This document is constructed. It is not a redacted client report, not an average of past engagements, and not a claim about what your program would show. It exists so you can judge the format and the rigor before commissioning anything. Every figure is illustrative and traces to the arithmetic published in the methodology brief, which uses the same specimen program.
00The specimen program
A mid-size control platform inside a larger system program. Deliberately unremarkable: no exotic technology, no crisis, no villain. The kind of program where every team reports green and integration keeps slipping anyway.
| Reference | SPECIMEN-01 |
| Assessment scope | 18 modules · 240 documented interfaces |
| Trailing change effort (12 months) | 1,200 engineering days |
| Fully-loaded day rate (client-supplied) | $650 |
| Integration cycles per year | 4 |
| Source access | Read-only, 11 of 18 modules |
| Elapsed | 3 weeks |
Modules are identified by letter throughout, as they are in a real deliverable where names are client-confidential. Letters I and O are unused, to avoid confusion with digits.
01Executive summary
One page. It goes into a budget pack unedited, and it has to survive a finance director who did not attend any of the interviews.
The finding
Coupling in this program is concentrated, not diffuse. Four of eighteen modules — 22% — carry 62% of cross-boundary interfaces and absorbed 71% of change effort in the trailing year. Three of those four sit on the integration critical path.
Normalizing for change size, work inside that cluster cost 2.4× the effort of comparable work in the program's low-coupling modules. The difference is not team capability — it is the same organization, the same process, the same domain. It is the cost of the partition.
What it costs
Because 68% of the excess sits on the integration critical path, roughly 338 of those days translate into schedule rather than cost alone — about 5.5 weeks of integration per year spent absorbing coupling.
The decision in front of you
Three remediation candidates address 78% of the excess for 135 engineering days and pay back inside eight months. A fourth candidate — the one engineers raise most often in interview — has a 2.8-year payback and should not be funded.
Confidence
The exposure band is $262k–$363k. Its width is driven almost entirely by one assumption — the coupling multiplier — because this program does not currently measure change effort per module. Narrowing that band is cheap: it requires attribution of effort at module granularity, which is a reporting change rather than an engineering one. The uncertainty is itself a finding.
This assessment measures the architecture as documented and, where source access was granted, as implemented. It is not a certification artifact and does not substitute for a DER, auditor or safety assessor. It recommends work that ZOYA will not bid on.
02Architecture debt map
The technical page. It is what a chief architect argues with, and it is designed to be arguable — every edge traces to a documented interface or an observed change record.
Figure 1 — Coupling map, 18 modules. Node radius is proportional to trailing-year change effort. Cluster A contains modules A, B, C and D.
Effort concentration
Figure 2 — Change effort distribution, trailing 12 months. 22% of modules absorb 71% of effort.
Module register
| Module | Cross-boundary interfaces | Change effort (days) | Critical path |
|---|---|---|---|
| A | 46 | 268 | Yes |
| B | 41 | 231 | Yes |
| C | 38 | 205 | Yes |
| D | 24 | 148 | No |
| E | 13 | 46 | Yes |
| F | 10 | 38 | No |
| G | 8 | 34 | No |
| H | 8 | 31 | No |
| J | 7 | 28 | No |
| K | 7 | 26 | No |
| L | 6 | 24 | No |
| M | 6 | 22 | No |
| N | 5 | 20 | No |
| P | 5 | 19 | No |
| Q | 5 | 18 | No |
| R | 4 | 16 | No |
| S | 4 | 14 | No |
| T | 3 | 12 | No |
| Total | 240 | 1,200 | — |
Cluster A accounts for 149 of 240 interface endpoints (62%) and 852 of 1,200 change days (71%).
03Principal findings
Findings are written to be disagreed with. Each states the evidence it rests on, so a chief architect can attack the evidence rather than the conclusion.
31 documented interfaces cross this single boundary — the densest pairing in the program — and 41% of the measured excess effort traces to changes that touched both sides within the same cycle. Evidence: interface control documents, 14 months of change records, confirmed against source in both modules.
Ownership is ambiguous in the documentation and contested in interview. Changes to C required cross-team coordination in 62% of cycles, against a program median of 11%. Evidence: change records, design review minutes, four interviews.
No versioned contract exists; compatibility is maintained by convention and enforced only at integration test. Accounts for 14% of excess and a disproportionate share of late-cycle defects. Evidence: test reports across four integration cycles.
Raised in three of six interviews as the program's worst code. It is. It is also changed twice a year, sits off the critical path, and accounts for 6% of excess against 55 days of remediation — a 2.8-year payback. Recommendation: accept and document the decision, with an owner and a review date.
A deliverable that only says "fund this" is a sales document. Module F is the control: it demonstrates that the ranking is driven by return rather than by engineering discomfort, and it is usually the finding that earns the rest of the report its credibility with finance.
04Evidence coverage and confidence
Every finding carries the evidence behind it and a confidence grade. Where coverage is thin, the deliverable says so rather than smoothing it over.
| Evidence class | Coverage | Confidence | Gap |
|---|---|---|---|
| Interface control documents | 240 / 240 | 91% | 28 not at current revision |
| Change and defect history | 14 months | 86% | Not attributed per module |
| Source verification | 11 / 18 modules | 64% | 7 modules documentation-only |
| Design review records | 4 cycles | 82% | Cycle 2 minutes incomplete |
| Effort attribution | Program level | 48% | Dominant source of band width |
| Practitioner interviews | 6 | 78% | Supplier-side not represented |
Document classification uses a method validated in doctoral research against a panel of 35 practicing engineers, reporting Cohen's kappa 0.84 — agreement between the classifier and expert human raters — and F1 0.82 detection accuracy. Those figures describe classification reproducibility only. They say nothing about the accuracy of the cost model, which rests on the assumptions tested in section 05 and is reported as a band for that reason. The validation population was drawn from complex engineering programs; the extent to which it generalizes beyond that population is an open question addressed in the methodology brief.
05Sensitivity
A single number implies a precision the method does not have. The deliverable always presents a band and names the assumption the answer is most sensitive to.
| Assumption | Range tested | Exposure | Influence |
|---|---|---|---|
| Coupling multiplier | 1.9 – 2.9 | $262k – $363k | Dominant |
| Attributable share of effort | 64% – 76% | $291k – $345k | Moderate |
| Fully-loaded day rate | $580 – $720 | $288k – $358k | Linear, low uncertainty |
| Attainable improvement | 50% – 85% of excess | $162k – $275k recoverable | Dominant on the return side |
The conclusion — that the top three candidates are worth funding — holds across the full range of every assumption tested. What moves is the size of the prize, not the direction of the decision. That is the property that matters when the number is challenged in a budget review, and it is stated explicitly for exactly that reason.
06Ranked remediation portfolio
Ranked by return, not severity. "Do not fund" is a first-class result.
| Candidate | Excess addressed | Est. effort | Payback | Call |
|---|---|---|---|---|
| Re-partition A│B boundary | 41% | 60 d | 0.45 yr | Fund first |
| Extract shared state, module C | 23% | 45 d | 0.60 yr | Fund |
| Interface contract, C│D | 14% | 30 d | 0.66 yr | Fund if capacity |
| Consolidate module F internals | 6% | 55 d | 2.8 yr | Do not fund |
The top three address 78% of the excess for 135 engineering days, paying back inside eight months. The fourth is exactly the kind of work that gets funded on the basis of engineering discomfort and should not be.
0790-day sequence
The assessment ends with a sequence the program can execute itself. ZOYA does not deliver it, staff it, or bid on it.
- Weeks 1–2Attribute change effort at module granularityA reporting change, not an engineering one. It is the cheapest action available and it materially narrows the exposure band before any remediation is funded.
- Weeks 1–4Version the C│D interface contractLowest-effort candidate, and it stops the late-cycle defect pattern compounding while the larger work is scoped.
- Weeks 3–10Re-partition the A│B boundaryThe dominant candidate — 41% of excess for 60 days. Sequenced to complete before the next integration cycle so the effect is observable rather than inferred.
- Weeks 8–14Extract shared state from module COverlaps A│B deliberately: both touch the same teams, and running them consecutively wastes coordination cost already paid.
- Week 12Record the module F decisionAccept, with a named owner and a review date. An undocumented "we decided not to" becomes "nobody looked at it" within two staff changes.
- Week 14Re-measure against the baselineWith per-module attribution now in place, the second measurement is materially tighter than the first — and it is the point at which it becomes possible to tell whether the money worked.
08What this deliverable does not tell you
Stated at readout, in the report, in these words.
- It is not a certification artifact. Where a program certifies to DO-178C, AS9100, MIL-STD-882, ISO 26262 or IEC 62304, the assessment scores against those obligations. It is not accredited by any of them and does not replace a DER, auditor or safety assessor.
- It is a point-in-time measurement. Coupling accumulates continuously. A figure more than two or three integration cycles old should be treated as indicative.
- Documentation fidelity bounds the result. Seven of eighteen modules here were assessed from documentation alone. Where documentation has drifted from implementation, the map reflects the documented architecture — and that risk is named in the report rather than discovered later.
- It is a causal argument, not a controlled experiment. High-coupling modules cost more per unit of change. That coupling is the cause rather than a correlate of domain complexity, team experience or requirement volatility is argued from the in-organization counterfactual, not proven.
- It does not predict your outcome. The recoverable range is an estimate of attainable improvement under stated assumptions, not a guarantee that the excess disappears.
Everything above is a constructed specimen. No client engagement is described, and no figure on this page is a client result. The arithmetic is published in full in the methodology brief so that it can be checked rather than believed.
The firm measuring the debt is not selling you the rebuild.
If this is the depth you need for a budget case, a replan, or an inherited system you have just become responsible for, the assessment runs three weeks to a fixed scope. There is no implementation contract afterward, because ZOYA does not do implementation.
Start a scoping conversation