Rosetta Architectural Assessment¶
A single report for the prospective architect or tech lead asked to study and assess the Rosetta project. Snapshot date: 2026-08-29 — every version, count, and status claim is pinned to that date (platform v0.18.0 · app-server v0.5.1 / api 1.7.0 · mcp-server v0.8.9 tagged · metamodel v1.11.0); the source map records where each claim comes from and what had drifted at observation time. This report is itself a projection: where it and the repositories disagree, the repositories win.
What Rosetta is¶
Rosetta is a governed knowledge platform for Salesforce delivery, built by Keenan Vision LLC. Its founding idea is governed intent compilation: borrow the compiler's shape but target a worker instead of a machine. The knowledge of proven subject-matter experts is encoded as a canonical graph; each engagement builds a living digital twin — goals, current state, decisions with their reasons, tracked unknowns; the twin compiles into a Spec Manifest — the versioned, authorizable, auditable delivery plan; and at dispatch each work package compiles into a governed working environment for whoever picks it up, human or AI agent. Because the authors are humans and probabilistic models, compiler-style determinism is unavailable — and in its place stands governance: provenance on everything, decision traces, and a gated maturity ladder where nothing silently becomes load-bearing.
Three documents render from the same graph state for the three pairs of hands in the delivery relay — a Solution Thesis for the seller, a Statement of Work for the contracting organization, and the Spec Manifest for the human-plus-agent delivery team — so the baton passes without the knowledge degrading at each handoff.
What Rosetta is, architecturally¶
Five facts organize everything else in this report:
- One canonical graph. A Neo4j graph under a single governed metamodel (v1.11.0; ~40 node types) holds canon, engagements, decisions, and provenance. Every document — manifests, ADRs, even this report's subject matter — is a compiled projection of graph state (Chapter 2).
- A constellation, not a monorepo. Ten independently-versioned repositories — producer, API server, MCP surface, KMS/console, plugin family, advisory framework, evidence archive, ops and docs projections, and an umbrella — bound by five named cross-repo contracts and five invariants (Chapter 3, Chapter 4).
- A narrowing write path. Agents read through 43 MCP tools; write through fewer, idempotent and confirm-gated; and cannot ratify at all — the human gate is structural, enforced in three independent layers (Chapter 5 stage 6, Chapter 8).
- Three-gate governance, universally applied. Decisions are captured as traces and promoted — never authored — into ADRs, in every repo, at every altitude, including the constellation's own decisions about itself (Chapter 6).
- A measured feedback loop. Runs are ledgered with pinned toolchains and scored by versioned instruments; findings traceably become ratified decisions and shipped releases; engagement learnings graduate back into the canon (Chapter 9).
The verdict, compressed¶
(The full argument is Chapter 10.) The architecture is sound and unusually coherently executed, with self-application — the project demonstrably runs on its own machinery and publishes its own failures — as its most distinctive credential. The principal risks are organizational and operational rather than architectural: single-human concentration of ratification and operations; manual compatibility bookkeeping that lags a fast codebase; projection debt in the umbrella's own governance graph; and an evidence base that is rigorous but not yet independent. First fixes: a second ratifier, close the real-compile obligation, mechanize the compat matrix.
How to read this report¶
- In a hurry (30 minutes): this page, then Chapter 5 — the journey, then Chapter 10 — the assessment.
- Assessing seriously (a day): Chapters 1→10 in order; each ends with pointers into the deeper corpus for verification.
- Joining the project (a week): Chapter 10 §10.5 is a five-day reading map into the repositories themselves.
| 1 · This overview | What Rosetta is; the verdict, compressed |
| 2 · Domain model | The metamodel: three layers, five-field identity, the domain stack, the provenance lanes |
| 3 · Constellation | Ten repos, five contracts, five invariants, the self-engagement |
| 4 · Components | Member-by-member walk-throughs |
| 5 · The journey | The centerpiece: rosetta-core creation → delivered engagement, end to end |
| 6 · Governance | Three gates, namespaces, lanes, self-application |
| 7 · Operations | The estate, migration lanes, release trains, observability |
| 8 · Security & tenancy | Boundary, KMS, tenancy, the agent boundary, data honesty |
| 9 · Quality & evidence | Verification lanes and the empirical program |
| 10 · The assessment | Strengths, risks, what would change the verdicts, reading map |
Report provenance: authored 2026-08-29 in rosetta-meta/docs/assessment/ from the
sources inventoried in the source map; published through the
constellation docs pipeline (internal build full; public rendering, where offered,
strips internal-marked passages under the default-deny manifest). Corrections follow
the house rule: fix the source, re-render the projection.