How we measure
engineering performance.

Lines of code. Commit count. Story points. DORA. Each answers a different question. None answer the one that matters: did the output get more valuable, or just more numerous?

ETV (Engineering Throughput Value) is a unit of performance, produced by a measurement engine that reads code the way a senior engineer does — not just what changed, but what it meant, where it landed, and whether it touched the architecture.

The Engineering Throughput Value applied per file, per merged commit, combines five factors:

• Complexity — structural weight of the change itself.
• Engagement — ratio of surrounding code complexity to change complexity, so targeted edits in dense areas score higher than equivalent edits in trivial files.
• Architecture — where the change lands in the feature graph; deeply connected features carry more weight than peripheral ones.
• 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.

Each file contributes to one of three buckets: Growth, Maintenance, or Fixes. The buckets stay separate. Two engineers with identical totals can be doing very different work, and the score shows it.

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

Every file change is classified into one of three buckets. Scores are additive inside a bucket (you can sum Growth ETV across a quarter for an org), but deliberately not additive across buckets. Two engineers with identical total ETV can be doing very different work.

For each merged commit, the engine produces three sub-scores — one for Growth, one for Maintenance, one for Fixes. Each sub-score is assembled per file and summed across the commit. The structure of the score itself is deterministic; machine-learning components are used to tune thresholds and coefficients inside it, and a large-language-model classifier resolves ambiguous work classifications where pattern-based signals are insufficient.

Before any decay or amplification factors are applied, 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. When multiple repositories are connected, the graph extends across them via shared libraries and API contracts.

Several factors run before the per-file score is finalized. 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.

The filter list runs before any scoring and is identical across organizations.

• Generated code. Protocol Buffers, GraphQL schemas, OpenAPI clients, anything matching *_generated or *.gen.* patterns.
• Dependency lockfiles. go.sum, package-lock.json, yarn.lock, Cargo.lock, poetry.lock, etc.
• Build artifacts. dist/, node_modules/, hashed outputs, anything checked in by mistake.
• Minified files. Detected by average line length over 300 characters.
• Binary and media files. Images, video, archives, fonts, compiled binaries.

The scoring engine produces three sub-scores per commit. The report layer collapses them into a single scalar — Engineering Throughput Value (ETV) — and aggregates upward through three levels.

Figures in the report label the scalar as "performance" for readability. The formal definition is ETV.

Primary credit goes to the git author of the merged commit, after email-alias resolution. Co-authors are tracked but do not receive score credit. Attribution uses the merge date, not the commit date — so out-of-order merges land in the quarter they actually shipped.

Automation accounts (dependabot, renovate, github-actions) are excluded by default. Organizations can flag additional bots or service accounts.

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

• Cross-repository comparisons are not straightforward. Repositories of very different size, language mix, or team composition produce ETV scores on different effective scales. The repository is the natural boundary of the engagement calculation.
• Unconnected work is invisible. A contributor who does most of their work in repositories Navigara has not connected to will appear low.
• Supporting roles are not directly captured. Code review, mentorship, on-call, incident response, and design work do not carry ETV unless they show up as commits on the default branch.
• Co-authors are tracked but uncredited. The merge commit's git author receives the score; pair- and mob-programming need to be reconstructed externally.
• 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. The Q1 2026 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.

Growth, Maintenance, and Fixes is the canonical view. For executive reporting some teams prefer a two-bucket view: Maintenance + Fixes combined into Keep The Lights On (KTLO), with Growth on its own. The underlying three-category data is unchanged — KTLO is a visualization choice, not a different metric.