The single live status surface for auths-proof. Every session and agent reads this first. Update it in the same commit as the work it describes. Program definition: AP-SPEC-057. Independent baseline: How revolutionary is Auths Proof, really? (scores 3 / 6 / 4).
An unfamiliar developer puts their AI agent's Stripe refunds behind 2-of-3 manager approval and a per-agent limit in under 30 minutes, and an auditor verifies every refund offline.
Every piece of work traces to a step of this done test, or goes to Not now.
- Quickstart.
examples/stripe-refund-approval/has a README a stranger follows top to bottom in at most about ten numbered steps. It creates a root, three managers, and an agent; writes trust where refunds need 2 of 3 manager approvals (the corek_of_nplan through the approval-quorum SDK); gives the agent a grant with a bounded-policy commitment (a ceiling on the amount and a count per window); configures a gateway recipe forPOST /v1/refundswhose Stripe credential only the gateway holds; has the agent request a refund, collect two approvals, and submit through the gateway; and exports an audit bundle. - Offline audit. One command, with no network and no gateway access, verifies every refund in the bundle: the proof chain to the root, the 2-of-3 approvals, the bound, and the gateway's recorded outcome and provider evidence where available. Each refund is verified or refused with a stable code.
- Hostile cases in the same automated journey, each decided by the gateway as observed on the application socket (a witness process sees exactly one submission for the case and the gateway's answer to it; a refusal in the agent's own process fails the journey), and each refused before any credential lease with zero provider calls: 1 of 3 approvals, no manager, a repeated manager, over the ceiling, window count exhausted, a replayed operation ID, and approvals reused from another refund; and a tampered bundle the auditor detects.
- Provider. Hosted CI uses a Stripe-compatible counting double and no credentials. The README gives the exact command for Stripe test mode with the developer's own key; agents do not run it.
- Timing. The journey runs locally in minutes, and a CI job runs it from the packed Python wheel. The README records the step count and local time.
- Board. This section.
| Now | Next | Not now |
|---|---|---|
AP-SPEC-063 epic 8, consolidation: the gateway becomes the single provider-write path and the five local-agent effect profiles are removed, on branch audit-2026-09-24-gateway-epic8 (local commits, awaiting owner review and push). Epics 1–7 are merged (#181–#187), so the journey runs on §3.1's recipe with all five Stripe checks (§1). AP-SPEC-066 epic 1 (types, threats, evidence contracts) on draft PR #202, hosted CI green, awaiting owner review (§1). |
The owner states (2026-10-05) that the unfamiliar-developer cold run and the Stripe test-mode run are done; their artifact links are not recorded here yet (rule 2). AP-SPEC-066 epic 2 (production custody) starts on the owner's credential and client decisions (§9). | 060 §16 observer quorum; the witnessed did:keri adapter; 061; grant-constrained decoding; more vendor recipes; review-pass findings off this path: #145 and #147, which after epic 8 concern test-only references, and the rest of #148 (§3). |
- WIP limit: two epics in flight — one code, one evidence/docs.
- Done = an artifact link (CI run, report, commit whose diff holds the evidence). A merged spec is not done.
- Specs are written when an epic starts, not before. Backlog items get a paragraph here, no more.
- Check-ins use the five-item shape in §6. One decision per check-in.
- Commit titles:
prove,complete,independentneed the evidence in the diff (0057 §2). - No merge of PR #123 while any required check is red or while auths-field-lab pins a different SDK revision (0052 §5).
- One branch and one draft PR per epic, branched from the current HEAD of
codex/self-hosted-developer-profiles(Epic 1 stays on that branch and PR #123). Never merge, never force-push, never rewrite pushed history. - Unattended runs: decisions already in §4 are applied as written. A new
decision takes the narrower reading (fail closed, smaller claim), is
logged in §4 as
PROVISIONAL, and work continues. A decision that would widen a claim or a credential scope is not taken; it is logged in §9 as a blocker and the agent moves to the next unblocked item. - Live provider calls only through the existing field-lab
run-demo.shagainst the same disposable Airtable/Todoist resources, at most five runs per epic, only for an epic step that names a live call. Everything else is mocked. No new credentials are created or requested. - Hosted CI is the gate. While CI runs, work the next item that does not touch the same files. Three consecutive failures of the same check with no new evidence = blocker in §9, move on.
| Epic | Owner | Status | Evidence so far | Next check-in decision |
|---|---|---|---|---|
| 0057 Epic 1 — freeze on evidence | merged PR #123 | engineering merged to main; separate owner review and literal historical field-lab hosted gate remain unclaimed | PR #123 merged as a82b8ca after the owner accepted green auths-proof CI and explicitly waived field-lab CI for that merge. Local exact-wheel tests and earlier live provider read-backs were exercised; field-lab hosted green was not established. The third-adapter report remains an agent trial, not unfamiliar human adoption. |
Preserve the narrower evidence wording; do not retroactively call field-lab hosted CI or owner review complete. |
| 0057 Epic 4 — publish the evidence | none; draft PR #124 closed without merge on 2026-09-23 | stalled: the vendor corpus is on main (bindings/fixtures/openapi-corpus/); the 0057 §6 wording corrections, the GTM rewrite, and the unfamiliar-user trial are not checked on main |
Manual exact-ref CI ran; authoritative failed only on the dated-review naming allowance missing from its older base. PR #124 held the corpus, wording, and GTM revisions and was closed with no comment; branches codex/epic-4-evidence and epic-4-corpus remain. |
Owner: close Epic 4, or fold its remaining wording and GTM steps into the north-star work. The unfamiliar-user trial is the north star's "Next". |
| 0057 Epic 2 — gateway + hostile proof | merged PR #125 (2026-09-22) | done for the documented single-host development deployment; the multi-host store merged with 038 §9 (PR #143); provider qualification and AP-SPEC-053 adoption claims remain open | PR #125 was green at 90973d64 in exact-tip hosted CI. Field-lab commit fbbeb58 records the distinct-UID hostile run with three expected entries and zero unauthorized entries. Field-lab commit afa733b records fresh Airtable and Todoist writes through --mode isolated: both preflight isolation probes passed, Airtable returned observed with matching read-back, and Todoist returned response-recorded followed by independent task observation. The ledger limits this to the bound credentials, testkit trust, trusted Docker/host operator, and the single-host store. |
Do not relabel this as provider qualification or production trust; production-trust engineering is the 038 §9 row. |
| 0057 Epic 3 — signing under any principal method | merged in PR #129 (9de31899) |
engineering implemented, steps 1–6; not accepted (two human clauses) | Hosted green on Linux and macOS through the Git signing protocol workflow for steps 1–4 (runs 35782280920, and later ones at 31b640b8, 1f46f0db, 6598e168); step 6 action self-test green. Step 5 acceptance test verifies did:key, OIDC-workload, and Sigstore-keyless under one root; the live OIDC job and full CI on the final tip are recorded in the PR. Public-good Sigstore and complete workload policies are closed in code; hosted live runs are recorded in the PR. Open: dogfooding this repository and the two human adoption clauses (§9). |
Owner: decide root-key custody and branch protection for this repository. |
| 059 — commitment-bound provider evidence | merged in PR #130 (4b53cd22) |
steps 1–4 implemented; step 5 (live Airtable through the isolated gateway) open | Local: cargo test -p auths-gateway (21 unit, 1 binary), Python and TypeScript gateway client tests, public-API inventories regenerated; hosted results recorded in the PR. The claim ledger states the claim and non-claim and that the live run is not done. |
Operator: add a text field auths_echo to the disposable Airtable table, then run the isolated live journey with the updated field-lab recipe. |
| 060 — evidence-conditioned authority | merged in PR #133 (1dc213de); clients merged in PR #134 (d9c41af6); §15 merged in PR #144; §17 merged in PR #141 |
epic steps 1–4, §15 (SDK attach, Rust–Lean link), and §17 (per-extension attenuation) implemented; §16 (K-of-N observer quorum over operator domains) specified, not started | #133 full CI green on 91864f96; Rust, Go, and TypeScript agree on 148 vectors; Lean attenuation theorems registered. §15, local only: packed-wheel and packed-npm expected-before-replacement journeys pass against auths-gateway-harness (write authorized; changed value denied and stale observation indeterminate before any lease, in the SDK and at the gateway). 14 Lean refinement theorems link the 11 translated observation predicates to the model, and cargo xtask formal passes with 182 claims. SDK actions carry a bounded validity window (30 s by default, at most 300 s), so they verify at a later gateway clock. Readings are in 0060 §15.4. |
§16 is demand-gated (§3). Operator: live run. |
| 0057 Epic 5 — bounded policy in the path | merged PR #141 (step 1) and PR #149 (step 2) | engineering merged; the parts of 0025 tranches 4–6 listed in 0025 §24.3 stay open | Step 1: handler-declared per-extension attenuation laws, 163 corpus vectors on which Rust, Go, and TypeScript agree, re-qualified kernel translation, and Lean theorems that delegation never widens authority given narrowing laws. Step 2: the bounded-policy-commitment-v1 extension and link law (registry manifest 36, 173 vectors in parity); a closed gateway evaluator registry; one argument-ceiling window-count evaluator with insert-once count slots in the attempt store; Lean proofs of fixed-context tightening and decider soundness, recorded as the product-layer premise; and the per-principal hostile suite (bindings/fixtures/gateway/bounds-hostile.json), whose refused cases have zero provider entries and zero leases. Both merged to main. |
None; the open 0025 §24.3 parts are Not now unless the north star needs them. |
| AP-SPEC-056 Epics 1–2 — OpenAPI derivation | merged in PR #136 (24e1df15) |
Epics 1–2 implemented; Epic 3 (a MAY) not started, reasons in 0056 §8.3 | Local only: cargo test -p auths-openapi-derive (87-case corpus, with the pinned vendor documents present), the Python suite on a built extension, TypeScript unit, integration, and package tests on a local WASM build, a clean CPython 3.9 wheel consumer, and auths-node gateway recipe check on derived recipes. Derivation ships as its own WASM module so the runtime verifier bundle keeps its size. Vendor cases do not run in hosted CI. Hosted CI green on #136. |
Owner: review the PROVISIONAL readings in §4. |
| Queue item 7 — approval quorum ("2 of 3 managers approve") | merged PR #142 (2026-09-24) | implemented and merged; started on owner direction before Epic 5 merged | Python author_mcp_quorum_proof and TypeScript authorMcpQuorumProof project the core k_of_n plan through the new native auths-approval-quorum crate and collect one custody signature per approver. bindings/fixtures/gateway/approval-quorum.json drives the gateway hostile cases (auths-gateway quorum_tests): 1 of 3 (plan lowered to 1-of-1, or one approval missing) and a duplicate signer are denied with zero provider entries and zero credential leases; 2 of 3, 3 of 3, and 2 managers plus an outsider are authorized with exactly one entry each; an outsider beside one manager does not count; zero unauthorized entries; replay refused. Python and TypeScript author byte-identical proofs to the Rust vectors and reach the gateway's decision and code on every vector. No core change. Local only: cargo test -p auths-approval-quorum -p auths-gateway, clippy, the Python suite (the gateway-client socket tests then failed locally on the macOS path limit; since research spec 04 they use a short /tmp directory and pass on macOS: 7 failed at 5c674981, all 13 pass on branch gateway-example-and-sockets), mypy strict, pyright, ruff, TypeScript unit, integration, and package tests. |
Owner: review the PROVISIONAL readings in §4 (threshold from installed trust; approver set fixed before the first signature). |
| AP-SPEC-038 §9 — production trust for gateway, observers, Git signing | merged PR #143 (2026-09-24) | engineering merged; §9.3 human and quorum gate items open | Local: gateway, stores, custody, adapters, and Git-signing tests; PostgreSQL variants against a local TLS PostgreSQL 14; clippy, fmt, ci-plan, arch. Hosted: the PostgreSQL lifecycle workflow now runs the gateway conformance and hostile suites against its TLS fixture. Status and open items: 0038 §9.5. | Review; a second operator exercises separation and custody; decide whether to start AP-SPEC-060 §16. |
| North star — Stripe refunds behind 2-of-3 approval and a per-agent limit | merged PR #152 (2026-09-24) | journey merged; the cold run by an unfamiliar developer is open | examples/stripe-refund-approval/, auths-gateway audit, and CI job stripe-refund-journey in sdk-recipes.yml, from the packed wheel; the hostile cases and five tampered bundles run in the same journey; CI makes no Stripe calls. Readings are PROVISIONAL in §4. |
Owner: find an unfamiliar developer for the cold run (§0 Next). |
| North star — the example submits every request through the gateway | merged PR #192 (043d7a97) |
merged | examples/stripe-refund-approval/: submit sends every assembled proof to the gateway and decides no gateway rule; request drops a repeated manager, accepts --approvers "", and accepts a repeated operation ID; every outcome record carries decided_by (gateway, approver, client); the bundle keeps one entry per operation ID; request --precheck is the labelled opt-in client-side pre-check. Both journeys submit through gateway_witness.py, a separate relay process, and fail unless every hostile case is decided by the gateway on the socket; a --precheck negative control must fail that guard on every run. Local: both journeys pass; with submit faking a gateway refusal for refund-2-one-approval, the journey fails there ("the witness saw no submit frame"). Readings are PROVISIONAL in §4. |
Owner: review the §4 readings. |
| Gateway Unix sockets — a movable admin socket and errors that carry their cause (research spec 04) | merged PR #192 (043d7a97) |
merged | serve --admin-socket moves the admin socket out of a long state directory; disable, revoke, rotate, doctor (and enable, status, reobserve, operator-attest) take the same option, and its parent must be canonical, owned by the gateway's UID, and closed to group and other. Both socket paths are checked against max_socket_path_bytes() (103 on macOS, 107 on Linux, what SocketAddr::from_pathname accepts) before either bind; the admin socket binds first and a failed start removes what it bound. Bind, permission, connect, and state-directory errors keep their codes and carry the path and the operating-system cause; codes without a detail print as before. The Python and TypeScript GatewayEndpoint accept the platform maximum and report the length and the maximum. Local on macOS: cargo test --all-features -p auths-gateway (13 tests/socket_paths.rs cases, 3 listener unit tests at 103, admin_capacity and doctor_probe unchanged), clippy, the Python gateway-client tests (13 pass) and TypeScript unit tests (47 pass), and both north-star journeys. Linux's 107 is hosted evidence; a python-sdk.yml step checks the limit against the operating system on both legs of gateway-journey. Readings are PROVISIONAL in §4. |
Owner: review the §4 readings. |
North star — auths init stripe-refund-approval writes a working development enforcement point (research spec 11) |
PR #197 | implemented; hosted job stripe-refund-scaffold green (run 36520552983) |
auths init <recipe> (bindings/python/python/auths/_enforcement_init.py) checks the options, the platform, the project directory, every socket path the project binds, and the gateway binary before it writes anything, then renders the packaged templates beside the directory and renames them into place. The project's bin/ commands wrap auths-gateway and the SDK: setup, an install that takes the key only on standard input, start and stop, request, auths approve, submit, export, the offline audit, and bin/selftest, which runs spec 02's hostile table through the witness, spec 01's audit with and without --allow-unverified-refusals, eight tampered bundles and the known limit, a second install, and the key scan. auths.self_hosted gains compile_trusted_context, author_root_grant, and load_signer_file; the first two give the bytes the example's _native calls give (test_self_hosted_operator.py). CI job stripe-refund-scaffold in sdk-recipes.yml runs the project from the packed wheel. Local on macOS: the job's script end to end (50–85 s, most of it the key scan of that host's 1.5 million /tmp files), the new tests (30), ruff, mypy strict, pyright, and the public-API and wheel checks. An agent with no Auths context, given only the SDK README's paragraph, followed the generated README to a passing bin/selftest in 169 s with no blocker; its hesitations became the README's quick start, progress lines, and bin/stop socket cleanup. That is an agent trial, not the unfamiliar-developer cold run. Readings are PROVISIONAL in §4. |
Owner: review the §4 readings. |
| AP-SPEC-062 — remote approval requests (managers approve on their own devices) | merged PR #171 (2026-09-26) | implemented, epic steps 1–5; merged | bindings/fixtures/approval/remote-approval.json (Rust generator in auths-approval-quorum) covers requests, approvals, a decline, every approval.* code, the display attack in both directions, and a response signed for another envelope; Rust, Python, and TypeScript reproduce it byte for byte. auths approve ships in both packaged CLIs. The gateway hostile suite assembles every quorum case from remote responses, byte-identical to the in-process quorum. Both north-star journeys exchange requests and responses as files, with a declined manager and a tampered request, and the audit bundle lists the responses. No core or wire change. Local only; hosted results are recorded in the PR. Readings the spec had to choose are in 0062 §10. |
Owner: review the §10 readings (CLI name auths approve, per-request digest, decline custody kind). |
| North-star hardening | merged #155, #156, #157, #158, and #159 (2026-09-26) | done | The gateway Idempotency-Key for recipe writes (#146) is #156. The gateway path of #148 is #155: it zeroizes provider credentials and compares them in constant time, and #148 keeps the remaining fill(0) sites, encryption at rest, and the admin fields. The journey from the npm package is #158, which adds compileTrustedContext and authorRootGrant to the TypeScript package. The root README now leads with the journey (#157). The packed-Chromium cold-start flake that hit #153 and #158 is fixed in #159. |
None. |
| Principal status for every principal | merged PR #153 (8bf2970c) |
done | Rust, Go, and TypeScript check principal status for every principal in a branch under the anchor's policy (revocation-list semantics for delegates and actors) and agree on 184 vectors; the Go and TypeScript status selection now matches Rust. Advisory GHSA-j863-hjcq-vwj3 published 2026-09-24. | None. |
| AP-SPEC-063 — the generalized gateway | spec #178, #179, #180; epics 1–7 merged 2026-09-27/28; epic 8 on branch audit-2026-09-24-gateway-epic8 |
epics 1–7 merged; epic 8 local, awaiting review | Epic 1 case file and fixtures #181 (ADR 0013 accepted on 2026-09-28); epic 2 recipe /2 #182; epic 3 store and engine #183; epic 4 one spend limit #184; epic 5 operator plane #185; epic 6 evidence and assurance #186 (the scheduled Fuzz run with the gateway targets is the owner's to trigger); epic 7 north-star recipe with all five Stripe checks #187. Epic 8 (§12 option A) removes the five local-agent effect profiles, their routes, the journal executor, the generated clients, the SDK local-agent client, the connection administration, and the AP-SPEC-044 qualification machinery; auths-node keeps only gateway recipe check; the domain crates stay as test-only references; ADR 0012, the boundary plan, AP-SPEC-040–044, and AP-SPEC-038 Epic 6 are amended. §13 readings 1–57 are PROVISIONAL. |
Owner: review the §13 readings; the unfamiliar-developer cold run. |
| Offline audit exit status — entries without a gateway-signed outcome | merged PR #193 (88acd4af) |
done | product/runtime/auths-gateway/src/audit.rs: the unverified status, admitted on every entry, report auths.gateway-audit-report/3, and AuditReport::verdict; auths-gateway audit --allow-unverified-refusals; eight new and three updated offline_audit_* tests; both journeys audit with and without the option, detect a removed outcome, and record the option's limit under known_limits. Hosted CI green on the PR (run 36494708068) and on main with both audit fixes (run 36501045769). Advisory GHSA-4gwx-c288-m5jc published 2026-09-29. |
None. |
| Offline audit — account-scope binding | merged PR #194 (ee91b9c1) |
done | product/runtime/auths-gateway/src/audit.rs applies the recipe's account-scope binding after the per-proof observer check, as the gateway does before the claim; audit_tests.rs#audit_applies_the_account_scope_binding. Hosted CI green on the PR (run 36497853820) and on main (run 36501045769). The same advisory, GHSA-4gwx-c288-m5jc, covers it. |
None. |
| Review passes | merged PR #151 | done | docs/audit/: area prompts, verify and plan-work prompts, and settled.md. Pass records stay local. The 2026-09-23 pass filed #145–#148 and the advisory above. |
Next pass in early November. |
| Proof coverage of the decision path, measured and published (research spec 14, stages 0 and 1) | merged PR #198 (5f287db6); the mutation results follow on branch proof-coverage |
merged; results PR awaiting hosted CI and review | cargo xtask formal coverage (xtask/src/formal_coverage.rs) reproduces study 006 byte for byte at 8bf2970c from formal/coverage/pin-8bf2970c.tar.zst and publishes docs/assurance/PROOF_COVERAGE.md: 103 of 953 decision-scope functions (10.8%) and 1,201 of 10,346 code lines (11.6%) at the branch, 15 of 72 check sites. The S2 survivor Composition:21:16 is killed by threshold_antitone_k and thresholdTwo_eq_thresholdCounts; every translated function is in the refined closure (19 new refinement theorems); cargo xtask formal mutations runs S1–S3, scheduled weekly and required before a release: S1 23 of 23 killed (one first caught outside its witness, at the theorem now audited), S2 86 of 88 killed and 2 stillborn, S3 203 of 203 killed. |
Stages 2 and 3 (§3). |
| Native K-of-N approvals in the verifier kernel (research spec 10, track A with A14; AP-SPEC-065) | draft PR #200, branch kofn-approvals |
epic steps 1–10 implemented; awaiting owner review | Approval requirements are verifier-held (trusted-context keys 15 and 16, grant extension approval-requirement-v1); approvals ride in bundle key 10 and never count for the actor's own authority chain. Lean: the approval decision equals thresholdCounts, duplicates, outsiders, strays, and self-approval are irrelevant, the covering law is a narrowing law, and 7 refinement theorems link the Aeneas translation of approval_counts and the law predicates to the model. Rust, Go, and TypeScript agree on 319 corpus vectors. The approval quorum, AP-SPEC-062 remote approvals (/2), both SDKs, the gateway hostile suite, and both north-star journeys run on any 2 of 3 managers, whoever responds, including a silent third manager and a refused self-approval. |
Owner: confirm the PROVISIONAL readings of AP-SPEC-065 §14. Track B (R-C) is the next increment. |
| AP-SPEC-066 Epic 1 — freeze types, threats, and evidence contracts | draft PR #202, branch codex/production-gateway-polish |
implemented; hosted CI green; awaiting owner review. No production credential store, release verifier, runtime gate, stable code, or qualified recipe exists | Case 0008 compares Stripe, Airtable, Todoist, and Postmark (paper only). auths-connections gains the closed CredentialStoreKind, an explicit credential generation in the sealed ConnectionBinding, and CredentialBinding, the only view a credential store receives; a lease reads exactly the named generation. auths-gateway gains readiness (CredentialRetirementDelay of 20 s, checked at compile time against the 15 s transport bound; ClockTrustState; ProductionReadiness). The new crate auths-recipe-qualification holds the seven canonical qualification artifacts with their bounds; it verifies no signature. Fixtures: bindings/fixtures/gateway/production-codes.json (16 codes) and custody-hostile.json (91 cases), bindings/fixtures/qualification/schema-vectors.json (79 structural cases, 8 contract drifts) and verification-vectors.json (57 cases, pending). Two tests assert the shortfall and fail when the implementing epics land. architecture.toml gains two dependency boundaries: auths-connections reaches no workspace crate and auths-recipe-qualification reaches only auths-connections. The threat model and two plans (custody, protected run) are amended and written. Local on macOS: cargo test for auths-connections (30), auths-recipe-qualification (15), and the auths-gateway library (163 passed, 21 ignored); cargo clippy --all-targets --all-features on the three crates; cargo xtask arch and semantic-freeze, the compliance inventory, and the CI ownership check. An independent review of the first commit found no defect in the decoders and twelve findings elsewhere (two vectors with two faults, three shortfall assertions that would not have failed, two invariants stated more strongly than the types held, and smaller gaps); all are fixed on the branch. Hosted: every check green at cb09596d (CI run 37252792573, with the Python, TypeScript, SDK-recipe, gateway-isolation, and PostgreSQL workflows of the same commit); the first push failed authoritative implementation on a stale proof-coverage measurement, regenerated in 62c167a7. Readings are PROVISIONAL in 0066 §18.3. |
Owner: review 0066 §18.3; decide the 72-hour root ceremony (0066 §18.4) and the three items in §9. |
| AP-SPEC-066 Epic 2 — production custody and rotation | draft PR #203, branch gateway-production-custody |
done by its gate: the refund journey passed live against Stripe test mode on a gateway whose key is held in Secrets Manager (run 37349590113); the store contract with least privilege and the journey against the counting double passed in the same run. Hosted CI was green at 737b64d7 (68 checks) before the live jobs were added |
The engine, install, and join hold the credential store behind the trait. New crate auths-credentials-aws-secrets-manager: derived names, the store over three service calls, request signing reproduced from the service's published vectors, a one-attempt network client, three workload-identity sources. rotate-prepare / rotate-commit, retirement of the old generation after 20 s by exact generation, and rotation on a disabled connection. install --credential-store; production refuses the local file and an unknown kind; doctor reports custody apart from the observer. The store's tests drive the frozen name, version, lease, rotation, and crash vectors. A defect the new tests found is fixed: a prepared successor followed by a disable made the local store delete the serving credential. Local on macOS: auths-connections 32, auths-credentials-aws-secrets-manager 26 (live test ignored), auths-gateway 192 with default features and 193 with all; clippy and rustdoc clean. The owner created the AWS key, two OIDC roles, and the GitHub environment; no static key exists. Readings are PROVISIONAL in 0066 §19.2. |
Owner: review 0066 §19.2 and merge #203. Open for later epics: a distinct connected account (0066 §7.6), split serving and operator identities, and orphan collection. |
| AP-SPEC-066 Epic 3 — reusable recipe qualification | draft PR #204, branch recipe-qualification-verifier |
implemented in code and tests; hosted CI in progress. Nothing is qualified: no trust root, signer, or family exists and the protected run has never been started | auths-recipe-qualification gains the release verifier (all 57 frozen verification vectors driven), the evidence artifact, a closed catalogue of 36 scenarios tied to the twelve wall rows, evidence-closure verification, and the gateway semantic-closure artifact. A new crate, auths-recipe-qualification-issuance, holds proposals, the two signing roles, the differential, redaction, freshness, and signer-rotation stages, and the auths-qualification tool. auths-gateway gains the qualification gate, asked before the claim and before every lease; the deployment tuple; qualification-import, qualification-status, and the operator command qualification-reload; and installation manifest /5. Production requires qualification and pins no root yet, so it leases nothing; a build feature for tests relaxes that for the existing production suites. The protected run is .github/workflows/recipe-qualification.yml with qualification/run/ and the family contract in qualification/README.md; a test reads the workflow and fails if a pull request can reach a secret or the signing job. The signing environment exists with a required reviewer and the default branch only, and holds no secret. Local on macOS: cargo test for auths-recipe-qualification (18), auths-recipe-qualification-issuance (14), and auths-gateway (library 176 passed, 21 ignored; qualification_gate 3); workspace cargo clippy --all-targets; cargo xtask arch and semantic-freeze; the compliance inventory; the CI ownership check; assemble.sh on a throwaway family. Not shown: a protected run, a family harness, or a support-bundle scan (0066 §20.2). Readings are PROVISIONAL in 0066 §20.3. |
Owner: review 0066 §20.3; hold the root ceremony and create the release signer (0066 §20.4); decide the clock adapter and where remembered revocations live. |
Order for one agent working alone. Each row's start gate must hold before its first commit; its done gate is the only thing that moves it to §1 "done". Estimates are human-sized; an agent may finish faster, but the gates do not shrink.
| # | Epic | Start gate | Done gate | Branch |
|---|---|---|---|---|
| 1 | 0057 Epic 1 — freeze on evidence | none | PR #123 green on one commit; §D fixture identical in Python, TS, native; TS starter executes; field-lab pinned to that commit and green; the claim ledger explicitly corrects any historical title whose diff lacks its claimed evidence | codex/self-hosted-developer-profiles (PR #123) |
| 2 | Stalled: PR #124 closed unmerged (§1). 0057 Epic 4 — publish the evidence (steps 1, 3, 4 only) | Epic 1 pushed (may run while its CI runs) | corpus for GitHub + two vendor documents under bindings/fixtures/openapi-corpus/ with rejection walls; every §6 wording row in 0057 corrected at its cited location; GTM doc rewritten per 0057 Epic 4 step 4. Step 2 (unfamiliar-user trial) needs a human or a zero-context agent in a separate task; if neither is available, log in §9 |
epic-4-evidence |
| 4 | 0057 Epic 3 — signing under any principal method | Epic 1 done gate; AP-SPEC-058 written as the first commit of this epic | one verifier action accepts proofs chained to sigstore-keyless and did:key with no KERI code path; delegation commands ported; demo from three principal methods. The "twenty external repositories" clause needs humans and is logged in §9, not faked |
epic-3-signing |
| 5 | Merged (#141, #149). 0057 Epic 5 — bounded policy in the path. Step 1: AP-SPEC-060 §17 per-extension attenuation. Steps 2–3: AP-SPEC-025 §24 tranches 4–6 and the five hostile-suite cases of §24.4 | Epic 2 hostile suite passing | per-principal cases added to the hostile suite (inside A's bound, outside A's bound, inside B's bound) with zero unauthorized entries; 0025 status line names implemented tranches | epic-5-policy |
| 6 | AP-SPEC-056 implementation — done, PR #136 | Epic 2 recipe AST committed and Epic 4 corpus published | both packaged CLIs pass the whole corpus; every derived recipe passes recipe check |
epic-6-openapi-derivation (merged) |
| 7 | Merged (#142). Approval quorum in the SDK and gateway ("2 of 3 managers approve") | Epic 5 merged | Python and TypeScript expose k_of_n authorization plans as thin projections of the core AuthorizationPlan and collect member signatures; the gateway hostile suite shows 1 of 3 approvals refused before any credential lease and 2 of 3 authorized, with zero unauthorized entries. No core change |
approval-quorum |
| 8 | AP-SPEC-060 §15 — SDK attach and the Rust–Lean link. Merged (#144). | Epic 5 merged | §15.1: packed Python and npm consumers attach a read-back observation and run the expected-before-replacement journey; §15.2: refinement proofs equate each translated predicate with its model counterpart, registered in the assurance manifest | 060-sdk-attach |
| 9 | Engineering merged (PR #143), started on owner direction before its start gate; §9.3 human and quorum items open (§9). AP-SPEC-038 §9 — production trust | items 7–8 merged | the §9 acceptance: multi-host gateway store, custody, separation of duties | 038-production-trust |
-
059 / 060 are implemented and merged; see §1.
-
AP-SPEC-066 production gateway polish and recipe qualification. Draft; epic 1 is implemented (§1). Sequenced after the north-star evidence, which the owner states is done (§4, 2026-10-05); all five epics are required for its stable-launch gate: types/threats, production provider-secret custody and drain-safe rotation, recipe qualification, operator polish, and two live qualified recipes. The derived flag covers the technical subset; the unfamiliar-operator and human release reviews remain explicit human gates. KMS/PKCS#11 signing custody remains deferred under #190 and is not a launch blocker. Epics 2, 3 and 5 need new credentials (AWS workload identity, a protected qualification environment with software release-signing material, and disposable provider accounts), which is an owner decision under rule 9 (spec §15).
-
060 §16 observer quorum. Specified, not scheduled. It has value only once a second observer run by a different operator exists; today the gateway is the only observer. Start when such an operator exists. Approval quorum (queue item 7) is a different feature and needs no core change.
-
Research spec 14 stages 2 and 3 — proof coverage of the decision-critical predicates and the control flow. P2, 2 to 4 months, overlapping 061, whose rules they share. Stages 0 and 1 are in §1; the published document (
docs/assurance/PROOF_COVERAGE.md, "Next stages") carries the table below and the covering stage of every uncovered check site.Stage Scope of work Target 2. Decision-critical pure predicates The registry handlers, the composition evaluator with a Lean plan evaluator, the composition floors, the status decision, and the resource, budget, and shared-action checks, extracted as pure functions under 061 §3.4 Every deciding check study 006 found at F0 that is a pure predicate ( NumericBudgetAlgebra::attenuatesand::covers; the floors ofverify_authority_measured;status_decision) reaches F3; 0001 §6.3's plan theorems are proved; everycomposition.*andbranch.*check site whose guard is a pure predicate maps to closure functions3. Control flow 061 phase 3: the staged verifier as extractable per-stage slices Every check site of the proved configuration maps to closure functions; every refusal site is in the closure; every study class's minimum F-level is at least F2 -
061 End-to-end machine-checked verifier. Spec: AP-SPEC-061 (draft, not started). Phased codec → crypto link → control flow, with a claim sentence per phase. The 2026-09-26 feasibility spike (0001, 0002) sized it at about 2–3 months at agent speed.
- Today the pinned Aeneas translates none of
verify_v1. There are nine blocker classes, and 061 §3.4's extraction rules fix them. - libcrux fits as the verified crypto link. It needs an owner-approved RUSTSEC-2026-0173 exception, decided when phase 2 starts.
- Phases 0–1 can start now.
- Today the pinned Aeneas translates none of
-
063 Generalized gateway. Spec: AP-SPEC-063 (draft). Epics 1–7 are merged and epic 8 is in review; status is in §1. It covers per-recipe recovery capability, the provider capabilities the Stripe vertical proved necessary, one spend limit, an operator plane the application cannot interfere with, evidence and assurance, and, under the owner's §12 decision (option A, 2026-09-27), one provider-write path. §13's readings are PROVISIONAL.
-
Reads through the gateway. Read recipes, response projection (
allowed_fields,maximum_response_bytesas in 0024 §10), disclosure receipts. Confidentiality additionally needs hermetic agent egress. Folded into Epic 2 step 5. -
Grant-constrained decoding. Project the grant (enum variants, ranges, schema) into the model's structured-output grammar so the agent cannot emit an out-of-grant action. SDK helper, 2–3 wk, UX not security.
-
Reference-monitor theorem. Formal statement that for any agent function, every effect is inside the grant or no effect occurs. The novelty-axis result. After 061.
-
053 extensions the vendor corpus will demand: typed query segments, omit-when-null bodies. Decide from Epic 4's rejection walls, not before. Typed query segments also let 059 resolve an
unknowncreate. -
Multi-host gateway. Merged in PR #143: attempt, evidence, outcome, and window-count state runs on the PostgreSQL store under AP-SPEC-038 §9.1, with two-process conformance in
postgres-lifecycle.yml. The store's qualification (0038 Epic 2) is open. Connection state is shared through the store since 063 epic 5 (#185). -
Surface-area cost. Formal, kernel, gateway, bindings, and signing have grown faster than adoption. Before each new epic, name what it retires or consolidates, and track the per-PR regeneration and freeze overhead.
-
Review pass 2026-09-23. Off the north-star path, so Not now: #145 (Stripe refund recovery reads one page and matches on editable metadata; its demo releases budget on a miss; after 063 epic 8 only the demo and the reference vertical remain), #147 (PostgreSQL receipt timestamps and read-back field, now in a test-only reference), and the remaining
fill(0)sites of #148. Its small cleanups landed in #163. Settled findings are indocs/audit/settled.md. -
Review pass 2026-09-24. Merged as PRs in priority order on owner direction (§4, 2026-09-25), with no issues filed: hardening #160, cleanup #163 (which also carried the 2026-09-23 pass's small items), connection revocation #164, the Stripe reservation hold #165, admin-socket capacity #166, kernel conformance #167, CI gates #168, and status statements #169. Still open: the nightly kernel mutation job (2.5 part C); one key counted as two principals (2.7). The owner's 063 §12 decision settled the rest: 063 epic 8 removes the local agent, so its socket model (2.4), its error contract (2.8), and its journal after provider entry are moot; 063 epic 6 records the provider status in the audit; GitHub recovery and blocking I/O off async workers now concern only test-only references. Settled findings are in
docs/audit/settled.md.
| Date | Decision | Where recorded |
|---|---|---|
| 2026-09-20 | "No generic HTTP executor" → "no runtime-supplied URL/method/headers/body; declared digest-bound recipes are a different mechanism" | 0052 §1, 0024 §4/§29, f3a5757 |
| 2026-09-21 | Enum is a schema node, not a grant-level restriction; "authorized" = valid proof for the exact action under supplied trust | 0055 §1, ledger |
| 2026-09-21 | 053: gateway-validated logical operation ID in operator namespace; header allowlist; observation-only read-back; transport entry durably excluded | 053 §3.1–3.3, d6d5601 |
| 2026-09-21 | SDK confirmed ≠ lifecycle Committed; gateway records response-recorded / unknown / observed, never confirmed |
abstraction case 0007, 053 |
| 2026-09-21 | Header-borne API keys IN scope for 053/056; query, cookie, basic OUT | 0056 §3.1/§3.3 (053 wording amendment pending) |
| 2026-09-21 | Multi-host claim reuses PostgresLifecycleStore; singleton-lock limit is a 038 finding, not a new spec |
0057 §5 |
| 2026-09-21 | GTM verb is "become the format incumbents emit and accept", not "unseat" | 0057 §1, GTM doc pending Epic 4 |
| 2026-09-21 | Identity default: Sigstore keyless / OIDC workload in CI, did:key local, WebAuthn/HSM roots; KERI available, never default |
Epic 3 |
| 2026-09-21 | Reject noncanonical numeric tokens at the native canonical-wire boundary before typed projection: 1.0, 1e0, -0, leading zeros, and underscores are rejected as raw JSON; typed fields see only canonical integers. |
0057 Epic 1 adversarial fixture; owner confirmed |
| 2026-09-21 | AP-SPEC-056 --closed root spelling remains an unvalidated candidate; the mapper must reject an ambiguous body alias versus absolute JSON pointer rather than guessing. |
Epic 4 corpus; owner confirmed |
| 2026-09-21 | The vendor corpus is a digest-pinned manifest with measured operation rejections, not committed multi-megabyte upstream bundles; mapper parity requires exact local source bytes. | Epic 4 corpus; owner confirmed |
| 2026-09-21 | Preserve pushed history for 9b31882; resolve its overclaiming title with an explicit forward correction in the claim ledger, which becomes the Epic 1 title-audit gate. |
AP-SPEC-057 §2; claim ledger |
| 2026-09-21 | For PR #123's engineering handoff, stop pursuing auths-field-lab CI: the billing annotation is confined to that repo, while exact auths-proof CI is green and the demos passed local exact-wheel tests and live read-back. This owner direction does not itself amend AP-SPEC-057 Epic 1's stricter hosted-demo acceptance. |
Owner direction; 0051 §10 and acceptance review |
| 2026-09-22 | The owner merged PR #123 on green auths-proof CI, waived field-lab CI for that merge, and directed gateway work from updated main. This permits Epic 2 to start without relabeling the historical field-lab hosted gate as passed; owner review and unfamiliar-user evidence stay open. | Owner direction; merged a82b8ca; AP-SPEC-053 |
| 2026-09-22 | Audited AP-SPEC-050–057 against merged main, the current gateway branch, their acceptance clauses, and recorded hosted/live evidence: 050 is partial, 051/052/054 retain review gates, 053 is partial, 055 is implemented, 056 remains unimplemented, and 057 is active with only Epic 2 complete in its bounded scope. |
AP-SPEC-050–057 status headers; this board |
| 2026-09-22 | Owner directed AP-SPEC-058 to be written as Epic 3's first commit. That starts Epic 3 at the spec step only. Epic 1's historical field-lab hosted gate and owner review stay unclaimed. auths.git-signature/1 is a new profile, separate from auths.git/1; the proof binds the unsigned payload digest, not the object ID; trust must come from outside the verified range; revocation applies where the record is present; verification is gate-time. |
0058 §§3.1–3.5, §8 |
| 2026-09-22 | Owner directed AP-SPEC-059, 060, and 061 to be written as drafts before their epics start, overriding the §5 "not doing" row, whose reason (no gateway) no longer holds. Writing a spec does not start an epic; the WIP limit still governs implementation. 059 keeps the 053 idempotency key and adds an echo field; 060 is a core wire change with observers separate from authority anchors; 061 phases 0–1 may start before 059/060. | 0059 §2, 0060 §3.3, 0061 §8 |
| 2026-09-22 | Owner directed Epic 3 implementation to start, which waives Epic 1's done gate for Epic 3 only, as the owner did for the #123 merge; Epic 1's historical field-lab hosted gate and owner review stay unclaimed. Step 1 fixed the envelope frame with explicit lengths and raised the armored limit to 200 KiB so both fields fit at their limits. | 0058 §3.3, §3.6 |
| 2026-09-23 | Owner directed 059 implementation after Epic 3 merged (#129). observed-by-provider requires the exact token and the verified value; the idempotency key stays per 053; readings are in 0059 §7.1. |
0059 §2, §7.1 |
| 2026-09-23 | Owner directed spec amendments with no shortcuts: 0038 §9 (gateway, observer, and Git signing in the production substrate; separation of duties; K-of-N observer quorum); 0060 §15 (SDK attach, Rust–Lean link), §16 (K-of-N observer quorum counted per operator domain), and §17 (per-extension attenuation, which lets delegates add observation requirements and narrow policy bounds); 0025 §24 (the tranches Epic 5 needs, using §17). Epic 5 now depends on 0060 §17. | 0038 §9, 0060 §15–§17, 0025 §24 |
| 2026-09-23 | PROVISIONAL, taken unattended as the narrower readings: the AP-SPEC-056 mapper spells the root body .; records minLength above 1, pattern, and format as unenforced; treats anyOf [T, null] as nullable and resolves it only by --pick; splits server base paths into fixed segments and drops one trailing slash; takes operator_namespace from a required --operator-namespace flag; writes recipe.json; reads JSON only; flattens nested closed objects to _-joined root fields because the compiler accepts root scalars only; makes --max-items unusable until the compiler accepts arrays; lets --max-bytes only narrow maxLength; refuses an override name shared by a parameter and a body property; and refuses to derive an operation declared security: []. |
0056 §8.1 |
| 2026-09-23 | PROVISIONAL, taken as the narrower readings for queue item 7, which the owner directed to start before Epic 5 merged: the quorum threshold and membership come only from the operator's installed trusted context (members are depth-zero trust anchors; k authorized branches from k distinct actors), never from the proof-carried plan; the approver set is fixed before the first signature, because each envelope commits to the plan identifier and the verifier requires a signed action for every plan leaf, so every listed approver must sign and replacing a declining approver is a new proposal. Letting unsigned leaves count as absent would be a core verifier change and was not made. |
docs/product/APPROVAL_QUORUM.md; auths-approval-quorum |
| 2026-09-24 | Owner decision: the approval-quorum action window is configurable with a default of 24 hours, so human approvers are not held to minutes. The default is held only in auths-approval-quorum; the single-signer 30 s default and 300 s cap in auths-author are unchanged. The window is cut to the earliest approver grant expiry, custody requests stay valid for the whole window, and core ActionValidityPolicy is the one place the window arithmetic lives. |
auths-approval-quorum; auths-author; docs/product/APPROVAL_QUORUM.md |
| 2026-09-24 | PROVISIONAL: the approval-quorum window is bounded at 7 days (604 800 s). The owner fixed only the default. | auths-approval-quorum |
| 2026-09-23 | PROVISIONAL, taken unattended for 0060 §15: mcp-arguments-v1 moves from the gateway to auths-profile-mcp. The Python and WASM verifiers now carry two configurations, their own and mcp-arguments-v1, and the configuration a trusted context pins selects one, so SDK authoring reaches the same verdict as the gateway. The gateway test harness becomes a feature-gated process (testkit-harness) speaking the shared application-socket module. A changed record is shown both as refused by the SDK and as denied by the gateway for an agent that skips the SDK's check. |
0060 §15.4 |
| 2026-09-23 | Owner decision (2026-09-23) for 0060 §15, keeping the 30 s default: an SDK-prepared action is valid for validity_seconds after its evaluation time. The default is 30 s and the cap is 300 s, both held only in auths-author, and the window is cut to the terminal grant's expiry, so live SDK actions verify at a real gateway clock. The window is not a replay defence: the gateway's durable claim per namespace and operation ID is, inside and after the window. The challenge binds the deployment, and observation max_age is still judged at the gateway's clock. |
0060 §15.4 reading 7 |
| 2026-09-24 | PROVISIONAL, taken on owner direction for the §0 north-star journey, each the narrowest reading that makes it work: (1) the gateway admits a composed proof in which exactly one authorized branch carries bounds, keying the count to that branch's actor; two bounded branches stay refused as gateway.policy.multiple-branches. (2) "2 of 3 managers" for an agent is installed as three authorized approvals from three distinct roots under anchors {root, manager A, B, C}; the agent's root counts once, so two must be managers. Three managers without the agent also meet it, with no agent bound; the README says so. (3) The CI provider double is reached only through a loopback-provider cargo feature that the default gateway build lacks. (4) auths-gateway audit evaluates each entry at the gateway-signed outcome time (or the approvals' start without one) and recounts windows in that order; it cannot prove the bundle complete. |
0025 §25 reading 10; examples/stripe-refund-approval/README.md |
| 2026-09-24 | Owner decision: principal status applies to every principal in an authority branch (the trust anchor and every grant subject, which covers issuers and the actor), under the selected trust anchor's status policy. The anchor still needs a statement; for delegates and actors the snapshot is a revocation list: no statement under a fresh snapshot is active, and revoked or superseded denies. Chosen over requiring a statement for every principal, which would add a second renewed statement per principal on top of the one each grant already needs, and count every principal against the 512-statement limit. The Rust, Go, and TypeScript verifiers and the corpus change in the same PR as this spec text. |
core/spec/v1/verification-algorithm.md "Principal status"; core/spec/v1/protocol.md "Evidence and status"; 0002 §14 |
| 2026-09-24 | Owner directed the north-star hardening to run in parallel, above the WIP limit of two: build the gateway Idempotency-Key for recipe writes (#146), reversing the earlier "correct the docs" reading because the journey now sends Stripe refunds through a recipe; the gateway path of #148; and the journey from the npm package. |
§0, §1; #146; #148 |
| 2026-09-24 | Owner: review-pass records under docs/audit/passes/ stay local and are ignored by git; a finding that changes the design becomes a spec under docs/specs/. |
docs/audit/README.md; PR #151 |
| 2026-09-24 | PROVISIONAL: advisory GHSA-j863-hjcq-vwj3 names the affected product auths-dev/auths-proof (main before 8bf2970c), not the crates.io auths-verifier 0.1.x releases, which come from the separate auths-dev/auths repository. |
the advisory |
| 2026-09-25 | Owner decision: a trusted-context template has one assembly, auths_registries::TrustedContextTemplate. The Rust SDK's TrustedContextBuilder wraps it with its public API unchanged, and the WASM package compiles through it, so the npm journey adds no second copy in a binding. |
#158; core/crates/auths-registries/src/template.rs |
| 2026-09-25 | Owner directed fixing the packed-Chromium cold-start flake now: the check takes five cold starts, each in a fresh browser context, and holds their median to the unchanged 150 ms × 1.25 budget. | #159; bindings/typescript/test/package/packed-browser.mjs |
| 2026-09-25 | Owner direction: the 2026-09-24 review pass is implemented as PRs in priority order, without filing public issues; a security weakness goes to a private advisory first. Decisions inside that work that the owner has not taken follow rule 8 (narrower reading, logged PROVISIONAL). | §3 "Review pass 2026-09-24"; docs/audit/settled.md |
| 2026-09-25 | PROVISIONAL, taken unattended as the narrower readings for package 2.5 (kernel conformance) of the 2026-09-24 review, whose check-precedence decision the owner delegated: native's current order is codified, and only the attachment-limit line changes in Rust. (1) The canonical action is decoded, with its input, body, and detached-attachment bounds, before the proof, and a failure there carries no plan digest. The Go and TypeScript verifiers decode it the same way and return the native codes: fields read in key order, each bound checked as its field is read, the canonical encoding checked last. (2) Detached attachments are bounded by the aggregate attachment limit, as the spec and CDDL already said; native used the bundle limit, which denied attachments between the two limits and ignored a lowered attachment limit in process. (3) One check precedence, native's: decode (context, canonical action, proof), reference resolution, principal control (registry manifest and configuration first), action binding before any branch, authority branches, then plan and composition. Binding runs the carried body, each action's fields, profile, audience, challenge, evaluation time, channel, shared meaning, extensions, and observation attachments, then attachments, then the profile policy. Each branch runs root control, anchor acceptance, statuses (the anchor, then each grant's status and subject), the resource matcher, namespaces, the budget chain, the delegation walk, terminal coverage, the action's control, assurance, and observation. A statement's control failure is deferred to the branch that needs it. (4) Every grant permission's resource, not only the action's, must lie inside the anchor's namespaces, as native requires. (5) A budget algebra is resolved only where a bounded ceiling is compared, and a value in another algebra is local-policy-denied, the algebra rejecting its input; Go and TypeScript had resolved every algebra up front, including those of unrelated anchors, and returned indeterminate. (6) For a grant after the first, the observation-requirement drop check and the attenuation laws run before any handler evaluates the grant's extensions, so a malformed or over-limit child payload is observation-requirement-dropped under a parent with requirements and delegation-expanded otherwise, never the handler's code; protocol.md now defers to the per-extension laws instead of byte-for-byte preservation. |
core/spec/v1/verification-algorithm.md "Stages"; core/spec/v1/registry.md "Attenuation laws"; core/spec/v1/protocol.md "Trust anchor", "Grant"; core/spec/v1/error-codes.md; docs/LIMIT_COVERAGE.md |
| 2026-09-25 | PROVISIONAL, taken unattended as the narrower readings for package 2.6 (status statements) of the 2026-09-24 review, whose purpose decision the owner left open: (1) purpose is removed from principal-status statements rather than given purpose-scoped selection, which would add role semantics no spec defines. The wire loses key 3 and the later keys move down one, one direct cutover with no reader for the old shape (a ten-entry statement is malformed-proof); the carried-status rollback check keys on the principal alone, as selection does; the Python and WASM authoring APIs and the TypeScript engine contract drop the argument. (2) The accepted-extension rule covers every statement about a principal or grant whose status a branch evaluates, whatever its method or issuer and whether or not selection would pick it, checked after the statement's control and before selection; statements about subjects the branch does not evaluate are not checked. (3) As for actions and grants, the first extension in canonical order decides: an identifier the context does not accept is critical-extension-unknown, an accepted one unsupported-critical-extension. (4) No registered extension, exact-marker-v1 included, has a status handler, so an accepted extension on an evaluated status statement is never evaluated and is always unsupported-critical-extension; a status extension needs a protocol review, an executable model, and a new manifest. |
core/spec/v1/protocol.md "Evidence and status"; core/spec/v1/verification-algorithm.md "Principal status", "Grant status"; core/spec/v1/registry.md "Status-statement extensions"; core/spec/v1/auths-proof.cddl |
| 2026-09-25 | Owner directed AP-SPEC-063 (the generalized gateway) to be written as a draft before its epic starts. Writing it does not start an epic; the WIP limit still governs. The single-provider-write-path choice is left to the owner (§12), and §13's readings are PROVISIONAL. | 0063 §12, §13 |
| 2026-09-28 | PROVISIONAL, taken unattended for AP-SPEC-063 Epic 7 as the narrower readings: the four refusals after the credential lease run as a second agent with its own grant, so the agent keeps two refunds per UTC day; the rejected refund names an already-refunded PaymentIntent, since a missing one now fails the relative-ceiling read before any write; the non-test key is refused at install; install --loopback-provider exists only in the loopback-provider build; the profile keeps version 1 as a clean cutover; and the denied reads stay, failing closed at install if Stripe's refusals omit Stripe-Version. |
0063 §13 readings 46–51 |
| 2026-09-28 | PROVISIONAL, taken unattended for AP-SPEC-063 epic 8 as the narrower readings: auths-node keeps only the operator gateway recipe check, since public naming reserves the binary; the AP-SPEC-044 qualification machinery goes with the profiles it qualifies; the domain crates' production-only modules (connection onboarding, the Stripe evidence reader, the preflight stores, the OpenTofu protected executor, the profile error fragments) go, while evaluators, fixtures, Kani harnesses, and demos stay; the SDKs' local-agent client and its registry codes go; and shared code only the local agent used goes, each crate keeping its other consumers' surface. |
0063 §13 readings 52–56 |
| 2026-09-28 | Owner decision: epic 8 deletes the live provider qualification machinery with the profiles. PROVISIONAL, taken as the narrower reading: the stable-launch blocker second-qualified-effect-vertical becomes second-qualified-recipe, so stable launch stays blocked until two recipes earn a qualified claim under ADR 0013's rule, whatever the owner settles that rule to be. |
0063 §13 reading 57; release/evolution-policy-v1.json |
| 2026-09-28 | Owner decision: ADR 0013 is accepted. No recipe is called qualified; a recipe earns a qualified provider claim only through a later ADR that names its digest family, keeps the vertical's evaluator and fixtures as a test-only oracle, shows differential agreement on the vertical's corpus, cites hosted evidence from a live provider contract, and specifies that evidence pipeline. | ADR 0013 |
| 2026-09-28 | Owner decision: AP-SPEC-038 Epic 4 (KMS and PKCS#11 custody clients in the shipped gateway and Git binaries) is deferred and is not a launch blocker; tracked in #190. Until it lands, a production gateway cannot sign outcomes, and the north-star README and claim ledger say so. | 038 Epic 4; #190 |
| 2026-09-28 | Owner decision: AP-SPEC-064 (non-HTTP gateway transports) is parked, unmerged; its reasons are at the top of the spec on the closed PR #189. | #189 |
| 2026-09-28 | Owner decisions for the offline audit's exit status: (1) the fix goes through a public pull request, and an advisory is published when it merges, as for GHSA-j863-hjcq-vwj3 and GHSA-w6ch-6r34-wjxp. (2) An entry without a gateway-signed outcome is reported unverified, never verified or refused; refused needs a signed not-entered outcome, every entry reports admitted, and the report schema is auths.gateway-audit-report/3, with no reader of /2. (3) auths-gateway audit exits non-zero on any unverified entry by default (audit.unverified, exit status 1 like every other failure); --allow-unverified-refusals passes one only when the audit itself refuses its proof, and no option passes an unverified entry whose proof verifies. (4) The gateway still signs nothing for a refusal made before the claim, and an empty bundle still passes. (5) North star step 2 keeps its wording and is not met while refusals made before the claim carry no signed outcome: the audit reports them unverified, not refused. With the custody client of AP-SPEC-038 Epic 4 deferred, a production gateway signs no outcomes, so its bundles fail the audit. |
product/runtime/auths-gateway/src/audit.rs; examples/stripe-refund-approval/README.md; docs/audit/settled.md |
| 2026-09-29 | Owner decision: the audit's missing account-scope binding, found while fixing the exit status, ships as its own public pull request stacked on the exit-status fix (#193), and one advisory covers both fixes, published once both merge. | product/runtime/auths-gateway/src/audit.rs |
| 2026-09-27 | Owner decision on AP-SPEC-063 §12: option A. The gateway becomes the single provider-write path. Epic 8 removes the five local-agent effect profiles in one cutover, and the PostgreSQL and OpenTofu production paths end with them, since they have no HTTP equivalent. The domain crates stay as test-only references, and §12's table lists what production gives up. | 0063 §12, §15 |
| 2026-09-26 | The owner delegated the choice between two fixes. Taken: when protected-base translation evidence is missing, formal translation runs two clean reproductions in the same job, rather than also reusing base runs where only the translation job succeeded. Six of the last eight main push runs were cancelled by newer merges, which the second fix cannot cover. Evidence that is found but fails binding still fails the job, and every pull-request reproduction still packages generated drift. |
docs/ci/formal-translation-evidence.md; .github/workflows/ci.yml |
| 2026-09-26 | The owner delegated whether formal Lean authoritative fails when it packages an assurance update. Taken: it fails, as formal translation does, so the job that found the drift is the red one; the formal-translation gate and CI qualified were already red, and the updater keys off the update artifact, not job status. The job now declares the update_required output that formal evidence gates on, so aggregation is skipped instead of failing on a missing Lean artifact, and xtask requires both. |
.github/workflows/ci.yml; xtask/src/formal_qualification.rs |
| 2026-09-28 | PROVISIONAL, taken unattended for research spec 02 (the Stripe refund example sends every request through the gateway) as the narrower readings: (1) the example keeps a client-side pre-check only as the opt-in request --precheck, off by default, labelled "client-side; not an enforcement boundary" (the spec's default for its open question 1); (2) decided_by stays in the example, not in the SDK (question 2), and the gateway still signs no outcome for a denied submission (question 3), and declined or incomplete collections are not submitted as a partial quorum (question 4); (3) the codes pinned from the local run, to be confirmed by hosted CI (question 5): no manager is denied composition-requirement-not-met, and refund-1's proof sent with another refund's action is denied action-body-mismatch; a refund-1 resubmission with fresh approvals is not-entered gateway.attempt.replay, and a refused refund requested again after the window filled is not-entered gateway.policy.window-exhausted with its bundle entry replaced; (4) gateway_witness.py stays in the example, not in auths.testkit (question 6); (5) the guard covers every gateway-decided case the journeys run, the permitted refunds and the pre-existing scope, sum, and after-lease checks included, not only the spec's table; (6) a non-gateway record lists unmatched responses as [index, code] pairs, so no code key appears anywhere in it; (7) the pre-check reports repeated-approver before approvals-below-threshold before above-ceiling; (8) the TypeScript refunds.js --help carries the pre-check text, since parseArgs has no per-flag help; (9) superseded on merging spec 01 (PR #193), with the owner's decisions of 2026-09-29 below: the journeys follow spec 01's audit as merged, so the entries the gateway refused before its claim (one approval, no manager, above the ceiling, the unlisted account) are unverified with admitted: false, the default audit fails with audit.unverified, and --allow-unverified-refusals passes; the repeated-manager entry is replaced by its retry's signed outcome and audits refused gateway.policy.window-exhausted; README step 8 combines spec 02's one-entry-per-operation-ID rule with spec 01's account of entries without a signed outcome. |
research spec 02; examples/stripe-refund-approval/ |
| 2026-09-28 | PROVISIONAL, taken unattended for research spec 04 (gateway Unix sockets) as the narrower readings: (1) new codes gateway.serve.app-socket-too-long, gateway.serve.admin-socket-too-long, gateway.serve.invalid-admin-socket, and gateway.serve.unsafe-admin-socket-directory; a detail follows the code on the same line as <code> path=<path>: <cause>, the code stays the first token, and a detail holds only paths, lengths, modes, UIDs, and operating-system errors; (2) the default admin socket stays <state-dir>/admin.sock, and operators repeat --admin-socket on every admin command, with no environment variable and no recorded file (the spec's defaults for its open questions 1 and 2); (3) clients report an over-limit path, a failed path or directory check, and a listener running as neither their own UID nor root under their existing *.socket-unavailable code with a detail, not new codes (question 3); (4) the SDKs keep their early check in GatewayEndpoint with the platform maximum (question 4); (5) the peer-UID check in admin clients is always on and fails closed before any frame is written; (6) --admin-socket also goes on enable, status, reobserve, and operator-attest, which reach the same socket; (7) the path and directory checks also apply to the default location; (8) doctor, which runs as root, checks a moved admin socket's parent against the state directory owner's UID; (9) the TypeScript GatewayProtocolError also carries the path and error, for binding agreement; (10) the operating-system limit step runs on both legs of gateway-journey, not only macOS. |
research spec 04; product/runtime/auths-gateway/ |
| 2026-09-29 | Owner decision, on merging spec 01 (PR #193) into PR #192: (1) an entry without a signed outcome, for a refusal the gateway made before its claim, may be replaced in the audit bundle by a later signed refusal for the same operation ID, and then audits as refused; (2) README step 9 counts four refusals made before the claim (one approval, no manager, above the ceiling, the unlisted account), not three, and the README's "What this does not claim" list stays in step with that count. |
PR #192; examples/stripe-refund-approval/README.md |
| 2026-09-29 | Owner decisions for research spec 11 (auths init <recipe>): take the spec's proposals for its open questions, so the command is auths init <recipe> beside the profile scaffold, the three Python functions are public in auths.self_hosted, the project is thin generated scripts over the existing commands, the Stripe double is copied from the example and a byte-equality test keeps the copies aligned, and auths init stops after writing files; and the project pins the gateway binary by sha256 and refuses a different one (auths.gateway.changed). Open question 9, the second production path, stays open. |
research spec 11; bindings/python/python/auths/_enforcement_init.py |
| 2026-09-29 | PROVISIONAL, taken unattended for research spec 11 as the narrower readings: (1) the gateway's admin socket is run/admin.sock through serve --admin-socket (spec 04, merged in #192), so auths init checks run/app.sock, run/admin.sock, and the self-test's run/relay.sock against 103 bytes on macOS and 107 on Linux and against the SDK endpoint's limit; (2) the command code lives in lib/ beside the layout's app/refund_client.py, and bin/* run Python with -B, so no bytecode directory escapes the explicit modes; (3) dev/gateway_witness.py is a byte-identical copy of the example's witness, like the double, since a generated project must not need a checkout (the spec preferred reuse); (4) enforcement.toml holds only tables and key = value lines whose values are JSON literals, so the project reads it without a TOML parser on Python 3.9 and 3.10; (5) open question 5 is already answered by the recipe: the gateway refuses at install a key without its rk_test_ prefix (gateway.install.credential-guard), so no wrapper checks a prefix and the CI key is rk_test_mock_…; (6) the parameters add the example's --sum-limit (6 000) and --currencies (eur,usd), and --platform-account and --connect-account, required in stripe-test mode and refused in double mode, which uses the double's accounts; (7) bin/selftest runs only in double mode, on a fresh project, with the example's approvals, ceiling, count, and sum and a window of at least an hour; it runs spec 02's before-lease table and negative control, and the after-lease checks, which need a second agent, stay in the example's journey; (8) the key scan needs AUTHS_SELFTEST_KEY_FILE and fails closed without it; it reads every project file outside enforcement/gateway/ and the $TMPDIR and /tmp files whose mtime or ctime is after the start; the second-install check pipes a value that is not a key, so the key file is read only for the scan; (9) every directory the project creates is 0700, its root included; (10) bin/audit passes the gateway's report, standard error, and exit status through, and when the gateway prints no report (for example audit.trust-pin-mismatch) it prints {"error": code} so that every command prints one JSON object; (11) the study's three tamper cases act on entered refunds: one character changed in refund-1's longest string, refund-1's entry duplicated, and refund-1's and refund-4's evidence swapped; their findings are recorded, not pinned, while the example's four keep the journey's pinned codes; (12) in double mode bin/install-gateway records the double's token digest only after the install succeeds, and stops a double it started for a failed install; (13) bin/start starts the double and the gateway together and waits for the application socket and the gateway's ready line. |
research spec 11; bindings/python/python/auths/_templates/stripe-refund-approval/ |
| 2026-09-29 | PROVISIONAL, taken for research spec 14 (proof coverage) on owner direction and as the narrower readings: (1) Q1: AP-SPEC-001 §5.2's values are theorems — thresholdTwo is authorized at k = 0 (threshold_zero_authorized) and denied for two inputs at k ≥ 3 (threshold_above_inputs_denied), which changes the Lean helper's wildcard arm; Rust (threshold_counts, and plan validation rejecting k = 0 and k above the member count), Go, and TypeScript already gave these values, so no verifier behaviour, code, or vector changed, and auths-composition gains a regression test; (2) Q2 and Q4: both measures are kept — study 006's scope and roles for the headline, the check-site map for the decision-critical figure — and auths-registries/src/template.rs is decision logic, the reading with the smaller figure; (3) Q3: the macro-generated identifier accessors stay in the headline, as the study counted them, and the document gives the figure without them; (4) Q5: the mutation job reports and fails on an unexplained survivor, runs weekly and on dispatch, never on pull requests, and release-check requires current results with every survivor fixed or explained; (5) the committed document cannot name its own commit, so it names "the commit that contains this document" with the digest of its inputs, and a release binds the revision in its assurance evidence; (6) the kinds of the theorems added since the study (35) were classified by the implementing agent, not two raters, and the document says so; (7) S1 reuses study 006's 23 reviewed edits (formal/s1-mutation-edits-v1.json). |
docs/assurance/PROOF_COVERAGE.md; formal/coverage-scope-v1.toml; formal/theorem-kinds-v1.toml |
| 2026-09-29 | PROVISIONAL, taken as the recommended readings of the auths-research proposal "03. Status issuer scope" (study 005, H5), which the owner directed to be implemented: each status trust rule carries a required scope (own, anchors, or any), and a statement whose issuer's scope does not cover the branch's anchor takes no part in that branch's status evaluation and returns no code (D1), whatever its method (D2). An issuer no rule names still fails closed (D3); selection among in-scope issuers is unchanged (S1, D4); the carried-status rollback check keys on subject, method, and issuer (D5), reversing reading (1) of the 2026-09-25 status-statements row; the accepted-extension check covers in-scope statements only, narrowing its reading (2); an inconsistent scope makes the context invalid (D6). The registry manifest is not bumped: a pre-change context with a rule no longer decodes, and one without rules evaluates identically. |
AP-SPEC-064; core/spec/v1 |
| 2026-09-29 | PROVISIONAL, taken as the recommended readings of the auths-research proposal "05. Reason-code conformance" (study 005, H2): stage 2, step 9 runs every rollback check before any holding check, which is native's order, so the Go and TypeScript verifiers changed. The canonical-action decode checks are named check sites, each pinned by a raw-byte corpus vector marked "encoding": "raw". The check precedence recorded on 2026-09-25 stays PROVISIONAL: its ratification is the owner's, and until then every two-fault vector, including the two added here, pins a provisional order. |
core/spec/v1/verification-algorithm.md; bindings/independent/README.md |
| 2026-09-30 | Owner decisions on research spec 10's open questions: (1) an approval binds the approval requirement's identifier; (2) no principal in the authority chain may count as an approver, the rule of observer-in-authority-chain; (3) invalid approvals are ignored, never denying; (4–6) track B takes R-C — formulas with and, or, and not, a new bool attribute type, and verifier-context conditions (key 17) — in a later pull request; (7) grant-carried approval requirements (A14) are in the first release; (8) the proposed limits are accepted; (9) the trusted context's approval requirement is the authoritative quorum configuration, so the threat model's exact-plan wording and the quorum helper's floors go as a clean cutover. |
AP-SPEC-065 §14 |
| 2026-09-30 | PROVISIONAL, taken as the narrower readings for AP-SPEC-065 (native K-of-N approvals): the spec is 065 because 063 and 064 are taken; the authority principals excluded as approvers are every grant issuer and subject and every actor in the proof; approver anchors carry a status policy and only status issuers with scope any (or unknown to the snapshot) speak about an approver; stage 3's signature classification decides pending versus ignored; per-approval checks run equality, then signature, then status; an approver already counted is not verified again; each requirement is evaluated once per verification (at most 64); grant-carried requirements are evaluated per branch after the observation stage, each under its own identifier, with dropping or widening refused as delegation-expanded by the extension law; an unanchored approver's approvals are skipped; approval-context-invalid is a context-constructor conformance case, not a corpus vector; approval statement key 8 is compared with null until track B. |
AP-SPEC-065 §14, readings 10–23 |
| 2026-10-05 | Owner decision for AP-SPEC-066: production provider-secret custody, drain-safe rotation, recipe qualification, operator polish and two live qualified recipes remain stable-launch work. KMS/PKCS#11 custody for Auths root, observer, Git and qualification signing keys remains deferred under #190 and is not a launch blocker. Launch qualification uses a separately labelled protected software release signer authorized and revocable by an offline qualification trust root; it makes no hardware-custody claim. Human boundary review remains a release judgment, not a machine-derived or cryptographic independence claim. | AP-SPEC-066 §§6–8, §14–§15; #190 |
| 2026-10-05 | Owner decisions for AP-SPEC-066 epic 1: (1) the start gate of 0066 §15 step 1 is met — the owner states the Stripe test-mode run and the unfamiliar-developer trial are done; their artifact links are not recorded on this board; (2) the sealed ConnectionBinding carries an explicit credential generation, and a credential store reads exactly that generation; (3) where the qualification and release-policy types live is delegated to the implementer. The owner also directed epic 1 to be finished unattended. |
0066 §5.1, §18.2 |
| 2026-10-05 | PROVISIONAL, taken unattended for AP-SPEC-066 epic 1 as the narrower readings: one new product crate, auths-recipe-qualification, that depends only on auths-connections; RFC 8785 canonical JSON for every qualification artifact, with one signature suite (ed25519-v1); identifier grammars, size limits, and list bounds; the target's members; a record with ten evidence members that can only be passed, twelve capabilities each exercised or not applicable with a reason, and a read-back for every live write; stale may become revoked and revocation is permanent at each verifier; the code for each fault §10 leaves open, and the order in which faults are reported; nine required readiness preconditions; the secret-name and version derivations of the custody plan; a separate code inventory; bindings left to epic 4; Postmark as the paper-only header-API-key provider of case 0008; a CredentialBinding view as the store's lease argument; a read-back required for any record to close; and the injection header as the recipe's own committed declaration. |
0066 §18.3, readings 1–24 |
| 2026-10-05 | Owner direction for AP-SPEC-066 epic 2: start it on a new branch and pull request, continue through the whole epic without waiting for CI between tasks, commit per task, and resolve what is needed without asking. The owner created the AWS resources (account 585985124542, eu-west-1, one KMS key, runtime and operator roles trusted only through OIDC from the gateway-custody-live environment) and the environment; no static key exists. PROVISIONAL readings taken unattended are in 0066 §19.2, including the minimal client, the commitment-carrying two-phase rotation, manifest /4, named workload identity, and the test-only production plaintext feature. |
0066 §19 |
| 2026-10-05 | Owner direction for AP-SPEC-066 epic 3: pull main, start a new branch, and implement the epic fully, under the standing direction to continue without waiting for CI and to resolve what is needed without asking. | |
| 2026-10-05 | PROVISIONAL, taken unattended for AP-SPEC-066 epic 3 as the narrower readings (0066 §20.3): issuance is a second crate a gateway does not depend on; evidence is one artifact per member of passed cases, each tagged with one of 36 scenarios, and a record closes only when every always-required scenario has a case; a pull request produces offline evidence only and cannot assemble; signer rotation and freshness run on a placeholder candidate under a root made for the stage; the gateway's tuple takes the recipe family and provider contract from the operator's install and everything else from the build and installed files; production requires qualification, pins no root yet, and refuses the optional policy; the production clock adapter trusts one synchronization service's marker; remembered revocations and the list and index floors are kept per host; one run signs one index for every family; each privileged job of the run builds its own tool. An independent review of the branch found ten items (the signing job ran a binary another job produced; canaries were uploaded before the scan; an older release index could be replayed; import recorded its floor after the swap; four test or wording gaps); all are fixed on the branch. The agent created the GitHub environment recipe-qualification-signing with a required reviewer and the default branch only; it holds no secret, and the agent created no key. |
| Proposal | Reason | Recorded |
|---|---|---|
| 0024 work | Implemented; amendment was wording only | 0057 §5 |
| Multi-host store spec | 0038 Epic 2 + PostgresLifecycleStore exist |
0057 §5 |
| Universal gateway, identity platform, unified API, standalone receipts | Refused by 0024 §4, 053 §7, GTM | 0057 §5 |
| Merging PR #123 red | 0052 §5 | rule 6 |
Every agent report uses exactly this, under two screens, file:line for
every code claim, "not checked" where applicable:
- GOAL READ-BACK — the epic's acceptance in its own words, and what it does not cover.
- CODE CHECKS — what was verified, cited.
- SPEC CLARITY — sentences it had to guess at, both readings, its pick.
- CONFLICTS — with any committed spec, ADR, or this board.
- PROPOSED NEXT STEP — one bounded piece of work, done criterion, size.
The reply to a check-in is one decision and an update to §1.
This board, AP-SPEC-057, and the independent review enter the branch together
as docs: add program board, evidence program, and review baseline. The
previous Epic 1 binding-semantics work is separately committed as bda2b07.
Unattended runs append to docs/program-log/<date>-<label>.md, one entry
per epic transition and per blocker, each with a commit hash or CI run URL.
The morning report is the last section of that file, in the §6 shape, plus
a table of every PR opened with its CI state.
| Logged | Epic / step | What was needed | What the agent did instead |
|---|---|---|---|
| 2026-09-21 — RESOLVED | Epic 1 CI | GitHub Actions jobs could not start while the repository was private and paid minutes were unavailable. | Repository is public again; exact-revision runs 35552487976, 35552488044, 35552488080, and 35552488096 were rerun for real logs. |
| 2026-09-21 — RESOLVED | Epic 1 field-lab checkout | The earlier private-repository checkout appeared to require a read token. | Public auths-proof needs no checkout token. No credential was provisioned; field-lab commit 7ecea03 removed the workflow token input and pinned green SDK commit da5f470. |
| 2026-09-21 — RESOLVED | Epic 1 title audit | 9b31882 says “complete independent adapter adoption trial” but its diff contains conformance tooling, not the participant report. |
Preserved history and added a forward correction to the claim ledger under the AP-SPEC-057 §2 evidence-in-the-diff rule. The independent trial remains an Epic 4 blocker. |
| 2026-09-21 — RESOLVED | Epic 1 authoritative naming | The dated independent competition review and dated GTM research memos intentionally retain historical Auths Proof headings; adding allowances causes expected semantic-freeze drift. |
Added exact path-and-token allowances in release/public-naming.toml, advanced only auths.release.public-surface and the inventory freeze from 259 to 262 across two follow-ups, and regenerated the inventory; did not edit the independent review or GTM research or weaken the global stale-name rule. Hosted authoritative CI passed. |
| 2026-09-21 | Epic 1 field-lab hosted CI | The private auths-field-lab repository's Actions billing state rejected jobs before startup, despite the owner reporting it fixed. |
Exact-pinned Airtable run 35664008498, Todoist run 35664008485, and Tier 0 run 35664008506 received the payment/spending-limit annotation. The owner directed no further field-lab CI checks for PR #123. Local exact-wheel mocked tests passed 12/12 and 10/10; earlier live write/read-back succeeded. AP-SPEC-052 Epic 4's engineering evidence is recorded in the acceptance review, while AP-SPEC-057's distinct hosted done gate remains open, not inferred from local evidence. |
| 2026-09-21 — RESOLVED | Epic 1 formal evidence aggregation | CI attempt 1 could not download a phase artifact after GitHub intermediary returned 403; failed-jobs-only attempt 2 incorrectly looked for successful phase artifacts under its new attempt number. | Commit 73e0f72 selects the latest non-expired bounded artifact from the same run at or before the current attempt; exact CI passed formal evidence aggregation and the final qualification summary. |
| 2026-09-22 | Epic 1 formal evidence retry validator | Docs-tip CI passed translation, Kani, and Lean, but formal evidence attempt 1 hit GitHub artifact-download 403 and attempt 2 rejected the selected attempt-1 result because the native aggregator still required the current attempt number. | The source-attempt fix is bounded to artifact selection and aggregation: require the selected artifact's exact attempt in its contents, same run/head/closures, and a positive attempt not later than the current retry; targeted local test and generated closure checks passed. Hosted exact-tip verification is pending. |
| 2026-09-21 | Epic 1 independent owner review | AP-SPEC-051's final metadata gate calls for a human read of the Python/TypeScript API inventories and claim metadata. | The implementation agent published a manual source-level read-through, explicitly not human approval. The owner plans separate fresh LLM sessions for independent review; their findings and owner acceptance are pending, and LLM output will not be mislabeled human approval. |
| 2026-09-21 | Epic 4 step 2 | An unfamiliar participant must perform the AP-SPEC-054 trial and provide a redacted report. | Did not simulate a participant; corpus and wording work remain on draft PR #124, but the trial clause is open. |
| 2026-09-21 | Epic 3 acceptance | Twenty external repositories and one organization enforcing signed-commit verification require real adopters. | Did not simulate adopters. AP-SPEC-058 is now written on owner direction (§4, 2026-09-22); its §6 acceptance table keeps these two clauses human-owned. |
| 2026-09-22 | Epic 3 step 6 dogfood | Signing this repository's own agent commits and requiring the check here needs a root key the owner holds, .auths/git/trust.cbor committed to main, and a branch-protection rule. That is a trust-root and repository-policy decision. |
Did not create a root of trust for the owner's repository or change branch protection. The action and its hosted self-test (git-signing-action.yml) show it passing on agent-signed commits and failing on an unsigned one in a scratch repository. Owner steps: auths-git key init --label root, then auths-git trust init --root root --repository github.com/auths-dev/auths-proof --out .auths/git; merge that; add the action as a required check. |
| 2026-09-22 — RESOLVED IN CODE | Epic 3 step 5 public-good Sigstore | Public-good Rekor signs with DER ECDSA; the kernel suite takes fixed-width low-S. | The Sigstore adapter converts log and entry signatures to fixed-width low-S before the unchanged strict suite, tested on a recorded public-good entry (AP-SPEC-046 §15). A production Fulcio/Rekor client and the hosted live-sigstore job were added; the hosted run's result is recorded in PR #129. The workload policy commitments were also fixed (AP-SPEC-045 §5, AP-SPEC-046 §15.7). |
| 2026-09-23 | AP-SPEC-038 §9.3 second operator | The separation and custody requirements must be exercised by a second operator. | Implemented the checks and tests; did not simulate an operator. |
| 2026-09-23 | AP-SPEC-038 §9.3 observer quorum | A 2-of-3 observer quorum across three operator domains needs AP-SPEC-060 §16, which is demand-gated. | Did not implement §16; the gate item stays open. |
| 2026-09-23 | AP-SPEC-038 §9.3 root ceremony | The candidate evidence needs a reviewed root ceremony record. | Tested a 2-of-3 root through the kernel's KOfN; no ceremony was held or recorded. |
| 2026-09-23 | AP-SPEC-038 §9.1 custody kind in trust | A trusted context requiring a custody kind needs provider attestation and a core wire field. | Signers report custody kind; no verifier-side requirement was added. |
| 2026-09-23 | AP-SPEC-038 §9.1 custody in the binaries | auths-gateway and auths-git have no KMS or PKCS#11 client (Epic 4 work). |
Library paths are custody-held and conformance-tested; production gateway install refuses a software observer. |
| 2026-10-05 | AP-SPEC-066 Epics 2, 3, 5 credentials | An AWS account with workload identity and two roles; protected signing and live-evidence environments with a software release-signing key; disposable provider accounts; and a root ceremony. | Wrote both plans without creating or requesting any credential. Epic 2 can build the adapter against the in-repository double first; its protected-account run waits for the owner. |
| 2026-10-05 | AP-SPEC-066 revocation cadence | 0066 §8 bounds a revocation list at 72 hours and §7.4 keeps its root offline, so a root ceremony is needed at least every 72 hours while any production recipe is enabled. | Recorded the finding (0066 §18.4), planned a 48-hour cadence, and froze vectors that make revocation permanent at each verifier. Did not change the bound. Owner: accept the cadence or amend §8. |
| 2026-10-05 | AP-SPEC-066 Epic 2 client | The Secrets Manager adapter needs either a minimal closed client over the existing HTTP and TLS stack or the vendor SDK, whose default TLS backend needs a build script and a native dependency that architecture.toml forbids without approval. |
The custody plan recommends the minimal client and states the alternative's cost; no dependency was added. Owner decides at the start of epic 2. |
| 2026-10-05 | AP-SPEC-066 Epic 3 trust root and signer | The qualification trust root and the release signer's key must be created by the owner: the root offline in a ceremony, the signer's key into the signing environment. The agent handles no key. | Built the ceremony tool (auths-qualification root-init, certify, revoke, signer-init), the signing job, and the protected environment without a secret. The gateway pins no root, so production qualifies nothing until a release pins one (0066 §20.4). |
| 2026-10-05 | AP-SPEC-066 Epic 3 clock adapter | The kernel's time-synchronization flag is the signal that covers every Linux host and container, and reading it needs a system call the workspace's ban on unsafe code does not permit. |
The production adapter trusts the marker one synchronization service writes; a host synchronized otherwise must provide it. Recorded as 0066 §20.3 reading 12. |
| 2026-10-05 | AP-SPEC-066 Epic 3 remembered revocations | Whether what a gateway remembers as revoked lives per host or in the shared store. | Kept per host in the state directory; a host with an older list is bounded by that list's next update (0066 §20.3 reading 15). |
Owner direction: finish Epic 3 on recipe-qualification-verifier / PR #204;
the absent hostile, recovery, live and installed-consumer runners are Epic 3
implementation work, not deferred wholesale to Epic 5. The branch now has an
executable corpus runner and measured-observation contract, workflow wiring,
CLI/script-pipeline tests, and direct credential-lease counters. Hosted
verification is pending. Production family corpora, the owner's root ceremony,
live qualifications, operator trial and launch acceptance remain unclaimed.
Owner direction: finish Epic 4, then Epic 5, then publish the Python SDK
release candidate 0.0.1-rc1 and run a simulated onboarding pilot across all
recipes with measured friction and a backlog. Epic 3 PR #204 is merged.
Epic 4 implementation is on gateway-operator-polish; acceptance is still
open. The simulated pilot does not replace the independent operator trial or
human release review. Signing environment metadata contains no secret and
neither live recipe environment exists; the offline owner root ceremony and
live-provider qualification remain unclaimed. Python packaging must normalize
the requested semver to PEP 440 0.0.1rc1, preserving 0.0.1-rc1 as the
release/tag identifier. No publication or qualified launch is claimed yet.
Owner clarification (2026-10-06): publish the RC as a GitHub prerelease with downloadable Python wheel assets; PyPI publication is not required. Download those published assets, verify their checksums and install them in clean environments for the simulated onboarding pilot. Local checkout installs do not demonstrate that release handoff.
Epic 4 code at f1f92c3f passed every job in
main CI,
including authoritative tests, Lean, Kani, formal evidence and CI qualification.
The six operator-package, isolation, PostgreSQL, recipe and SDK-package
workflows also passed. The
operator package
was downloaded and verified: archive SHA-256
70b585794b4883a9f85897446bf13ccc334d711570b0dee3148413788f577cd4
and all eleven payload digests match. Frozen evidence uses freeze version 369,
manifest-byte version 58 and release-metadata version 369. Protocol identities
and proof statements are unchanged. This is engineering evidence;
protected live custody
still awaits environment approval, and live/human acceptance remains open.
Owner clarification (2026-10-06): merge each epic PR when that epic is complete and CI is green. This authorizes those merges without another confirmation; it does not waive the spec's live or independent-human acceptance gates.
Owner correction (2026-10-06): the agent simulates being an operator, fixes the observed friction and reruns the packaged rehearsal; the owner handles real users offline. This supersedes the earlier requirement for the agent to wait for an independent participant before continuing engineering. The simulation is labeled as such and cannot qualify live providers or establish independent human adoption. A separate source-free Ubuntu job downloads the operator archive and simulation kit, runs the documented CLI against disposable development installations, and records command timing and friction. Its hosted result is pending. Continue with Epic 5 engineering after this rehearsal; protected live inputs and release-signing keys remain explicit external prerequisites for signed qualification.
The first local Docker rehearsal used the verified f1f92c3f archive without
a source mount or network. It passed 31 steps, then found that separate-process
rotation does not reload development file custody in running hosts. The
rehearsal and runbook now keep those hosts drained during file rotation and
restart both before checking the committed generation. The defect rerun is
pending; no production AWS rotation result is inferred from this procedure.
The next run passed rotation on both restarted hosts, then refused tuple
export because the development install omitted a family and contract. The
rehearsal now declares an explicitly synthetic family/contract at install;
those identifiers carry no production qualification claim.
The corrected Docker rehearsal passed all 47 steps in 5.848 seconds against
the downloaded f1f92c3f archive. The container mounted only that archive,
public inputs and the report directory; networking was disabled, with a
synthetic public-address DNS entry solely for transport construction. No
provider request or TLS session was exercised. The sanitized result is
deployment/gateway/evidence/operator-simulation-2026-10-06.json. It covers
shared controls, retained-floor restore refusal, drained file rotation,
privilege-dropped diagnostics, support redaction, disposable trust stages,
restart and store-only outage controls. Exact-current-commit hosted rehearsal
and CI remain pending. Live production and human adoption claims remain open.