Protocol edge
OID4VCI, OID4VP, SD-JWT VC, ISO mdoc, OpenID Federation, and direct signed-evidence adapters.
privacy verification infrastructure
Verify the fact. Enforce the boundary. Keep the evidence.
Aadya sits between evidence and action. It accepts a wallet presentation, private proof, organizational credential, delegated authority, or signed operational batch; checks trust and policy; then returns a minimised, inspectable decision receipt.
This is a reference implementation and production hardening is in progress. The current public deployment is deliberately inspectable; the intended production topology separates public, demo, verification, and operator planes. [SEC-3]
one verification rail
The demos are examples. This is the project.
Four separable layers turn heterogeneous evidence into one bounded decision contract.
Trust context
Issuer keys, holder binding, status, revocation, trust anchors, and scoped authority—kept distinct from legal status.
Policy core
Private predicates, nonce and audience binding, replay controls, delegation limits, and action-specific policy.
Evidence plane
Signed decisions, reason codes, commitments, and reproducible conformance or proof artifacts—without retaining the whole source record.
decision surfaces
Different evidence. The same control discipline.
Ask for a threshold or holder-bound action—not a profile.
Combine standards-based wallet presentation with an explicitly separate private-proof path when the decision requires stronger cross-site privacy.
Prove a role, then attenuate what a delegate may do.
Keep organizational trust, holder control, sub-delegation, spend limits, and action-time denial visible as separate checks.
Bind a decision to signed evidence, policy, and a specific action.
Treat sensor readings or risk scores as inputs—not decisions—and retain the signed control outcome rather than the unbounded raw record.
evidence before assertion
Infrastructure claims should be inspectable.
Each figure links back to a dated artifact and keeps its qualifier attached. A local conformance run is not a certification; technical trust validation is not legal status.
319 / 332
OIDF conformance modules passed, 0 failed. Reproducible local run; not an OpenID Foundation certification. [OIDF-1, OIDF-4]
15 / 33
Protocol theorems discharged versus tracked; the remaining 18 are published as partial. [FV-1]
28 / 31 · 4,677
National lists accepted under the current strict profile and service records parsed; 29 were fetched. Interop evidence; no qualified status. [TRUST-1]
7,179 · 0 failed
First-party Python tests in the dated 2026-07-28 local run; 158 skipped and 6 expected xfails. Engineering evidence, not certification or completion of blocked external gates. [TEST-1]
ZK + PQ hybrid
Real classical Groth16/BN254 private proofs; hybrid post-quantum confidentiality. The ZK layer is not post-quantum. [PQ-1, PQ-2]
deployment truth
Polished front door. Explicit trust boundaries behind it.
One app keeps the project easy to inspect.
This website, the demo pages, APIs, and several operator or developer surfaces currently share one FastAPI reference deployment. That is useful for reproducibility, but it is deliberately not presented as the final production architecture.
Separate public, demo, customer, and operator planes.
A hardened topology isolates static delivery, disposable demo workloads, tenant-scoped verification APIs, durable key and replay services, evidence storage, and operator controls. The infrastructure page makes that target and the current gap explicit.
the boundary is part of the product
What the project does not claim.
- No eIDAS legal status. Trusted-list and EBSI work is technical interop evidence; Aadya is not listed, qualified, or accredited.
- No OIDF certification. The conformance results are self-run and reproducible, not a listing on the Foundation certification register.
- No production-ready label. The implementation has substantive controls and evidence, while key operations, tenant isolation, governance, and separated deployment remain production work.
- No privacy collapse. Wallet compatibility and the stronger unlinkable private-proof path are described separately because they provide different guarantees.