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.live-batch-fixture.
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.