# Navigara adds a useful engineering-spend lens, but does not close the task-cost or hosting-TCO evidence gaps

**Research cutoff:** 9 October 2026. **Context:** Halbach AI’s Knauf Digital leadership workshop, 25-minute presentation and five-minute Q&A. **Status:** internal research and original synthesis. Public vendor capabilities are not independently tested here.

## 1. Recommendation: adopt four management ideas and retain our outcome-based economics

Navigara’s main proposition is to connect engineering spend, delivered code, business intent and the constraint limiting delivery. It combines repository analysis with usage telemetry and management controls. That is relevant to Knauf Digital’s technology leadership, particularly if coding assistants are part of their AI portfolio. It should become a short secondary example within our existing structure, while the product-information assistant remains the main illustration.

The useful additions are:

1. Include provisioned AI-tool seats, overages and induced CI/preview costs alongside API consumption.
2. Connect spend to an approved business objective or operating mandate, with a named owner and success measure.
3. Allow budget exceptions and bounded reallocation instead of treating every high spender as wasteful.
4. Measure the complete delivery path, including review, rework and deployment, because faster generation may move the constraint.

These are our recommendations, informed by the sources below. They do not require adoption of Navigara, its scoring system or its numerical benchmarks.

**Still open:** measured costs per accepted task for approved provider configurations; contract-specific GDPR eligibility; measured owned/rented inference capacity, power and operating effort; and a populated end-to-end local-versus-API TCO. Navigara’s public pages do not supply these missing inputs.

## 2. What their approach actually consists of

| Layer | Publicly described approach | What it can establish | What it does not establish |
| --- | --- | --- | --- |
| Output measurement | Repository-derived work categories and Engineering Throughput Value, or ETV | A vendor-defined view of code contribution and work mix | Customer benefit, cash savings or attributable AI impact |
| Adoption | Separate dimensions covering how people and teams use agents [N02] | Signals for coaching and workflow improvement | That more usage or autonomy is always preferable |
| Work purpose | Link work to objectives and inspect objective context [N03] | Whether recorded work has a stated mandate | Whether the mandate is economically sound |
| Spend | Attribute usage to work and offer optional model routing [N04] | A proposed connection between consumption and delivery | Complete invoice reconciliation or production savings independently verified here |
| Budgets | Adjustable envelopes, floors, escalation and review mode [N05] | A decision-control pattern | That past average efficiency predicts marginal returns |
| Delivery constraints | Checks across coding, review, automation, roadmap and AI cost [N06] | Places to investigate | A validated additive percentage of recoverable productivity |
| Finance reporting | Code-derived CapEx/OpEx classification and evidence exports [N07] | Potential support for finance’s review | A complete accounting recognition decision |
| Deployment | SaaS, local collector with cloud frontend, or full on-premises [N08] | Alternative control boundaries | A guarantee that every configured data flow stays local |

### The measurement mechanism is more specific than “an LLM scores value”

The methodology describes AI classification and structured context extraction followed by deterministic scoring. Complexity, engagement and further factors weight file changes; work remains split into features, maintenance, tests, documentation and fixes. Coefficients are periodically recalibrated. [N01]

This is a code-output proxy. Greater complexity is not automatically greater commercial value, and a useful simplification can reduce complexity. Use operational and business outcomes to validate any score.

The performance documentation explicitly limits raw comparisons across repositories and omits contributions such as mentoring, planning and much review work. It recommends team-level interpretation. It also says reverting a change does not retroactively remove the original score. [N09] That matters when output is used as a budget denominator.

## 3. Where this fills a real gap in our preparation

| Existing preparation | Useful extension | Recommended use in the workshop |
| --- | --- | --- |
| Full task costs, including review and operation | Make paid-but-unused seats and downstream CI/preview spending explicit | One sentence in cost anatomy; optional coding example |
| Workload ownership and chargeback | Add objective/mandate and success measure to the attribution chain | Add purpose beside cost centre and task ID |
| Envelopes, alerts and enforcement | Distinguish a safety ceiling from equal per-seat allocation; propose exceptions before automating | Explain in the governance slot |
| Accepted outcomes and latency | Show the path from task specification through review to release | Explain why faster generation can fail to improve delivery |
| Baselines and evidence hierarchy | Freeze measurement version, scope and cohort before comparisons | Technical appendix and pilot protocol |
| Exact token fields and billing | Extend reconciliation to coding-tool telemetry and subscriptions | Monitoring appendix; use native documentation |

