Don't trust us. Run the checks.

Write the payloads you are worried about, such as card-number shapes, raw URLs, and response bodies, and let the verifier tell you what the live policy does with each one before anything goes live.

stepstitch policy verify examples/policy/financial-fixtures.json
# per fixture: rejected (422, nothing stored) | dropped | redacted | accepted
# plus a must_not_persist literal scan over everything that would be stored

• stepstitch policy verify runs your own hostile fixtures through the live scrub boundary and reports, per fixture, whether it was rejected, dropped or redacted.

Every verified fix carries a canonical, hashed evidence bundle: scrub report, replayability, verdict, evidence grade. The hash covers the grade, so nothing can be upgraded after issue.

# 1. the hash is reproducible from the bundle alone
python -c "import json,hashlib,sys; b=json.load(open('attestation.json')); \
print(hashlib.sha256(json.dumps(b,sort_keys=True,separators=(',',':')).encode()).hexdigest())"

# 2. the signature is your tenant's, not ours
cosign verify-blob --key tenant.pub --signature attestation.sig attestation.json

• The attestation is canonical JSON hashed with SHA-256 and signed with a key only your tenant holds: anyone can recompute the hash or run cosign verify-blob without asking us anything.

Read the scope table: writing a verdict requires the verify scope, which sits outside the ladder any connected agent is issued from. Then read the test that proves a caller-supplied grade is demoted.

# the credential 'stepstitch connect' issues can read repros: never verify
POST /session/{id}/verify  ->  requires scope: verify (agents get: repros)

# and the grade cannot be asserted into existence
pytest service/tests/test_evidence.py server/tests/test_agents.py

• The credential handed to a coding agent cannot write a verdict: the verify scope sits outside the agent scope ladder, so the token that proposes a fix can never be the token that records it worked.
• Evidence grades are derived from how an outcome was obtained, never accepted from a caller: a payload claiming a signed grade is recorded as asserted.

Download the example FixProof and the policy it must satisfy, then check both on your own machine. The in-toto statement binds the fixed commit, frozen-test digest, measured red-then-green results, and privacy policy digest. The check also includes a real Ed25519 signature verified against the key the policy names. (The demo key is public by design so this example stays reproducible; your deployment trusts only the key `stepstitch proof keygen` creates on your host.)

curl -O https://stepstitch.vercel.app/fixproof.json \
     -O https://stepstitch.vercel.app/proof-policy.json
pip install stepstitch-service
stepstitch proof verify fixproof.json --policy proof-policy.json
# 8/8 checks incl. the ed25519 signature. Change any byte and rerun: it refuses.

• A FixProof is an in-toto statement whose hash is reproducible from the document alone: stepstitch proof verify checks it offline against your policy, with no host, no account, and no trust in whoever handed it over.
• The signature check is cryptographic, not cosmetic. An Ed25519 signature is verified against keys your policy names; a fabricated document with a recomputed hash, a fake signature string, and a valid signature by an untrusted key are each refused, and each refusal is a permanent test.
• Every leaf of the proof statement is mutation-tested: altering, deleting, or inserting any field makes offline verification refuse the document, and the mutation surface is enumerated from the statement itself so it cannot silently shrink.
• The proof binds digests, statuses, and identities: a proof built from a hostile ingest is scanned against the canary values and none of them appear in the exported document.

The public demo console is the real product surface over a synthetic dataset: traces, privacy posture, replayability, the frozen reproduction, and the measured red-to-green verdict.