How we measure
engineering performance.

A model reads every diff the way a senior engineer would, and grades what the change was worth instead of how much was typed.

It scores each change against the repository around it: what calls what, what a table is read by, what breaks downstream. Those file scores roll up to engineers and organizations with nothing estimated on the way, so every number here walks back down to the diffs it came from.

That unit is ETV — Engineering Throughput Value. It is applied per file, per merged commit. A commit touching ten files contributes ten independent measurements. Five factors set the weight of each one:

• Complexity — structural weight and cognitive load of the modified lines, computed per function scope.
• Engagement — how much of the surrounding codebase the change had to reason about, so targeted edits in dense areas score higher than equivalent edits in trivial files.
• Architecture — where the change lands in the feature graph; cross-feature surfaces and integration seams carry more weight than leaf-node edits.
• Decay — reduces credit when a change isn't real cognitive work: mechanical refactors, self‑rewrites of yesterday's code, copy‑paste from elsewhere in the repo.
• Multiplier — amplifies fixes when the bug was costly: old code, unfamiliar code, high‑churn areas.

per_file_score = f(complexity, engagement) × architecture × decay × multiplier

Each file lands in one of five buckets: Features, Maintenance, Tests, Docs, or Fixes. There is no single “performance score.” ETV is additive inside a bucket and deliberately not additive across them — two engineers with identical totals can be doing very different work, and the split shows it.

ETV is answerable from commit history alone. No PM tools, no surveys, no self‑report.

The classifier reads what the diff actually does, not what the commit message claims. Conventional Commit prefixes are a hint, not a rule. Classification is per file: a single commit can carry feature work in one file, a test in another and a fix in a third, each scored independently.

A healthy codebase typically shows steady feature work, moderate maintenance, tests that track the feature work, and few fixes. A spike in fixes is a signal worth investigating.

Two things happen to every merged commit, in order.

Navigara builds a structural model of each repository — a feature graph. The graph is derived from code organization alone (no external metadata, no PM tooling) and informs how per-file scores are weighted.

Inputs: code structure only. No connected ticketing system, no external metadata.

Several factors run before the per-file score is finalized, and all of them apply before aggregation. Three dampeners reduce credit when a change exists but doesn't represent genuine cognitive work; one multiplier amplifies fixes when the surrounding signals say the bug was costly.

A single commit adds session refresh to an API. Each file is classified and scored on its own; the commit's totals are the sums by work type.

Performance is defined over whatever commits exist on the default branch after landing. When a branch lands via merge commit, each constituent commit is scored individually and later commits are dampened where they overlap with earlier ones (similarity, blame decay, copy decay). When the same branch is squashed, the resulting commit carries the full scope in one shot, with no intermediate overlap to dampen.

The dampening factors are calibrated so these paths converge. Totals come out close either way, so you don't need to change how you merge to get meaningful numbers.

The filter list runs before both AI analysis and mechanical scoring, and is identical across organizations. If a commit shows fewer scored files than files changed, the difference is filtered files — the knowledge graph records which, and why.

• Generated code. Protocol Buffer output (.pb.go, _grpc.pb.go, .pb.ts), GraphQL codegen (.graphql.ts), OpenAPI specs, and machine-generated files matching *_generated.go, *.gen.go, zz_generated.*.
• Dependency lockfiles. go.sum, package-lock.json, yarn.lock, pnpm-lock.yaml, Cargo.lock, Gemfile.lock, and similar.
• Build artifacts. dist/, build/, .next/, vendor/, node_modules/, and bundled outputs carrying content hashes.
• Minified files. Detected by content heuristics when average line length exceeds 300 characters.
• Binary and media files. Images, fonts, PDFs, archives, compiled binaries.

Teams with unusual generated-code conventions or build layouts can extend the filter list from organization settings.

Engagement is measured against the repo's other functions and call sites; context complexity is computed against local function scopes. Navigara does not perform cross-repository analysis: a change in repository A carries no engagement weight from repository B, even if the two are related services.

This is deliberate. The repository is the natural boundary of abstraction in most engineering organizations — it has a coherent build, review process and ownership model. Cross-repo call graphs exist in practice but are rarely stable enough to use as a measurement substrate.

The consequence: scores are not automatically comparable across repositories of very different size or language mix. When comparing teams that work in different repos, compare trends within each team rather than raw totals across teams.

File-level scores sum per work type, and those totals roll up through three levels with nothing estimated or re-weighted on the way.

Figures in the report label the unit as “performance” for readability. The formal definition is ETV, and the five buckets stay separate underneath it.

Primary credit goes to the git author of the merged commit, after email-alias resolution. Co-authors recorded in commit trailers are tracked in the knowledge graph but do not receive score credit. A contributor active in multiple connected repositories within one organization is counted once, with their output summed across repos.

Commits are attributed to the time window in which they were merged to the default branch, not when they were authored — so out-of-order merges land in the quarter they actually shipped. In AI-native teams work typically ships in days rather than weeks, so merge-date attribution closely tracks when the work happened.

Automation accounts (dependabot, renovate, github-actions) are excluded by default. Organizations can flag additional bots or service accounts; flagged contributors stay visible in the knowledge graph for audit, but their commits do not contribute to aggregated metrics. Non-engineering roles are excluded from both the numerators and the denominators of reported figures.

Senior engineers spend significant time on code review, architecture, mentoring and technical decisions — work that rarely produces commits. Per-commit scoring does not capture these contributions directly, and aggregating commits to individuals will systematically underrate them.

A strong supporting engineer raises the output quality of everyone around them: fewer bugs (fewer fixes), cleaner architecture, faster onboarding. That impact shows up in the team's aggregate even when the individual's own commit-based score is low. Individual scores remain useful for understanding work distribution and spotting trends, but they are not a complete performance picture where supporting roles are present.

ETV is descriptive, not normative. It tells you what shipped, not whether the right thing shipped.

• Public default branches only. Private forks, unmerged work and commits in repositories that were not connected are not scored. A contributor who does most of their work outside the analyzed set will appear low.
• Merged code only. Code review depth, incident response, planning, mentorship and pair-programming sessions that never produce a standalone commit carry no ETV.
• Cross-repository comparisons are not straightforward. Engagement is repository-scoped and cross-repo data flow is not modelled, so repositories of very different size or language mix produce ETV on different effective scales. Cross-organization totals are not auto-normalized.
• Co-authors are tracked but uncredited. The merged commit's git author receives the score; pair- and mob-programming need to be reconstructed externally. Author-rewriting tools — squash policies that discard original authorship, or AI coding assistants that replace the human author — shift credit accordingly.
• Classification is probabilistic per file. Individual files can be misclassified at the edges; aggregates are stable despite those cases.
• Causal claims require care. ETV moving up after a tooling change is consistent with the tooling helping. It is also consistent with several other explanations. ETV describes output, not business impact, and the report deliberately avoids causal language.
• Business-goal alignment is out of scope here. ETV measures what shipped, not whether what shipped advanced a particular business objective. Navigara's Alignment concept extends the model toward that question by mapping engineering output to quarterly goals and OKRs, but it requires either a connected goal-tracking tool or manually entered goals. It is not part of this report.

Features / Maintenance / Tests / Docs / Fixes is the canonical view, and the one used throughout the report. For executive and cross-team reporting, the product also offers a two-bucket view: Maintenance, Tests, Docs and Fixes combined into Keep The Lights On (KTLO), with Features on its own — a clean split between new value and everything else.

Switching modes changes only how the data is displayed. The underlying five-category analysis is unchanged, and nothing is lost by switching back.