Quality metrics

This page is the single source of truth for dpone code-quality metrics. It contains the current generated snapshot, interpretation rules, CI gates and update commands.

Current quality summary

🟢 GREEN - generated quality metrics and hard architecture gates are passing.

Generic reconciliation/API/type facades are protected by import rules, broad facades are lazy/delegating, module-size debt is closed, and architecture fitness is back inside the green clustering target. Release governance is split into focused catalog sections, so current architecture fitness has no class responsibility advisories. ETLProcessor is now below the preferred fan-out target after moving extracted-payload load-path coordination behind a focused service, MSSQL source strategies are below the preferred fan-out target after moving queryout artifact construction behind a focused factory, ClickHouse sink payload ingestion now lives behind a dedicated service, and PostgreSQL/BigQuery sink strategy wiring is isolated behind dedicated composition factories and shared connector/state ports. Strategy intelligence public exports are now lazy, so package-level compatibility no longer creates a false god-module dependency hotspot. Nested spill-to-disk loading now lives behind a focused service, keeping NestedLoadService as the root/child orchestrator.

Current gate snapshot: - architecture_fitness: OK, avg_clustering = 0.1798, cross_layer_ratio = 0.293, class warnings 0. - module_size: OK, warn threshold 450 LOC, fail threshold 600 LOC, allowlisted debt 0. - layer_metrics: OK, intra_ratio = 0.707, cross_ratio = 0.293, baseline trend stable. - quality_metrics: generated quality dashboard is current.

Traffic-light interpretation: - 🟢 GREEN: no module-size failures, no import-rule violations, clustering is within target, and generated docs are current. - 🟡 YELLOW: no critical blocker, but there is allowlisted size/coupling debt or a metric near threshold. - 🔴 RED: forbidden imports, new non-allowlisted modules above max LOC, stale generated docs, or a worsening layer-metrics regression.

First recommendations: - Keep newly touched modules comfortably below 450 LOC where practical, even though the hard failure threshold is 600 LOC. - Keep command/runtime code behind service/protocol facades; do not import vendor adapters from generic core. - Keep small route/control-plane dependency triangles visible before adding the next broad route feature. - Keep ReleaseOpsCatalog as a composition root only; add new release behavior to focused gate/governance/readiness/risk sections. - Treat dpone.manifest.explain as the next architecture-fitness fan-out reduction target; benchmark scoring also keeps dpone.runtime.credentials.factory visible in the production-only corpus. - Treat broad facades as compatibility shims only: lazy re-export/delegation is acceptable, business logic is not.

Current generated snapshot

This section is auto-generated by dpone docs update-dev-metrics.

Quality summary

• Traffic light: 🟢 excellent
• Biggest module: 449 LOC (src/dpone/commands/airflow_self_service_rendering.py) → OK
• Avg clustering: 0.179 → OK
• Cross-layer ratio: 0.300 → OK
• First improvement target: keep broad service/command seams thin before adding new runtime features.

LOC (lines of code)

Repository-wide (**/*.py)

• Files: 3773
• Total lines: 646843
• Total SLOC: 549781
• Min: 0 (src/dpone/adapters/__init__.py)
• Max: 3962 (tests/test_airflow_self_service_cli.py)
• Avg: 171.44
• Median: 131

Repository-wide without tests (**/*.py, excluding tests/)

• Files: 2766
• Total lines: 408176
• Total SLOC: 347646
• Max: 1043 (tools/type_matrix_certification.py)
• Avg: 147.57
• Median: 118

Top 15 largest modules in src/dpone/

Module	Lines
src/dpone/commands/airflow_self_service_rendering.py	449
src/dpone/services/safe_sample_policy.py	449
src/dpone/manifest/confined_mutations.py	443
src/dpone/security_redaction.py	440
src/dpone/runtime/connectors/api/connector.py	436
src/dpone/gitops/airflow_dag_spec.py	434
src/dpone/runtime/etl/payload_loader.py	432
src/dpone/runtime/connectors/api/omnidesk_connector.py	431
src/dpone/readiness/airflow_deployment_projection.py	430
src/dpone/runtime/governance/finalization.py	428
src/dpone/gitops/airflow_compact_pack.py	427
src/dpone/gitops/airflow_connection_bridge_plan.py	426
src/dpone/runtime/governance/legacy_acceptance.py	424
src/dpone/runtime/etl/processor.py	423
src/dpone/services/schema_type_matrix.py	423

Coupling / Cohesion (internal imports inside dpone.*)

• Modules: 2464
• Internal import edges: 5838
• AVG Ce (fan-out): 2.37
• Median Ce: 1
• P90 Ce: 6
• P95 Ce: 8
• MAX Ce: 21 (dpone.runtime.sources.strategies.mssql.mssql_queryout_artifacts)
• MAX Ca (fan-in): 102 (dpone.output_json)
• LCC ratio (largest connected component): 0.938
• Avg clustering coefficient: 0.179
• Cohesion ratio (share of deps within slice): 0.620