Navigara’s September CEO-questions article explicitly includes tooling-induced compute and senior review effort alongside seats and tokens. [N10] Our existing full-cost principle already covers much of this; the addition makes the coding-tool case concrete.

The August bottleneck article frames specification, coding and review as one loop. [N11] Adapt the principle to our main illustrative workflow: faster answers still need evidence checks and sometimes specialist handling. Do not assert that review is necessarily Knauf’s current constraint.

### A useful work-purpose record

Our proposed minimal record is:

| Field | Purpose |
| --- | --- |
| Workload and task IDs | Join execution to the business activity |
| Owner and cost centre | Assign operational and financial accountability |
| Objective or operating mandate | Explain why the work is funded |
| Acceptance rubric and service constraints | Define a useful outcome |
| Actual cost, outcome and exceptions | Support continuation, adjustment or stopping |

Missing linkage means **unexplained**, not automatically **waste**. Incidents, compliance, maintenance and bounded experiments can be valuable off-roadmap work. Our recommendation is to retain separate mandates for them.

### A better budget question

Ask: “What additional accepted outcome could this exception buy, at what incremental cost and risk?”

Start with recommendations that a person reviews. Reserve minimum capacity for critical work and a separate experimentation allowance. Compare similar workloads and inspect quality before moving funds. A low historical cost/output ratio is a screening signal, not a forecast of what the next euro will buy. These are our proposed controls, rather than a claim that Navigara implements each of them.

## 4. Evidence checks: use the methods, qualify the claims

### The research is observational, commercially interested and sensitive to rescoring

The latest linked report was published on 7 September 2026 and covers 699 qualifying contributors across 65 public repositories. Its reported yearly ETV increase differs between open and fixed cohorts: about 130% versus 82%. The quarterly confidence interval includes zero. The paper does not attribute a quantified share to AI adoption. It documents rescoring shifts, repository-selection effects and unobserved engineering work. [N12]

This supports discussion of measurement uncertainty. It does not support promising Knauf a similar gain.

Keep the Q1 and Q2 reports separate: the April report uses an earlier cohort and a three-category framework. [N13] Comparing headlines from separately scored editions would mix definitions and populations.

### Several public examples fail an arithmetic check

| Public example | Published figures | Our calculation | Treatment |
| --- | --- | --- | --- |
| July spend-management article, first contributor | $343.30 spend; 10.3 ETV; $24.04/ETV | 343.30 / 10.3 = **$33.33/ETV** | Do not reuse the ratio |
| Same article, last contributor | $1,090.25 spend; 0.90 ETV; $467.83/ETV | 1,090.25 / 0.90 = **$1,211.39/ETV** | Discrepancy is too large for ordinary display rounding [N14] |
| Token-spend product page | $40,000 buys about 165 ETV; nearby current cost $3,009/ETV | 40,000 / 3,009 = **13.29 ETV** | A different marginal rate would need to be disclosed [N04] |

These calculations check the displayed figures, not underlying customer records. They do not establish that every example is wrong. The July author also labels dynamic budgeting as a pilot argument and the five-person table as an illustration. Preserve that qualification.

### Clarify scoring semantics before using a scalar denominator

The methodology and performance docs say the categories should not be added across work types. The Q2 PDF sums them with equal weights and tests alternative weights. [N01, N09, N12] A reporting convention could explain this, but the public sources do not reconcile the distinction clearly.

The architecture page describes a cross-repository mesh, while the performance page says scoring uses a repository boundary. [N09, N15] These could be separate capabilities; establish which scope enters a reported score.

Determinism for fixed inputs can coexist with changing historical results when classification, coefficients or scope change. Do not interpret that as proof that determinism itself is false. Request a frozen calculation version, snapshots, explanations of restatements and enough detail to reproduce comparisons.

