How To Read This

Each promise below gives you what you get in one line, how far it's proven today, and a link to the executable spec that proves it. The promise stays honest because the badge is earned by what that spec actually runs, not by what this page asserts.

• proven — a checked-in executable spec asserts the behavior end-to-end, in one of three honest sub-kinds the Honesty Audit keeps distinct (the same verdict-mode vocabulary Claim Discovery routes by):
  • deterministic — npm run lint:specs runs the command and file checks live on every run (Readiness, Claim Discovery, Reviewable Artifacts, A Testable Agent).
  • cautilus-eval — the default run replays an operator-witnessed live agent capture and a blind judge verdict; the live agent re-run is opt-in and costs a real agent run (Behavior Evaluation, Bounded Improvement).
  • human-auditable — an operator witnessed the live run and vouches for it; the default run replays the checked-in capture and the live re-run is opt-in, with no automated judge (accepted where a full deterministic or eval proof would be disproportionately costly).
• declared — the evidence exists as a saved bundle, but the behavior has not been re-run live yet (named in Proof Debt)
• promised — stated, with no executable proof attached yet (named in Proof Debt)

Today, all seven promises are proven, none are declared, and none are promised. That split is the point: this page shows the real state of the work, and the Honesty Audit binds each badge to its proof route so the split cannot quietly drift.

What Cautilus Does For You

Why You Can Trust It

Cautilus marks each promise with how far it's actually proven, and keeps that mark in plain sight. So everything on this page is the real state of the work — which is what makes the proven marks worth anything.

Honesty Audit

Every badge above is bound to its proof route, so a badge cannot claim more than its proof actually delivers. Surface Honesty Audit is the navigable, runnable per-badge map: for each promise it shows the level this page CLAIMS, the level the proof route is OBSERVED to deliver (recomputed by inspecting the leaf spec's checks and evidence files), the proof class, the command that runs it, and whether the two agree. The binding is semantic, not just structural: for every badge that declares evidence, each evidence file must actually be read by a cautilus-json-file check in its leaf spec, so a route cannot point at an unrelated spec or pad its evidence count with files the spec never asserts on. Run npm run audit:surface to regenerate it, or npm run audit:surface:check to fail on drift or over-claim; npm run lint:specs runs the leaf proofs plus the check block below. The check reads the generated audit manifest and fails specdown if any badge over-claims, if a badge's evidence is not referenced by its proof spec, or if this page and the proof-route registry disagree about which badges exist.

Proof Debt

What it would take to move each unproven promise to a live proven badge. This list is owned work, not a silent gap.

How Proof Works Here

Each subclaim on a spec page must be backed by evidence that runs the claimed behavior end-to-end and asserts on the produced packet, file, or audit artifact. These are not acceptable as the closing state of a subclaim:

• --help substring matches or other surface-existence checks that only assert a word appears in help output
• "command exists" probes that do not run the claimed scenario
• Evidence is pending placeholders left as the closing state

For each subclaim, either (a) add an executable check that runs the actual scenario and asserts on the produced packet/file, or (b) link a concrete existing evidence bundle, audit fixture, or packet path that proves that specific subclaim. If a subclaim genuinely has no evidence yet, log it as explicit proof debt above — an owned next-action that names the bundle to author — rather than letting it close as a silent omission.

Vocabulary

• A promise means something Cautilus currently says it can help with.
• A candidate claim means a possible promise found during Claim Discovery.
• evidence means a packet, fixture, command result, or durable artifact that supports a promise.
• A gap means missing or weak evidence that stays visible.
• A cross-cutting rule means a rule or risk that applies across workflows, such as host ownership, evidence visibility, or packet freshness.

Go Deeper

Everything below serves the promises above.

1. User Workflow — how people use the cautilus CLI and the cautilus-agent skill to discover, evaluate, and improve behavior against explicit evidence.
2. Contracts — the command, packet, adapter, fixture, and evidence contracts that keep the workflow buildable and reviewable.
3. Promise Ledger — which behavior claims Cautilus makes, how they relate, and which workflow or contract owns each.
4. Cross-Cutting Rules — reviewability, ownership, vocabulary, freshness, cost, and resumability rules across workflow steps.
5. Evidence State — which claims are supported now, which proof was selected instead of rerun, and which gaps remain open.

The whole pitch is simple: real evidence for every promise, and an honest mark of how far each one is proven.