Heuristic interpretation

• AVG Ce = 2.37 → OK (lower is usually better; big fan-out hints 'god modules')
• P90 Ce = 6 → OK (if P90 grows, responsibilities are spreading)
• Avg clustering = 0.179 → OK (higher clustering often means more cycles/tight coupling)

Top 15 modules by fan-out (Ce)

• dpone.runtime.sources.strategies.mssql.mssql_queryout_artifacts: 21
• dpone.gitops.schema_airflow_contracts: 18
• dpone.gitops.schema_contracts: 17
• dpone.readiness.airflow_self_service_application: 17
• dpone.commands.airflow_self_service_cmd: 16
• dpone.commands.data_product_cmd: 16
• dpone.readiness.safe_sample_live_runtime: 16
• dpone.commands.registry: 15
• dpone.readiness.airflow_pipeline_scaffold: 15
• dpone.readiness.airflow_preview_service: 15
• dpone.readiness.studio_composition: 15
• dpone.runtime.sources.strategies.mssql.mssql_queryout_bcp: 15
• dpone.services.readiness: 15
• dpone.commands.docs: 14
• dpone.commands.run_safe_sample_cmd: 14

Top 15 modules by fan-in (Ca)

Approved stable high fan-in contracts are expected shared DTO/port modules; they remain visible here but are treated differently from god-module risks.

• dpone.output_json: 102 - approved stable contract: output serialization port
• dpone.output_text: 99 - approved stable contract: output text rendering port
• dpone.readiness.migration_control: 76
• dpone.gitops.models: 60
• dpone.commands.func_command: 50
• dpone.runtime.sources.extract_result: 48 - approved stable contract: source extraction DTO
• dpone.ops.routes.models: 46
• dpone.config.load_config: 44
• dpone.commands.base: 43
• dpone.ops.checksums: 43
• dpone.contracts.airflow_deployment: 42
• dpone.manifest.confined_files: 42
• dpone._compat: 41
• dpone.config.load_strategy: 39 - approved stable contract: load strategy enum contract
• dpone.gitops.schema_contract_primitives: 39

Layer / Slice architecture metrics

• Layers observed: 58
• Internal import edges: 5722
• Intra-layer edges: 4007
• Cross-layer edges: 1715
• Intra-layer ratio: 0.700

• Cross-layer ratio: 0.300

• Excluded layers: dpone.compat (126 modules, 116 edges removed from this coarse architecture view)

Heuristic interpretation

• Intra-layer ratio = 0.700 → OK (higher means more dependencies stay within their own layer)
• Cross-layer ratio = 0.300 → OK (lower means cleaner boundaries between layers)
• Top cross-layer / cross-slice flows below help spot architecture seams that may need ports, facades or further extraction.

Layer summary