### Engineering productivity is not automatically financial ROI

Valuing added capacity at loaded salary produces an estimate of capacity benefit. It becomes financial value only through an identified action or outcome: avoiding a hire, releasing paid resources, increasing contribution margin, or reducing a measured operating burden.

A benefit/cost ratio is not net ROI. Keep our existing convention:

**Net ROI = (attributable monetised benefit − incremental total cost) / incremental total cost.**

Report realised cash, avoided expenditure and redeployed capacity separately. Do not derive headcount reductions from a throughput score.

### Do not replace established delivery metrics with a vendor score

Some blog titles imply DORA metrics broke. DORA’s own current guidance describes five delivery metrics spanning throughput and instability, and recommends contextual interpretation rather than cross-team competition. [N16] Pair accepted business outcomes and cost with delivery and quality measures. ETV may be an additional diagnostic if validated for the actual context.

## 5. Does Navigara solve our token and GDPR questions?

### Telemetry is useful for attribution; billing remains the financial authority

The integration guide describes OTLP ingestion for Claude Code, Copilot, Codex and LiteLLM, with identifiers used to link usage to contributors. Prompt and raw-body collection are optional. [N17] This is a documented integration approach, not proof that every installation captures all billable usage.

Anthropic’s native documentation calls cost metrics approximate and directs users to the provider for billing. It also documents older streaming overcounts before Claude Code v2.1.214. [N18] Record the client version and validate collection against provider records before treating a dashboard as reconciled.

Our proposed reconciliation has three separate records:

1. **Consumption:** provider/API counters, exclusive cache categories and model identity.
2. **Charges:** provisioned seats, included entitlements, overages, negotiated rates, credits and actual invoices.
3. **Outcomes:** the accepted task, relevant business mandate and review/rework effort.

A subscription’s API-equivalent usage estimate is not an additional payable charge. Collector and proxy streams may describe the same requests; avoid double counting. Keep employee-facing reporting proportionate and agree its purpose with the appropriate internal owners.

### A local collector is not the same as local inference

Navigara’s security page explicitly says analysis content goes to the configured LLM endpoint. Keeping code inside the network therefore requires an internal model endpoint. [N19] The full-on-prem guide also permits external API endpoints and separately describes local endpoints for air-gapped operation. [N08]

This reinforces our configuration-level eligibility approach. Check the application, analysis model, trackers, identity, exports, metadata and backups together. A deployment label or GDPR badge does not substitute for that assessment.

### Their pricing is an input, not a hosting comparison

The live page lists starting prices of $7/developer/month for Measure, $30 for Pro and a $4,500 one-off report; enterprise is quoted separately. [N20] These are software prices, not measured task costs. Any trial comparison must also include integration, operation, analysis-model charges where applicable and internal review effort.

We did not obtain a contract, independent assurance report, service-level test, customer invoice or measured self-hosted throughput. No blanket provider-compliance conclusion is drawn.

## 6. Market relevance for Halbach

The public positioning combines spend attribution, outcome proxies, routing and governance. Navigara’s optional Chameleon router means there is some direct overlap with the public model-selection landscape, alongside the broader engineering-management proposition. Its advertised quality and savings examples are not validated benchmarks here. [N04]

Navigara’s comparison articles are useful discovery leads, not a neutral ranking. They contain inconsistent descriptions of some competitors. We cross-checked one lead against Faros’s own current site, which also describes engineering token attribution, outcome feedback and model-routing controls. [N21] No vendor superiority conclusion follows.

For Halbach, public claims such as “we route to cheaper models” are unlikely to distinguish the product on their own. Earn credibility through a measured workload, eligibility constraints, quality, implementation effort and the action that realises savings. This is strategic interpretation, not evidence about Halbach’s unpublished capabilities.

Use high-level public mechanisms in the workshop. Keep proprietary routing policies, evaluation datasets, implementation recipes, partner traces and unpublished performance evidence outside a deck that may circulate.

## 7. Targeted script changes preserve the 25+5 format

These are replacements inside existing slots, not additional slides:

