v0.5.0 - Deployment/version receipts

v0.5.0 - Deployment/version receipts

This release adds the lowest-friction X-facing demo: signed deployment/version receipts.

The idea: X can publish a receipt proving that rollout R used algorithm commit C, model artifact root M, config hash H, and policy bundle P during time window T. Anyone can verify the receipt offline. No user data, ranking output, or private infrastructure details need to be disclosed.

New commands

npm install
npm run deployment-demo
npx @veritasacta/verify examples/deployment-version/deployment.receipt.json \
  --jwks examples/deployment-version/deployment.jwks
npx @veritasacta/verify examples/deployment-version/feed-session-certificate.receipt.json \
  --jwks examples/deployment-version/deployment.jwks

Included fixtures

• deployment.receipt.json: public production-version-style receipt for algorithm/model/config/policy bundle metadata.
• feed-session-certificate.receipt.json: user-facing certificate showing what a Premium user could see without exposing user features or ranked output.
• deployment.jwks: public key for both demo receipts.

Claim boundary

This is a demo receipt derived from the real Phoenix fixture in this repo. It is not a claim about production X. A real deployment would need X, or an authorized deployment observer, to hold the signing key and define the rollout metadata.

v0.4.0 - VOPRF-gated disclosure (the privacy layer)

The privacy layer. v0.4.0 adds VOPRF-gated disclosure on top of the v0.3.0 receipt format.

What's new

The open receipt format proves what ran. v0.4.0 demonstrates the ScopeBlind layer that lets authorized people verify it privately.

• npm run voprf-demo — Full BRASS/VOPRF-gated disclosure flow against the real Phoenix receipt. Researcher receives an issuer-blind VOPRF token, verifies the recommender receipt, presents the token to unlock a tiered disclosure (top-10 structured ranked items). Verifier confirms: receipt signature valid + VOPRF token valid + DLEQ issuer proof valid + DLEQ client proof valid + disclosed rows match the signed ranked_items_root.
• npm run unlinkability-demo — Issuer view vs verifier view of two token issuances for the same approved researcher. Demonstrates scope-specific nullifiers and contrasts against a naive signed-bearer-token scheme (which would carry a stable subject and link redemptions by default).
• New profile: scopeblind.recommender.gated-disclosure-attestation.v1. Cryptographically binds the disclosure to the source receipt via receipt_id + receipt_signature_hash.
• Signed disclosure attestation verifies offline against @veritasacta/verify@0.6.1. No production server contacted.

The precise privacy claim

The issuer cannot link token issuance to later verification/redemption from the cryptographic transcript alone. Inside one verifier scope, two redemptions by the same researcher remain linkable by nullifier (intentional, for rate limiting). Across scopes they are unlinkable.

This is exactly the property a naive signed bearer token cannot provide.

What it's not

• Not a regulatory artifact. Whether a deployment satisfies DSA / AI Act requirements depends on retention, access control, the auditor's authority, and the regulator's view.
• Not production. The shipped demos are local; they generate BRASS-style P-256 VOPRF tokens with DLEQ proofs and verify them locally. They do not call the production ScopeBlind issuer at api.scopeblind.com. The cryptographic property is identical; the operational separation between issuer and verifier is what production deployment delivers.
• Not "verifier-blind." The verifier sees the redemption event. The privacy property is that the issuer cannot link issuance to redemption.

See LIMITATIONS.md for the full caveat list.

Run it

git clone https://github.com/VeritasActa/x-algorithm-receipts
cd x-algorithm-receipts && npm install

npm run voprf-demo
npm run unlinkability-demo

# Verify the resulting attestation with the production verifier:
npx @veritasacta/verify examples/voprf-gated-disclosure/gated-disclosure.attestation.json \
  --jwks examples/voprf-gated-disclosure/gated-disclosure.jwks

Why this matters commercially