Layer	Modules	Out	In	Intra	Cross-out	Cross-in	Avg Ce	Avg Ca	Cohesion	Target layers	Source layers
dpone._compat	1	0	41	0	0	41	0.00	41.00	1.000	0	10
dpone.adapters	17	18	17	6	12	11	1.06	1.00	0.333	4	5
dpone.airflow	8	0	0	0	0	0	0.00	0.00	1.000	0	0
dpone.airflow_connection_names	1	0	7	0	0	7	0.00	7.00	1.000	0	3
dpone.api	1	3	0	0	3	0	3.00	0.00	0.000	2	0
dpone.app	5	6	8	1	5	7	1.20	1.60	0.167	3	3
dpone.backfill	21	25	31	22	3	9	1.19	1.48	0.880	3	4
dpone.cli	4	9	4	3	6	1	2.25	1.00	0.333	4	1
dpone.cli_render	22	45	39	19	26	20	2.05	1.77	0.422	7	1
dpone.commands	210	807	336	334	473	2	3.84	1.60	0.414	25	1
dpone.config	4	4	106	4	0	102	1.00	26.50	1.000	0	8
dpone.connector_sdk	12	9	13	9	0	4	0.75	1.08	1.000	0	1
dpone.contracts	38	32	222	30	2	192	0.84	5.84	0.938	2	16
dpone.core	7	8	1	1	7	0	1.14	0.14	0.125	4	0
dpone.dag	37	92	113	68	24	45	2.49	3.05	0.739	5	7
dpone.dbt_publish	10	16	16	13	3	3	1.60	1.60	0.812	1	1
dpone.gitops	159	364	438	310	54	128	2.29	2.75	0.852	10	5
dpone.governance	6	6	29	5	1	24	1.00	4.83	0.833	1	4
dpone.integration_matrix	1	2	3	0	2	3	2.00	3.00	0.000	2	2
dpone.integration_matrix_behavior	1	1	3	0	1	3	1.00	3.00	0.000	1	3
dpone.integration_matrix_constants	1	0	6	0	0	6	0.00	6.00	1.000	0	6
dpone.integration_matrix_counts	1	1	5	0	1	5	1.00	5.00	0.000	1	5
dpone.integration_matrix_manifest	1	1	1	0	1	1	1.00	1.00	0.000	1	1
dpone.integration_matrix_models	1	5	1	0	5	1	5.00	1.00	0.000	5	1
dpone.integration_matrix_samples	1	4	1	0	4	1	4.00	1.00	0.000	4	1
dpone.integration_matrix_selection	1	1	1	0	1	1	1.00	1.00	0.000	1	1
dpone.integration_matrix_simulation	1	4	1	0	4	1	4.00	1.00	0.000	4	1
dpone.integration_matrix_wide	1	1	1	0	1	1	1.00	1.00	0.000	1	1
dpone.kubernetes_names	1	0	8	0	0	8	0.00	8.00	1.000	0	4
dpone.lazy_exports	1	0	5	0	0	5	0.00	5.00	1.000	0	3
dpone.lib	14	25	11	10	15	1	1.79	0.79	0.400	3	1
dpone.load_profile	5	7	7	5	2	2	1.40	1.40	0.714	1	1
dpone.manifest	92	260	383	241	19	142	2.83	4.16	0.927	6	8
dpone.metrics	14	16	28	16	0	12	1.14	2.00	1.000	0	1
dpone.observability	7	2	3	2	0	1	0.29	0.43	1.000	0	1
dpone.operations	38	38	0	0	38	0	1.00	0.00	0.000	1	0
dpone.ops	275	631	592	527	104	65	2.29	2.15	0.835	13	4
dpone.orchestration	6	6	9	5	1	4	1.00	1.50	0.833	1	1
dpone.output	1	5	7	0	5	7	5.00	7.00	0.000	5	1
dpone.output_files	1	0	2	0	0	2	0.00	2.00	1.000	0	2
dpone.output_format	1	1	1	0	1	1	1.00	1.00	0.000	1	1
dpone.output_json	1	0	102	0	0	102	0.00	102.00	1.000	0	4
dpone.output_table	1	0	11	0	0	11	0.00	11.00	1.000	0	2
dpone.output_text	1	1	99	0	1	99	1.00	99.00	0.000	1	4
dpone.output_yaml	1	0	2	0	0	2	0.00	2.00	1.000	0	2
dpone.ports	25	22	105	13	9	92	0.88	4.20	0.591	3	10
dpone.readiness	306	736	677	513	223	164	2.41	2.21	0.697	19	6
dpone.root	1	0	0	0	0	0	0.00	0.00	1.000	0	0
dpone.runtime	666	1820	1666	1516	304	150	2.73	2.50	0.833	16	9
dpone.schema	1	1	1	0	1	1	1.00	1.00	0.000	1	1
dpone.security_redaction	1	0	21	0	0	21	0.00	21.00	1.000	0	8
dpone.services	227	592	395	270	322	125	2.61	1.74	0.456	17	8
dpone.staging	2	4	1	1	3	0	2.00	0.50	0.250	2	0
dpone.storage	8	10	36	8	2	28	1.25	4.50	0.800	1	5
dpone.strategy_intelligence	37	53	48	31	22	17	1.43	1.30	0.585	6	5
dpone.supply_chain	8	5	5	3	2	2	0.62	0.62	0.600	2	1
dpone.type_system	22	23	50	21	2	29	1.05	2.27	0.913	2	4
dpone.vault_references	1	0	3	0	0	3	0.00	3.00	1.000	0	3

Top 15 cross-layer dependency flows

From layer	To layer	Edges
dpone.commands	dpone.output_json	98
dpone.commands	dpone.output_text	96
dpone.commands	dpone.services	95
dpone.services	dpone.gitops	95
dpone.runtime	dpone.config	86
dpone.readiness	dpone.manifest	69
dpone.runtime	dpone.contracts	69
dpone.commands	dpone.readiness	63
dpone.ops	dpone.runtime	59
dpone.readiness	dpone.runtime	58
dpone.services	dpone.readiness	58
dpone.services	dpone.ports	49
dpone.operations	dpone.ops	38
dpone.services	dpone.manifest	33
dpone.readiness	dpone.contracts	31

Top 15 cross-slice dependency flows

From slice	To slice	Edges
dpone.services.gitops	dpone.gitops	90
dpone.runtime	dpone.config	86
dpone.readiness	dpone.manifest	69
dpone.runtime	dpone.contracts	69
dpone.ops	dpone.runtime	59
dpone.readiness	dpone.runtime	58
dpone.services.gitops	dpone.ports	39
dpone.operations	dpone.ops	38
dpone.readiness	dpone.contracts	31
dpone.runtime	dpone.readiness	29
dpone.runtime	dpone._compat	24
dpone.runtime	dpone.ports	24
dpone.runtime	dpone.storage	23
dpone.commands.dag	dpone.dag	22
dpone.services.ops	dpone.ops	22

