Appendix H — Evidence Ledger: The DocAble Case

G.1 How to Read This Ledger

Part V presents the DocAble case over time. This appendix carries the quantitative and repository-level receipts behind its numerical claims.

Each section gives the measurement, its source or counting procedure, the observation window where one applies, the resulting values, and the main limit on interpretation. Unless stated otherwise, these are within-case descriptive measurements. They do not establish causal effects, comparative productivity, or portable target values.

The measurements fall into six groups: build scale and repository motion; model correspondence and drift; model coverage; representation and navigation cost; development and processing costs; and the relationship between measurement and authority.

The ledger exists for traceability. A number summarized in Part V should be recoverable here, together with the assumptions that bound it.

G.2 Build Scale and Repository Motion

G.2.1 Weekly Commit Volume

Weekly commit volume rose sharply as the agent fleet expanded, exceeded 1,000 commits per week during sustained high-volume periods, and briefly exceeded 3,000. Volume declined through the interval Part V identifies as hardening, then rose again.

During hardening, a larger share of classified commits concerned models, validation, tests, and control machinery. Commit counts do not establish why volume changed or whether productivity rose or fell.^** On some of these weeks, the author purportedly went on vacation. Figure H-1 plots the weekly series.

G.2.2 Support-Apparatus Ratio

Production and support-apparatus source were counted at four dated repository states across the seven primary source roots. The counting procedure fails if an expected root is absent. These counts are the source for the support-ratio curve in Part V.

Support-apparatus source began below parity with production source, crossed it by the mechanization snapshot, peaked at 3.68× during hardening, and stood at 3.06× at the final snapshot.

These counts describe how source was distributed in this repository. The ratio is not a measure of engineering value, engineering-capital return, or a recommended target for another project.

G.2.3 Product-Path Line Motion

Lines added and deleted were counted over four windows for the two principal product paths:

• web/ — the Python service and worker.
• backend/ — the C# tool and rule engine.

Source: git numstat over the dated commit windows.

The mechanization window contains the largest add-and-delete volume, particularly in backend/. Deletions fall sharply in the later windows, and both paths become strongly net-additive. Figure H-2 plots these counts.

These counts are a repository-motion proxy, not the theoretical concept of churn used elsewhere in the book. Generated bundles and vendored trees are included where they occur; Part V's accounting note describes that bounded inflation.

G.2.4 Growth of Countable Controls

Project-specific lint files and gate scripts were counted at four repository states, using git ls-tree at the corresponding window SHA.

Both counted surfaces begin at zero in the prototype snapshot. At the final snapshot, the 747 lint files contain 993 registered lint specifications.

Two further repository counts show that at least some controls were created in response to observed failures:

• Paired fix-and-lint tags — 208 commits carry one.
• Incident-named lints — 27 lints name a specific dated incident in their text; spot checks confirmed that the sampled cases linked an observed failure to the resulting control.

These counts show both the growth of project-specific control machinery and a subset of cases where failures led to new controls. They do not show what fraction of all controls originated in failures rather than being designed prospectively, and raw control counts do not measure their value.

G.3 Model Correspondence and Drift

The measurements in this section concern model↔code correspondence only. Documentation drift is counted separately in G.3.5 and is excluded from the model-sync claim.

The underlying question is narrow. After explicit models became reasoning surfaces, did model↔implementation drift occur, could derived checks detect it, and did the observed class recur after close?

G.3.1–G.3.4 Correspondence Results

Manual review classified all approximately 27 pre-floor findings as genuine model↔code drift. Because that classification relied on human judgment rather than an independent criterion, the result establishes that drift existed before the floor, not the detector's precision.

The six HEAD catches were an unregistered model consumer, a missing component entry, a service-call-graph mismatch, and three stale-anchor or stale-test cases. A symbol-anchored drift lint, a consumer-registry-freshness check, and a service-call-graph drift lint detected them.

Taken together, these observations establish a bounded within-case sequence: model↔code drift existed before the derived checks; the checks caught six fresh instances; and the modeled, mechanically decidable class did not recur across 56 closes during the measured window. They do not establish that the class was eliminated or that the mechanism prevents model drift.

G.3.5 Documentation Drift — Excluded from the Model-Sync Claim

Stale headers and stale prose numbers are documentation drift, not model↔code drift. They are counted separately because folding them into the correspondence measurements would inflate the model-sync evidence.

These observations concern prose that no derived correspondence check parses. They therefore say nothing about whether a model remains synchronized with implementation.

G.3.6 Scope of the Model-Sync Claim

