Playground

Run a governed action, end to end. Pick a scenario and watch screening, policy, relay, and receipt happen in order. The pipeline is simulated in your browser with the same vocabulary and states as the live API. Nothing is sent to the network.

The six scenarios

• Query a research service: a clean read-only lookup travels the full governed path: screen, decide, ticket, relay, receipt. It ends COMPLETED with effect permit.
• Purchase software above budget: a spend request clears screening but exceeds the organization budget cap. Policy escalates, the run holds at APPROVAL_REQUIRED, and a person approves or denies it. Approval continues the dispatch; denial ends the run as CANCELLED.
• Handle an injected web page: a web page hides an instruction aimed at the agent. Screening raises prompt_injection.hidden_text and prompt_injection.instruction_override and the run ends BLOCKED before anything is dispatched.
• Send an email containing a secret: a credential is caught before dispatch. Screening raises sensitive_data.public_exfiltration and nothing leaves the boundary.
• Send a report with customer fields: the report goes out, but customer identity fields cross the boundary only in redacted form. Policy effect redact, final state COMPLETED.
• Delegate work to a child agent: the same delegation path with two payloads. The destructive ask raises a2a.destructive_delegation and is blocked; the scoped read-only ask completes.

How each run works

Every run moves through the same order: the agent declares its intent, semantic screening classifies the content, policy decides with one of four effects (permit, redact, escalate, forbid), a relay ticket binds the dispatch to the agent and purpose, the request goes out through the governed relay, the response is screened on the way back, and a receipt records the outcome. The scenario only changes where the pipeline stops.

The honesty model

• Simulated locally. The scenarios replay a deterministic model of the decision pipeline in your browser. No scenario run touches the hosted API.
• Same enums as the live API. Every decision word, screening label, deny layer, and transaction state in the playground comes from the shipped decision vocabulary. Nothing is invented for the demo.
• Demo-key receipt verification. Each completed run issues a demo receipt under its own demo schema, signed with an Ed25519 key generated in your browser. The Verify button runs a real WebCrypto verification against that demo key. The demo key is not the network trust root; the real root is published at /receipts/trust.json. Browsers without Ed25519 support get an unsigned demo receipt that says so.
• Live probes when the browser allows. The page checks the hosted API's health endpoint and fetches the public trust document. A LIVE chip renders only after a successful fetch; when the fetch fails, the page says so and shows the curl command to fetch the trust document yourself.

Want the real thing?

Register an agent against the live API in minutes. The developer docs at /cortexanet/developers document the hosted contract, and /cortexanet/request-access is the way in.