Borrowed from software engineering¶
Rosetta did not invent its instruments. It borrowed some of software engineering's best ideas — deliberately, with attribution — and then customized them, because SaaS delivery breaks the assumption those ideas grew up with.
The assumption is that source is canonical. In classical software engineering, the code is the truth: check it out, build it, and you can reproduce the system anywhere. A SaaS platform like Salesforce does not work that way — the metadata is alive. You cannot take an org, cut a source artifact, and faithfully reproduce that org somewhere else; configuration, data, and history are entangled in a running system. So every engineering discipline that anchors itself to source needs a new anchor before it works here. Rosetta's answer: anchor to intent and decisions instead of code.
Architecture Decision Records — from memory to guardrail¶
The ADR is a software-engineering classic (Michael Nygard, 2011): a short record in the code repository explaining a consequential decision, so future engineers inherit the why. Rosetta keeps the idea and changes its job. Here, ADRs are first-class nodes in the knowledge graph, attached to the very patterns they govern — queryable in the middle of a live conversation, by people and by agents. In the governed lane they are not written ad hoc: a decision earns its ADR through recorded review gates. And they are enforced, not just remembered — when an implementing agent proposes to improvise around a governed decision, the ADR is what tells it no. In a code repo, an ADR explains the past. In Rosetta, it polices the present.
The Spec Manifest — the Spec Kit idea, re-aimed at SaaS¶
The Spec Manifest descends openly from the spec-driven development movement — GitHub's Spec Kit most directly, alongside kin like AWS Kiro and Tessl. That movement's core moves are all here: the specification, not the code, is the artifact that directs the work; a project constitution states the non-negotiable invariants every task must honor; and executable units of work derive from the spec rather than from someone's recollection of a meeting.
The customization is where it gets interesting. Spec Kit compiles a spec into code for a system being built from scratch; Rosetta's manifest compiles from a digital twin — an evidence-bearing model of a customer's existing, living org — into governed configuration of a platform nobody rebuilds from source. Its constitution binds probabilistic implementers, human and AI, so every clause carries provenance and its acceptance criteria come from evidence. Same engineering shape, different target: not "spec → code" but "intent → governed operator environment."
The governance rubric — supply-chain discipline for knowledge¶
The rubric that gates everything — three-class provenance, recorded decision traces, a maturity ladder with explicit promotion gates — borrows from the software supply-chain and governance-as-data tradition: W3C-style provenance records, attestation chains, policy as inspectable data rather than tribal habit. The customization: the supply chain being secured is not a package registry but a body of delivery knowledge. A pattern's journey from proposed to field-validated is tracked the way a build artifact's journey is tracked — so when an auditor asks where a recommendation came from, the answer is a record, not a recollection.
The pattern across all three is the same: keep the engineering instrument, move its object from code to intent, and add governance where determinism was lost. That is what "customized for SaaS" means here — and why the working papers describe their lineage in detail rather than claiming invention (the research).
Terms used across these pages are collected in the plain-English glossary.