How it works

In one line: recurve produces the verdict — RED-first, gated code correctness — and an auths agent identity signs off on that verdict, and on the release. Everything verifies offline, from the repository.

Two halves, one seam

	Role
recurve	the referee. Turns each claim about the change into a probed, RED-first, gated check and renders the verdict.
auths	the identity. Mints an agent identity (did:keri:), signs each verdict and the release, and gives anyone the public key to verify.

They meet at a single, unobtrusive seam. recurve emits a verdict receipt and hands its hash to a signer command; a matching verifier command re-checks it later. Point those two config lines at the auths adapters and the referee's verdicts become signed, re-verifiable attestations — with zero changes to recurve:

[receipts]
signer   = "python3 tools/auths_sign_receipt.py"
verifier = "python3 tools/auths_verify_receipt.py"

flowchart TB
    subgraph R [recurve · the referee]
      B[baseline → matrix --gate] --> P[per verdict:<br/>self-hashed, chained receipt]
    end
    P -- self_sha256 --> SGN[auths_sign_receipt.py]
    subgraph A [auths · the agent]
      SGN --> ID[did:keri agent signs<br/>+ an independent witness cosigns]
      ID --> OUT[attestations/*.json<br/>signed · witnessed · anchored]
    end
    OUT -- public key + repo only --> V[verify offline]

What happens per verdict

As each check turns GREEN, the seam produces a small, layered record:

1. A signed action envelope — the agent signs the verdict; tamper-evident and wrong-key-proof.
2. A DSSE in-toto attestation — the same verdict in the standard format any supply-chain verifier already reads.
3. A witness cosignature — a second, independent agent counter-signs, so the referee never marks its own homework.
4. A transparency-log inclusion proof — the receipt is anchored as a leaf in an append-only Merkle log, provably included, checkable offline.
5. An OTEL trace binding — the verdict carries the trace/span it was produced under, so it references the same span your observability tooling shows.
6. A fresh-context attestation — a newly-minted agent, distinct per cycle, attests the work ran in a clean context (no state carried between cycles).

The evidence bundle page opens each layer up.

The gate measures the real code

The auths SDK is a sibling the demo consumes as a prebuilt native extension. recurve is told to treat it as a secondary tree it rebuilds before probing, so the gate always measures the current SDK source — never a stale artifact:

sculpt auths: rebuild OK (exit 0)
● … 16 claims probed against the freshly built SDK …

If a claim's honest fix lives in the SDK, the gate builds it; a check can never pass against yesterday's binary. (This is recurve's multi-repo support — see recurve's own docs for the general mechanism.)

Verification is offline by construction

The verifier — tools/verify_all.py, the "someone who wasn't there" check — reads only the agent's public key (published in the repo) and the files on disk. It re-runs every signature check, every inclusion proof, and the witness-independence check. No network call, no certificate authority, no server. If a byte of the evidence was changed, it fails — that is what makes the repository, and nothing else, the root of trust.

The pieces

Path	What it is
src/auths_curve/integration.py	the seam in one place — mint agent, sign/verify verdict, cosign, anchor, bind trace, verify offline
tools/auths_sign_receipt.py	the signer adapter — the agent signs each verdict and emits the bundle
tools/auths_verify_receipt.py	the verifier adapter — re-checks the agent's own receipt signatures
tools/verify_all.py	offline re-verification of every signature and proof
tools/ci_merge_gate.py	the merge-gate — allow/block for CI
tools/compliance_export.py	maps gated receipts to control frameworks
claims/integration/	the recurve suite: prose, ledger, probes, and a kept counterexample per probe
attestations/	the per-verdict evidence bundle (git-ignored; regenerated each run)