Demonstration
Explore a fictional application scenario and a separate assessment and reporting flow.
Who denied the request?
Choose an illustrative scenario. These examples run entirely in your browser; they do not send attacks, call the engine, or replay preserved test results.
Alice requests a record.
The fictional application allows users to read their own records. Change the resource to inspect application authorization. The separate assessment and reporting walkthrough below explains assessment scenarios.
Illustrative rules and explanations. No defensive-benefit claim.
200 · Application permits the read
Actor: alice · Target: alice's recordAssessment: evidence can be examined separately; this browser example does not produce an engine verdict.
What reaches the recipient?
This selector explains documented scenarios. It does not run C, establish TLS, send requests, or replay captured evidence.
- CLI recipient → HTTPS sender: mTLS POST /attempt with an exchange ID.
- Sender → separate HTTP scene: run GET /public; the response completes and journals close.
- Pinned controller → frozen C subprocess: project evidence, then receive the selection or diagnostics.
- Sender → CLI recipient: return a later HTTP response bound to the exchange and original scene run/request.
Select a reporting scenario.
Explanatory display of Revision 3 outcomes; not a live experiment.
Clean
Enforcement-Action field absentAgreement; no additional proposal. This is not ALLOW.
Recipient: parses and records. No forwarding or control execution.
monitor communicates a selected fixture proposal. It does not mean monitoring began. The original GET /public response already completed; the field belongs to the later reporting response.