Names And Keys
Cautilus spec titles are the names readers use. A title should be clear enough to work in conversation, links, tables, and review notes.
This follows the same design pressure as a good wiki page or domain model: the name carries meaning, and a rename is a concept change unless the surrounding contract moves with it.
Names
| kind | examples | naming rule |
|---|---|---|
| workflow promise | Readiness, Claim Discovery, Behavior Evaluation, Bounded Improvement | name the user-visible job Cautilus supports |
| cross-cutting rule | Evidence Gaps, Host-Owned Execution, Packet Freshness | name the rule or risk that applies across workflows |
| proof state | Evidence Map, Proof Gaps, Latest Selected Evidence | name what the reader can inspect |
Current Aliases
| stable name | user-facing name | rule |
|---|---|---|
| Host-Owned Execution | Host Ownership | use the stable name in model and concern pages; use the user-facing name where the reader is choosing Cautilus boundaries |
Compact Keys
Tables and packets may use compact keys such as promise.readiness, rule.evidence-gaps, or gap.traceability-config.
Those keys mirror the human names and should not become the primary product language.
Rename Rule
A rename moves the title, slug, machine key, prose, packets, tests, and view mappings together. When only reader wording changes, keep the stable name and add an alias in this file.
Verify the named model and reading roots exist.
node -e 'const fs = require("node:fs"); for (const path of ["docs/specs/ledger/promise-ledger.spec.md", "docs/specs/user/index.spec.md", "docs/specs/contracts/index.spec.md", "docs/specs/rules/index.spec.md", "docs/specs/evidence/index.spec.md"]) { if (!fs.existsSync(path)) throw new Error("missing " + path); }'