The correspondence mechanisms cover only modeled, mechanically decidable relationships, and the observed N is small. A semantic mismatch whose anchors still resolve may remain judgment-dependent, and an unmodeled region has no model-correspondence check at all.

The results are therefore field observations about one governed surface, not a general catch rate or a proof of model correctness. Three cases stay distinct:

• Derived correspondence — machinery can re-establish it from current artifacts.
• Semantic correspondence — it may still require judgment.
• Unmodeled regions — no model claim exists for them yet.

G.4 Model Coverage

The traceability tracer measures the fraction of exercised code with no corresponding model claim. Repeated runs identified portions of the exercised surface that stayed outside the explicit model structure. Across the recorded sequence, the unmodeled fraction fell from 56% on the first run to 7.89% on the ninth.

Three qualifications matter.

• Coverage, not quality. The metric measures coverage, not model quality. Code may trace to a model claim that is itself incomplete or poorly chosen.
• Operator-directed decline. Each model-loop Epic targeted a large remaining orphan cluster. The decline reflects deliberate modeling work, not autonomous convergence.
• Not all orphans are debt. An unmodeled exercised symbol may be a genuinely missing model, a missing anchor on an existing model, or implementation detail below the grain the model should represent. Backward tracing from exercised symbols to expected model edges distinguished these cases; only the first two necessarily call for more modeling. The unmodeled fraction measures absence of explicit representation, not engineering deficiency: the remainder may include unknown obligations, tacit obligations, and deliberately preserved degrees of freedom. MAGE does not prescribe zero as the target.

G.5 Representation and Navigation Cost

A small exploratory pilot tested whether a model-derived navigation surface reduced the context an agent consumed while determining where to look in the repository.

Across four tasks, model-guided navigation reduced reconstruction-token cost by a median of roughly 35% relative to the from-scratch condition, with no observed loss of task-level correctness.

The tasks were not independently sampled, and N=4 is too small to estimate a general effect. Within this small pilot, the result is consistent with the proposed mechanism: an explicit representation may reduce how much lower-level structure an agent must reconstruct before acting.

G.6 Cost and Scale Receipts

These quantities establish orders of magnitude relevant to the Part V discussion. Their units, scopes, and cost categories differ; they are not entries in a comparative cost model.

The manual-remediation estimate and automated-processing figure use different units and cost categories. One estimates faculty labor across a teaching load; the other records direct processing cost for one representative deck. They indicate scale but are not a controlled cost comparison.

The vendor range is a market observation, not a quality-adjusted comparison with DocAble. The development-cost figure is an order-of-magnitude direct-cost estimate, not audited project accounting.

G.7 Measurement Without Authority

A measurement can be useful before it deserves authority.

G.7.1 Provisional Cost-and-Time Model

A per-chunk worst-case cost-and-time estimate was recorded as a timestamped provisional model rather than embedded as a permanent code constant.

Current instrumentation can report when an operation would exceed the provisional budget. Production admission does not depend on that estimate, because the observation base is not yet strong enough to justify a blocking threshold.

The provisional bound need not be correct to be useful. The system keeps the stages separate: observation → representation → reporting. Because the evidence is insufficient, the estimate does not become a gate.

G.7.2 Cold-Start Contrast Case

The contrasting case did justify an engineering decision.

The measured request-level cold-start value was 4,057 ms. That observation fed a topology model representing the longest cold-start path and motivated an architectural change. The resulting warm floor was 109 ms. The sequence is request-level measurement (4,057 ms) → cold-start topology model → architectural change → 109 ms warm floor.

The contrast does not imply that every measured quantity should eventually become a gate. Authority requires evidence adequate to the decision being made. The provisional cost model remained report-only; the stable, structurally interpretable cold-start observation justified architectural action.

G.8 What This Ledger Does Not Measure

Most quantities in this appendix are activity, structural, or within-case mechanism measures:

• commits and line motion;
• source distribution;
• control counts;
• model coverage;
• correspondence catches and reopens;
• exploratory navigation cost;
• selected financial and runtime observations.

These are not direct estimates of the broader outcomes needed to compare MAGE with another engineering process: durable throughput, defect escape, human-attention burden, or total cost of ownership. The case follows one production system, one primary engineer directing an agent fleet, and one contemporary model ecosystem; it did not collect those outcomes under a controlled counterfactual. The measurements therefore establish what happened within the case and which mechanisms were exercised, not the effects another organization should expect from adopting MAGE.

The ledger's narrower purpose is traceability: the quantitative claims in Part V can be inspected independently of the surrounding argument.