> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ctrlrun.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# The specifications

> Six documents, one per version, each a delta over the ones before and each still binding. They live in the repository; this page says what each asked.

Every version of CTRLRun was a specification before it was code: what it must do, the
acceptance tests it is judged by, the public names it freezes, and what is deliberately out of
scope. All six are still binding in full, and nothing in a later one relaxes an earlier one.

They are written for somebody implementing against the kernel, and they are long: a hundred and
eleven thousand words between them. So they live in the repository rather than on this site,
where the pages are written for somebody using it. Read a concept page first; open a
specification when you need the contract.

| Version | The question it asked                                                                                | Document                                                                         |
| ------- | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| v0.1    | Can an action be decided, approved, executed once, and recorded?                                     | [`SPEC-v0.1.md`](https://github.com/CTRLRun/ctrlrun/blob/main/docs/SPEC-v0.1.md) |
| v0.2    | Can it work with no code change, over MCP, with reconciliation and evidence that leaves the process? | [`SPEC-v0.2.md`](https://github.com/CTRLRun/ctrlrun/blob/main/docs/SPEC-v0.2.md) |
| v0.3    | Who is acting, and what are they entitled to?                                                        | [`SPEC-v0.3.md`](https://github.com/CTRLRun/ctrlrun/blob/main/docs/SPEC-v0.3.md) |
| v0.4    | Does it hold in *my* setup?                                                                          | [`SPEC-v0.4.md`](https://github.com/CTRLRun/ctrlrun/blob/main/docs/SPEC-v0.4.md) |
| v0.5    | Can somebody else implement this?                                                                    | [`SPEC-v0.5.md`](https://github.com/CTRLRun/ctrlrun/blob/main/docs/SPEC-v0.5.md) |
| v0.6    | Does it still hold when the process dies, the host goes away, and the database is somewhere else?    | [`SPEC-v0.6.md`](https://github.com/CTRLRun/ctrlrun/blob/main/docs/SPEC-v0.6.md) |

## How to read one

Each is a delta. Start at the version that introduced what you care about, and read the
sections it names in the earlier ones: the acceptance tests are numbered continuously (`T1`
onward), the public names are frozen in a numbered section per version, and a rule that moved
says where it moved from.

Two conventions worth knowing before you open one. **MUST, MUST NOT and SHOULD are used in the
RFC 2119 sense.** And every specification carries a section on what building that version
settled, including the defects an independent review found and what was done about each: those
sections are the honest part, and they are where a reader learns what the document got wrong
before it was right.

## What is on this site instead

| You want                                           | Read                                                                                 |
| -------------------------------------------------- | ------------------------------------------------------------------------------------ |
| what a thing is, in one page                       | [Concepts](/concepts/action-and-hash)                                                |
| how to do something                                | [Guides](/guides/protect-a-function)                                                 |
| every key, flag, field and error                   | [Reference](/reference/policy-yaml)                                                  |
| what is guaranteed and what is not                 | [What verify guarantees](/security/verify-guarantees), [Threat model](/THREAT_MODEL) |
| how the guarantees are held up                     | [How this is built](/how-this-is-built)                                              |
| every README sentence, mapped to its code and test | [Claims](/CLAIMS)                                                                    |

## Next

* [Architecture](/ARCHITECTURE): how the kernel is shaped, and why.
* [How this is built](/how-this-is-built) · [Get started](/get-started/quickstart) · [Why](/why).


## Related topics

- [How this is built](/how-this-is-built.md)
- [The Agent Control Standard](/ACS.md)
- [Receipts and evidence](/concepts/receipts-and-evidence.md)
- [CTRLRun and MCP](/mcp/overview.md)
- [Receipt and event schemas](/reference/receipt-and-event-schemas.md)