How to update this page

dpone docs update-dev-metrics

CI check:

dpone docs update-dev-metrics --check

Layer-metrics gate (thresholds + regression vs baseline):

dpone docs check-layer-metrics

Architecture-fitness gate (coupling hot spots + high-responsibility classes):

dpone docs check-architecture-fitness

Module-size gate (LOC/SLOC + explicit debt baseline):

dpone docs check-module-size

Refresh the committed baseline snapshot:

dpone docs check-layer-metrics --write-baseline
dpone docs check-module-size --write-baseline

Metric groups

1. LOC / SLOC (lines of code)

These metrics show raw module size and help spot oversized files. LOC counts all physical lines; SLOC counts non-empty, non-comment source lines. The generated report tracks both repository-wide metrics and the same metrics excluding tests, because production module size and test volume have different meanings.

Useful heuristics: - max LOC < 600 is the hard target for “regular” modules. - LOC <= 450 is the warning target for newly touched modules. - files above ~800-1000 LOC are strong candidates for splitting. - median LOC is often more informative than average, because a few large modules can skew the average.

2. Module-level coupling / cohesion

These metrics are based on the internal import graph inside dpone.*.

• Ce (fan-out) — how many internal modules a module imports. Lower is usually better.
• Ca (fan-in) — how many internal modules import a module. High fan-in can be fine for stable shared abstractions.
• LCC ratio — size of the largest connected component in the import graph. Very high values can mean the system is too entangled.
• Avg clustering — a proxy for “triangles” in the graph. Higher values often indicate tight coupling and hidden cycles.
• Cohesion ratio — share of imports that stay within the same slice. Higher is usually better.

Heuristics used in the generated report: - AVG Ce: OK ≤ 6, WARN ≤ 12, ALERT > 12 - P90 Ce: OK ≤ 12, WARN ≤ 18, ALERT > 18 - Avg clustering: OK ≤ 0.18, WARN ≤ 0.25, ALERT > 0.25

3. Layer / slice architecture metrics

These metrics complement module-level coupling by looking at architectural boundaries.

• Layer summary groups modules into coarse layers such as dpone.commands, dpone.services, dpone.manifest, dpone.dag, dpone.runtime, dpone.ports, dpone.adapters.
• Cross-layer flows show the strongest allowed layer→layer dependencies.
• Cross-slice flows go one level deeper (commands.dag -> services.dag, services.docs -> metrics, etc.) and help identify where abstractions may still leak.

Useful heuristics: - Intra-layer ratio — higher is better. A rough target is >= 0.55. - Cross-layer ratio — lower is better. A rough target is <= 0.45.

These are not absolute pass/fail thresholds. Some orchestration-heavy layers (commands, services) will naturally depend on several other layers. The main value is tracking trends over time and spotting unexpectedly heavy flows.

Baseline vs target

The current generated snapshot is recorded above on this page. Regression baselines live in docs/layer_metrics_baseline.json and docs/module_size_baseline.json.

Recommended long-term goals: - max module LOC < 600 - max module SLOC < 500 - max Ce < 12 - avg clustering <= 0.18 - no forbidden cross-layer imports (enforced by dpone docs check-import-rules) - no new non-allowlisted module-size failures (enforced by dpone docs check-module-size) - cross-layer ratio trending downward release over release

Layer-metrics gate in CI

Recommended CI step:

dpone docs check-layer-metrics \
  --baseline docs/layer_metrics_baseline.json \
  --min-intra-layer-ratio 0.55 \
  --max-cross-layer-ratio 0.45 \
  --allowed-ratio-regression 0.02 \
  --allowed-flow-regression 5

What it checks: - absolute thresholds for intra-layer / cross-layer ratios; - optional cap for the largest cross-layer flow; - regression against the committed baseline snapshot in docs/layer_metrics_baseline.json.

This is intentionally a coarse architectural gate. It does not replace dpone docs check-import-rules; instead, it complements it by catching trend regressions even when no forbidden import rule is violated.

Module-size gate in CI

Recommended CI step:

dpone docs check-module-size \
  --baseline docs/module_size_baseline.json \
  --warn-lines 450 \
  --max-lines 600

What it checks: - LOC and SLOC per Python module; - new modules above the hard max; - existing debt only when documented in docs/module_size_baseline.json; - focused refactor progress when allowlisted modules shrink below thresholds.

Current baseline policy: - No allowlisted modules may remain above 600 LOC by default. - New baseline entries require an explicit owner, reason, remediation target and architecture-review justification. - Compatibility facades are allowed, but must delegate immediately and must not accumulate business logic.