# Chapter 10 — The assessment *Everything before this chapter described; this chapter judges. It is written with full candor by design — an assessment a skeptical architect can trust has to name the weaknesses with the same precision as the strengths. Verdicts are grounded in the 2026-08-29 snapshot; the drift inventory in the source map records the exact observations behind them.* ## 10.1 Verdict in one paragraph Rosetta is an unusually coherent early-stage platform: a real architecture (one canonical graph, one governed metamodel, explicit cross-repo contracts, a narrowing write path) executed with discipline that most teams several times this size do not achieve, and — its most distinctive property — governed by machinery it demonstrably applies to itself, including publishing its own failures. Its principal risks are not architectural but organizational and operational: a single ratifier and operator, a manually-maintained compatibility bookkeeping layer that lags reality, projection debt in its own governance graph, and an evidence base that is rigorous but not yet independent. An architect asked "is this sound?" should answer yes; asked "what would you fix first?" the answer is concentration and bookkeeping, not design. ## 10.2 Strengths 1. **One sovereign, consistently applied.** "The graph is canonical; every document is a projection" is not a slogan here — it decides real disputes (the codex re-render rule, the no-second-sovereign ruling, the Cypher-wins preamble), and the one fenced exception (operator-authored SOW commercial terms) is explicit and preserved rather than silently tolerated. 2. **Contracts with version discipline.** Five named cross-repo contracts, each with a version of record, an authorizing ADR trail for every bump, and — in the REST contract's entire lineage — exactly one breaking change, ratified before it shipped. The additive-bias evolution culture is visible in the record, not claimed. 3. **The narrowing write path.** Read wide (43 tools), write narrow (idempotent, confirm-gated, enum-validated), ratify human-only (enforced in three independent layers). The tool policy's completeness guard — a build failure whenever a new API tag has no conscious allow/deny decision — is a small mechanism with outsized assurance value. 4. **Provenance that does work.** The confirmed/simulated and authorship lanes are consumed by real behavior: customer renders hard-fail on unconfirmed content, the rehearsal lane is structurally quarantined, ratification flips the axes and stamps a human. Data honesty is treated as part of the threat model, which is the correct framing for this class of product. 5. **Self-application with receipts.** The project runs on its own twin, manifests, and three-gate ladder; retro findings traceably became ratified decisions and shipped, gated releases; and the system's most important known limitation was discovered by its own evaluation lane and is being answered by an open schema decision. This is the strongest form of credibility a governance platform can offer. 6. **Operational honesty.** Production migrations that cannot skip their own gates and ledger themselves; a metamodel that documents which CI job can lie to it; runbooks that record incidents and footguns rather than sanitizing them; drift logged as drift. 7. **Production is current.** Verified live at snapshot: the API estate serves the latest tagged release with both datastores healthy — the constellation's newest ratified capability (data-driven tenancy administration) is deployed, not parked. ## 10.3 Risks and open items Ordered by how much they should influence an adopter's or investor's judgment. **R1 — Single-human concentration (organizational, high).** One person is simultaneously: sole ratifier of every DT, production operator, KMS administrator, release manager, and tiebreaker. The governance machinery is disciplined but not yet independent — every `RATIFIED` is one signature. Mitigations exist in embryo (a designated-reviewer scheme for content intake; named external contributors), but the decision lanes, the estate, and the keys all funnel through one calendar. This is normal for the project's stage and it is still the top risk: the bus factor applies not just to knowledge (which the twin discipline genuinely mitigates) but to *authority*. **R2 — Bookkeeping lags reality (process, medium).** The compat matrix and roster — the constellation's load-bearing tables — were behind observed state in three rows at snapshot (a consumer release, its contract bump, and four patch releases of the console went unrecorded); the master manifest's header lags the decision record; the MCP surface has a released-but-untagged version. None of this is a correctness failure — the drift is additive and the trains were mid-flight — but a system whose central claim is "the record is the truth" must fund the record-keeping, and at snapshot the manual upkeep visibly trails a fast-moving codebase. A mechanical check (`make versions` exists; extending it to red-flag matrix rows and manifest headers) would retire most of this class. **R3 — Projection debt in the umbrella graph (governance, medium).** The constellation's own graph seed stops at its tenth decision while the markdown record runs to thirty-three; the bootstrap projections are still honestly stamped PROPOSED/SIMULATED with the re-compile obligation (ADR-RX-007) open; six accepted decisions await ADR promotion. The debt is documented by the system itself (the manifest's own open-questions section names it), which is the mitigating grace — but until the real compiler regenerates the master manifest and the seed is backfilled, the umbrella preaches a discipline (graph → projection) that its own artifacts only partially practice. This is the report's most pointed finding precisely because the claim is central. **R4 — Evidence base is rigorous but in-house (evidential, medium).** Chapter 9's boundary holds: no independent third-party lap, no paying-customer production engagement in the record, n=1 runs by design. The archive's structure is built to fix this; until it does, external claims should stay carefully scoped (the public materials, to their credit, already label the flagship engagement as simulated). **R5 — Metamodel enforcement asymmetry (technical, low-medium).** Community-edition Neo4j cannot enforce property-existence or edge-property constraints, so large parts of the identity and edge contracts are application-layer plus load-time gates. The compensations are good (39 invariant gates, apply-time 422s, corpus replay), but the enforcement story depends on every write path going through the sanctioned layers — which is also why the "MCP is the only agent write path" rule and the governed-lanes prod discipline carry real security weight. **R6 — Small drift inventory (hygiene, low).** Eleven concrete observations are logged in the source map: duplicated heading blocks in the platform manifest, stale tool counts in the plugin metadata, a broken bundle target pointing at a stub directory, conflicting comments about the internal-docs auth gate, an uncommitted engagement stack in the producer working tree, per-repo metamodel pin fields a version behind the global one. Individually trivial; collectively a maintenance-cadence signal, and an easy first sweep for a new contributor. **Watch item — override modes are ahead of their usage.** The domain-stack inheritance machinery (refine/replace/suppress) is designed, schema'd, and documented, but seed data exercises only `base`. The multi-engagement override story is therefore *designed but not yet field-proven* — worth a deliberate exercise before a customer engagement depends on it. ## 10.4 What would change these verdicts Five concrete moves, in leverage order: (1) a second ratifier with a defined scope, even narrow — the single highest-leverage de-risking available; (2) close ADR-RX-007 — run the real compile, diff to zero, backfill the seed — retiring R3 and converting the umbrella's central claim from aspiration to demonstration; (3) mechanize the matrix (extend `make versions` to fail on unrecorded releases), retiring most of R2; (4) an independently-operated lap in the evidence archive, opening the path out of R4; (5) finish the in-flight trains (the MCP tag/publish, the ADR promotions for the six eligible decisions) and sweep the R6 list. ## 10.5 Your first week studying Rosetta — a reading map For the architect this report was written for, in order: 1. **Day 1 — the frame.** This report's Chapters 1–3, then the public docs tour and the governed-intent-compilation concept page (the vocabulary in its persuasive register). 2. **Day 2 — the ground truth.** `rosetta-meta/CONSTELLATION.md` end to end, then the metamodel document's §0 (the versioned decision history) and §5 (identity). 3. **Day 3 — one engagement, for real.** The NTO engagement stack under the producer's `db/engagements/` — domain, artifacts, decision traces, spine — then the codex renders of it in the evidence archive. 4. **Day 4 — one decision, end to end.** Pick the ratification lane: read DT-RX-022, then ADR-RX-022, then the server's ratify handler and the MCP policy's denial of it, then the metamodel §0.7 state machine. That chain *is* Rosetta in miniature. 5. **Day 5 — the loop.** The evidence archive's charter and the test8 run ledger (manifest, scores, retrospective), then the bake-off retro, then DT-RX-033 — watch a finding become schema. At that point you will disagree with this report somewhere, which is the intended outcome: everything above is a projection; the graph — and the record — are canonical.