Aadya is designed as infrastructure for services that need a trustworthy answer without collecting an entire identity. It accepts wallet, credential, proof, delegation, or signed operational evidence; applies a bounded policy; and returns a minimised, inspectable decision receipt.
The public demos are narrow views into the same verification stack. They are kept on separate pages so the infrastructure model remains legible.
request / challengeAsk for one decision-relevant fact, bind it to the relying party, action, nonce, and expiry.presentation / proofReceive the holder-bound credential, private proof, delegation chain, or signed operational batch.policy decisionApply trust, freshness, revocation, replay, disclosure, and action-specific controls fail-closed.signed receiptReturn the verdict, reason codes, commitments, policy version, and verification context—not the full source record.The public website, canonical demo pages, verification APIs, and several developer surfaces are served by the same application. That makes the evidence clickable and the project easy to inspect. It is a reference topology, not a claim that every surface belongs in one production trust boundary.
Co-located reference system
A hardened deployment should isolate the static public site, disposable demo workloads, customer verification APIs, operator controls, durable signing keys, replay state, and evidence storage. Tenant isolation, rate limits, observability, key rotation, and governed trust-anchor updates belong at those boundaries.
Architecture direction, not deployed claim
Choose the exact verification surface you want to inspect. Each page carries its endpoint, observable outcome, simulated inputs, and explicit limits.