# 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:

1. **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](02-domain-model.md)).
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](03-constellation.md),
   [Chapter 4](04-components.md)).
3. **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](05-journey.md) stage 6, [Chapter 8](08-security-tenancy.md)).
4. **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](06-governance.md)).
5. **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](09-quality-evidence.md)).

## The verdict, compressed

*(The full argument is [Chapter 10](10-evaluation.md).)* 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](05-journey.md),
  then [Chapter 10 — the assessment](10-evaluation.md).
- **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](index.md) | What Rosetta is; the verdict, compressed |
| [2 · Domain model](02-domain-model.md) | The metamodel: three layers, five-field identity, the domain stack, the provenance lanes |
| [3 · Constellation](03-constellation.md) | Ten repos, five contracts, five invariants, the self-engagement |
| [4 · Components](04-components.md) | Member-by-member walk-throughs |
| [5 · The journey](05-journey.md) | **The centerpiece:** rosetta-core creation → delivered engagement, end to end |
| [6 · Governance](06-governance.md) | Three gates, namespaces, lanes, self-application |
| [7 · Operations](07-operations.md) | The estate, migration lanes, release trains, observability |
| [8 · Security & tenancy](08-security-tenancy.md) | Boundary, KMS, tenancy, the agent boundary, data honesty |
| [9 · Quality & evidence](09-quality-evidence.md) | Verification lanes and the empirical program |
| [10 · The assessment](10-evaluation.md) | 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.*