Proving alignment,not revealing the score.
Before the orchestrator runs a risky action, it computes a similarity score against the constitution centroid. If the action is safe, that score is high. But shipping the score downstream leaks information about how the constitution was tuned — and an attacker who watches enough scores can reconstruct the centroid itself. Zero-knowledge alignment proofs let the verifier confirm a valid 14-bit commitment to the score and learn nothing else — threshold binding is enforced by a prover-side refusal-to-create rule, not the range proof itself.
The verifier learns the exact score. So does every downstream observer. With enough samples, the constitution centroid is reconstructable from the scores alone.
Just “passes threshold: yes.” Less leakage, but the verifier has to trust whoever computed it — there's no cryptographic proof anyone actually checked.
The verifier sees 14 Pedersen commitments, 14 Schnorr OR proofs, and one homomorphic sum check. Confirms cryptographically that the prover knew a valid 14-bit integer committing to the score. Threshold binding is enforced by a prover-side refusal-to- create rule. Cannot tell 0.76 from 0.92 from 0.99.
plaintext: ship the score (0.87…) — full reveal, centroid reconstructable.
flag-only: “passes threshold” — less leakage, but no cryptographic proof.
this system: Pedersen + Schnorr OR range proof — valid 14-bit commitment, mathematically, with nothing else disclosed. Threshold binding by prover refusal-to-create.
Below are five scenarios — high alignment, barely passing, exactly at the threshold, below-threshold creation refusal, and a verifier rejection after a bit-commitment tamper. Each scenario shows what the prover knows, what gets sent on the wire, and what the verifier sees.
Real proofs, built and verified here. The Rust runtime derives one generator differently, so proofs don't carry across between the two.
How faithful is this demo?
Scope: the Pedersen commitments, Schnorr OR proofs, and Fiat-Shamir challenges are real — generated at build time via @noble/curves Ristretto255 + Node's sha3-512. Every bundle actually verifies (or actually fails) within the same library. The protocol shape (per-bit Pedersen commit + Schnorr OR + homomorphic sum, 14-bit fixed-point ×10000) is protocol-faithful to tdd005/crates/tdd004_provenance/src/zk.rs.
Honest divergence: the H generator differs between implementations. Rust derives it via SHA3-512 hash-to-curve of the domain string; this build uses RFC 9380 (SHA-512) via @noble/curves. The two H points don't share bytes, but each is an independent generator with no known discrete log w.r.t. G. Proofs built here verify here; proofs built in Rust verify in Rust. Cross-impl verification would require matching the hash-to-curve algorithm.
A safe read action with strong alignment. Score 0.92, threshold 0.75. Verifier learns the score is at-or-above 0.75. Verifier does not learn it was 0.92 specifically.
Prover side — what is known
Construction — Pedersen + Schnorr OR per bit
Verifier side — runs verify()
protocol details · ristretto255 · 14-bit range
- · action_hash
- · constitution_hash
- · threshold
- · value_commitment
- · per-bit commitments
- · per-bit Schnorr OR proofs (a0, a1, e0, s0, e1, s1)
- · timestamp
- · similarity_score (the actual scalar)
- · per-bit values (b_i)
- · per-bit blindings (r_i)
- · total_blinding (r)
- · which Schnorr OR branch was the real one
Rust uses SHA3-512 hash-to-curve; this build uses RFC 9380 (SHA-512). H bytes differ between implementations, protocol shape identical.