The receipt format is open. Anyone can ship signed receipts. Issuer-blind verification with selective disclosure is the patent-protected (Patent #2 verifier nullifiers, Patent #4 configurable disclosure) ScopeBlind layer. v0.4.0 makes the moat visible.

Related

• IETF: draft-farley-acta-signed-receipts
• Verifier on npm: @veritasacta/verify (Apache-2.0)
• Previous release: v0.3.0 (structured Phoenix parser)

v0.3.0 - structured Phoenix ranking parser

v0.3.0 - structured Phoenix ranking parser

This release upgrades real mode from byte-level stdout commitments only to a two-root output model:

• output_root: Merkle root over exact Phoenix stdout lines, preserving byte-level reproducibility checks.
• ranked_items_root: Merkle root over parsed structured Phoenix ranked records (rank, post_url, post_id, score fields, VQV score, topics).

The included real receipt is bound to xai-org/x-algorithm@0bfc2795d308f90032544322747caacd535f75ae, includes algorithm_source_root over 212 source files, commits to 8 model/config/corpus artifacts, and discloses 30 structured top-N records.

Verify

npx @veritasacta/verify examples/x-feed-real.receipt.json --jwks examples/real.jwks
node scripts/inspect-receipt.mjs examples/x-feed-real.receipt.json

Expected inspector highlights:

algorithm commit       git:0bfc2795d308f90032544322747caacd535f75ae
structured output      phoenix-table-v1
ranked items           30
ranked items root      merkle-rfc6962-sha256:4eff4e9ba7004994adccad71aa9ce4097798bb714dca4c3dd341c279155bc001
top item: #1 score=0.3922 post=2055371034010726771 topics=Sports,NBA

Caveat

This proves execution binding, not ranking quality. It does not prove the ranking is fair, truthful, beneficial, legally sufficient, or actually used in production.

v0.2.0 - real-mode receipt against actual Phoenix pipeline

First release with a real-mode receipt bound to an actual run of the published Phoenix pipeline.

What's new

• Real-mode receipt at `examples/x-feed-real.receipt.json`, bound to `xai-org/x-algorithm@c3ef330`. Generated by cloning the upstream repo, downloading the 2.9 GB Phoenix LFS artifacts, running `uv run run_pipeline.py`, hashing all 8 model and config files, and signing the audit event.
• Reproducibility demo (`npm run repro-demo`) showing wrapper-level determinism: two independent runs with the same input produce identical `input_commitment` and `output_root`.
• Tamper detection demo (`npm run tamper-demo`) showing the verifier rejects any modification to a signed payload.
• CI workflow (`.github/workflows/verify-receipt.yml`) verifying the receipt on push, PR, and daily schedule. Copyable into any recommender repo.
• LIMITATIONS.md documenting the canonical caveats: execution binding vs ranking quality, mock vs real, output-bytes vs parsed-records, observer trust, regulatory framing.

Verify

```sh
git clone https://github.com/VeritasActa/x-algorithm-receipts
cd x-algorithm-receipts
npm install

Mock-mode receipt (instant, no artifact download):

npm run demo
npx @veritasacta/verify examples/x-feed-demo.receipt.json --jwks examples/demo.jwks

Real-mode receipt (already in the repo, bound to xai-org@c3ef3307):

npx @veritasacta/verify examples/x-feed-real.receipt.json --jwks examples/real.jwks

Inspect semantic fields:

node scripts/inspect-receipt.mjs examples/x-feed-demo.receipt.json
node scripts/inspect-receipt.mjs examples/x-feed-real.receipt.json

Tamper demo:

npm run tamper-demo

Reproducibility pair:

npm run repro-demo
```

In-browser verifier

For no-CLI verification, drop a receipt + JWKS at https://www.scopeblind.com/verify-receipt.

RFC

#1 Add optional post-ranking audit event hook proposes a minimal in-tree hook for `xai-org/x-algorithm`. Filed on this repo because upstream Issues are disabled.

What this proves

Execution binding, not ranking quality. The receipt proves a specific output was bound to specific code, model artifacts, config, and input commitments at signing time. It does not prove the output is fair, truthful, or beneficial. See LIMITATIONS.md.

Related

• IETF: draft-farley-acta-signed-receipts
• Verifier: `@veritasacta/verify` (Apache-2.0)
• Lesson 18 in microsoft/ai-agents-for-beginners walks the same primitive for agent tool calls.
• Blog: scopeblind.com/blog/x-algorithm-receipts (canonical) / veritasacta.com/blog (reference-implementation framing).