- **Cost, 2–5 minutes:** “For employee AI tools, the bill also includes provisioned seats and overages. More generated work can add testing and review costs elsewhere.”
- **Governance, 5–9 minutes:** “A budget needs a ceiling and an exception path. A high bill can reflect useful work, so judge the mandate, accepted output and incremental economics.”
- **Monitoring, 9–12 minutes:** “Connect cost to both an owner and a purpose. Treat client cost telemetry as provisional until it reconciles with the provider’s bill.”
- **Optimisation, 12–17 minutes:** “After improving generation, check what limits the complete workflow. If evidence checking or review is now the constraint, faster generation alone may add a queue.”
- **Evidence, 20–23 minutes:** “More output is not itself cash saved. Show what changed, what it cost, and which action or business outcome made the benefit real.”

Keep Navigara as a background source or optional appendix example. The presentation remains a useful decision framework for Knauf, with relevance to Halbach shown through evidence and judgment.

## 8. Sources and scope

See 11_navigara_public_page_inventory.md [local reference omitted] for all retrieved and inaccessible URLs. All sources below were accessed on 9 October 2026. Dates on undated product/docs pages are access dates, not publication dates.

| ID | Primary source | Use and limitation |
| --- | --- | --- |
| N01 | [Methodology](https://research.navigara.com/methodology) | Scoring design; vendor methodology, not independent validation |
| N02 | [AI adoption](https://navigara.com/product/ai-adoption) | Separate adoption dimensions |
| N03 | [Alignment](https://navigara.com/product/alignment) | Objective-context and linkage approach |
| N04 | [Token spend](https://navigara.com/product/token-spend) | Routing beta and cost/output examples |
| N05 | [Adaptive limits](https://navigara.com/product/token-limits) | Floors, mandates, escalation and review mode |
| N06 | [Agent speed](https://navigara.com/product/agent-speed) | Diagnostic checks; displayed speed recovery is example data |
| N07 | [CapEx/OpEx](https://navigara.com/product/capex-opex) | Finance evidence positioning; recognition not independently assessed |
| N08 | [Full on-premises](https://docs.navigara.com/deployment/full-on-premises) | Actual infrastructure and endpoint options |
| N09 | [Performance docs](https://docs.navigara.com/concepts/performance) | Scope, aggregation and attribution limitations |
| N10 | [12 CEO questions, 17 September](https://navigara.com/blog/ceo-questions-ai-roi) | Useful cost and uncertainty questions |
| N11 | [Bottleneck loop, 24 August](https://navigara.com/blog/three-bottlenecks-one-loop) | Workflow hypothesis, not measured universal effects |
| N12 | [Q2 report, revised 7 September](https://research.navigara.com/research/Navigara-Performance-Report-Q2-2026.pdf) | Observational study, limitations and sensitivity |
| N13 | [Q1 report, 30 April](https://research.navigara.com/research/Navigara-Performance-Report-Q1-2026.pdf) | Earlier edition, different definitions/cohort |
| N14 | [Spend-management article, 29 July](https://navigara.com/blog/three-ways-to-manage-token-spend) | Pilot argument and arithmetic checks |
| N15 | [Architecture docs](https://docs.navigara.com/concepts/architecture) | Repository mesh description |
| N16 | [DORA metrics](https://dora.dev/guides/dora-metrics/) | Official five-metric guidance, updated 5 January 2026 |
| N17 | [AI-tool integrations](https://docs.navigara.com/integrations/ai-tools) | Vendor integration instructions |
| N18 | [Claude Code monitoring](https://code.claude.com/docs/en/monitoring-usage) | Native telemetry/billing distinction |
| N19 | [Security](https://navigara.com/security) | LLM endpoint and responsibility boundary |
| N20 | [Pricing](https://navigara.com/pricing) | Live advertised prices, not procurement quotes |
| N21 | [Faros](https://www.faros.ai/) | One primary-source market cross-check |
| N22 | [Changelog](https://docs.navigara.com/changelog) | October 7 v0.16.4: repository spend and issue linkage; October 2 budget-page rename |

**Freshness:** the latest listed release at inspection was 7 October 2026. The current research edition remained Q2, published in September. A Q3 publication was not identified in the research index. Latest software release and latest empirical study are different dates.