Implementation (SSRA) › Authoring contract
Authoring contract
SSRA is Skills, Scripts, References, Assets, the file grammar of an engagement. The name is taken from the four directories of an Agent Skill (SKILL.md · scripts/ · references/ · assets/) and extended to the whole repository. The placement rule in one sentence: every data source
gets a tool server, every repository gets a constitution, every use case gets a skill, and hosts connect through the north gateway.
SSRA is not a layer: it is how every layer manifests as files. The skeleton (a template for every file type below) is platform scaffolding
owned in L7 and proven by the master reference project; each client's filled files are GENERATED from plane values. A new use case adds one
skill file; a new client adds one binding; a new data source adds one south server registered in the library. Everything else is stamped or pinned.
What belongs in each file, and what must stay out
The middle columns are the authoring contract, drawn from the published engineering guidance (sources S1 to S5 and S7 on the Citations page). The recurring theme: every file is either authored once and reused, or generated from values; nothing is hand-edited per client.
| SSRA component | What belongs in it | What must stay out | Authored by |
|---|---|---|---|
| Root constitution (CLAUDE.md) | Short, universal conventions that apply to every session: coding standards, repo layout, build and test commands, review rules. Written and refined like a prompt, kept brief. | Use-case logic, long reference material (link to it instead of pasting it), client values, secrets, anything that applies to only some sessions. | Platform team; single gatekeeper, proposals by PR |
| Client constitution (CLAUDE.md) | Facts generated from the binding: tenant names, gate names, stage mappings, activated use cases. | Hand edits of any kind; anything not derivable from plane values. It regenerates when the plane changes. | Generated; never hand-written |
| Skill files (SKILL.md) | One use case's procedure and output format. Supporting folders: scripts/ for executable steps, references/ for documents loaded on demand, assets/ for output templates. | Universal rules (the constitution's job), other use cases' logic, credentials, model or vendor names. | Use-case author, through the ADLC |
| Agent definitions | Exactly four things, per the published delegation research: the objective, the output format, guidance on which tools and sources to use, and clear task boundaries. Vague definitions cause duplicated and misaligned work. | Domain rules (they live in the rule library), orchestration state, business data, client names. | Solution team |
| Run contracts | A machine-checkable end state, a token budget, and an effort-scaling rule for the job class (a simple lookup warrants one worker and a handful of tool calls; a broad comparison warrants several workers). | Vague goals with no testable end state; open-ended budgets. | Use-case author; the harness enforces it |
| Slash commands (.claude/commands/) | Repeatable operational entry points: run a use case, validate, regenerate views, promote, compare variants. | Business logic or judgment of any kind. | Platform and solution teams |
| Hooks | Deterministic checks with exit codes: linting, schema validation, referential integrity, tenant isolation, eval regression, formatting. | Anything requiring judgment. A hook never calls a model. | Harness engineering |
| North-facing Platform MCP Gateway | Per-tenant endpoint configuration, tenant auth, the host allow-list, and a tool listing generated from the registry. | Hand-registered tools (the registry is the only path), business logic, per-client branches. | Harness engineering; tenant parameters from the plane |
| South-facing MCP tool servers | Tool definitions to the published tool-design standard: clear descriptions treated as prompt engineering, namespacing per source, high-signal responses, sensible pagination and truncation defaults. | Business decisions, drafting or formatting (the Smart Pipe antipattern), one-off client conditionals. | Harness and integration engineering |
| Binding (binding.yaml) | A value for every plane slot, version-controlled per engagement. | Code, prompts, or logic of any kind. Values only. | Filled during PLAN discovery |
| Ontology reference | The pinned Knowledge release ID. | Copies of ontology content; the release is referenced, never duplicated into the project. | Knowledge team releases; the plane pins |
| Eval suites & golden exemplars | Rubrics, golden exemplars, and judge prompts scoring factual accuracy, citation accuracy, completeness, source quality and tool efficiency. Around twenty queries drawn from real usage are enough to start; grow from there. | Production client data; unreviewed telemetry; anything that has not passed the data-rights clause. | Knowledge team writes the content; the harness runs it |