Metrics

ovecc records 28 metrics at every ovecc index, per snapshot. Any of them can be trended with ovecc history <metric> and compared with ovecc drift. The same definitions are served machine-readably by ovecc capabilities --format json and inside every JSON envelope's meta block.

Structure

Metric	Definition	Interpretation
files	Number of indexed source files	structural size
modules	Number of inferred or declared modules	structural size
dependencies	Number of resolved import dependencies	structural size
external_dependencies	Dependencies resolving outside the repository	informational
symbols	Extracted top-level symbols (functions, classes, …)	structural size
calls	Resolved call-graph edges	informational
apis	Exposed routes, RPC methods, and handlers	informational
tables	Database schema objects referenced by code	informational
functions	Functions/methods analyzed for complexity	informational
parse_failures	Files that failed to parse this run	lower is better

Coupling & architecture

Metric	Definition	Interpretation
coupling_density	Realized module edges over all possible directed edges. Range [0, 1]	lower is looser coupling
circular_dependencies	Strongly-connected (cyclic) module components, over runtime imports only — import type is erased before load and never witnesses a cycle	lower is better
boundary_violations	Findings crossing a declared architecture boundary	lower is better

circular_dependencies vs query cycles

One strongly-connected component can hold several elementary loops, so this metric sits at or below the loop count query cycles lists. They are not meant to match.

Complexity

Metric	Definition	Interpretation
max_cyclomatic	Highest per-function McCabe cyclomatic complexity	lower is better
max_cognitive	Highest per-function SonarSource cognitive complexity	lower is better
total_cognitive	Sum of cognitive complexity across functions	lower is better
high_complexity_functions	Functions over the complexity thresholds	lower is better

Findings & hygiene

Metric	Definition	Interpretation
security_findings	Code security findings: secrets, insecure patterns, weak crypto, tainted flows. Dependency advisories are tracked separately	lower is better
dependency_advisories	Known vulnerabilities (OSV) in dependencies; depends on when advisories were last fetched	lower is better
unused_exports	Exports imported by no reachable module	lower is better
unused_files	Files reachable from no entry point	lower is better
unlisted_dependencies	Phantom dependencies: imported but undeclared	lower is better
deadcode_entry_points	Entry points the reachability analysis started from	context for unused_files
code_smells	Structural code-smell findings: feature envy, large classes, data clumps	lower is better
stale_suppressions	ovecc-ignore comments that suppress no finding	lower is better

Evolution (requires Git history)

Metric	Definition	Interpretation
commits_ingested	Git commits ingested this run; 0 means no Git history	0 disables churn/ownership signals
max_file_churn	Highest per-file commit count	context
ownership_fragmented_files	Files with fragmented ownership	lower coordination cost

Per-component metrics

ovecc metrics additionally reports Martin metrics per component (not snapshot-trended, computed from the graph): fan-in, fan-out, coupling, instability I = fan-out / (fan-in + fan-out), abstractness A, and distance from the main sequence D = |A + I − 1|.

Not metrics

Two signals are deliberately not folded into any score:

• A module's bug-fix history sits beside the hotspots ranking rather than inside it. What a correction says about a module is a judgment call, so the number is there to be argued with, not to hand down a verdict.
• Line coverage (when an LCOV tracefile was indexed) sits on the same row for the same reason. Its value is the crossing: churn alone ranks the code that keeps moving, coverage alone ranks the code nobody tests, and only together do they say where a change is most likely to break something no test would catch.