Follow the request. Inspect the decisions.
A useful AI system needs more than a plausible answer. Inspect the checks that decide what can be trusted, what needs review and what may be recorded.
Try two working control examples, follow a scripted work order, or explore the four engineering instruments. Every example uses synthetic data. No model is called and no real system is changed.
Working example 01 · document validation
A matching document is a draft. Approval is a separate decision.
Imagine a material certificate arriving with an order. These fields have already been extracted: the demonstration checks them against a synthetic approved order. Change the document to see where the process must stop.
Possible application: checking incoming documents before an operations team accepts a record.
Synthetic · deterministic| Field | Submitted | Required |
|---|---|---|
| JavaScript loads the public synthetic fixture. Download it below to inspect the values directly. | ||
Try an interrupted action
After a matching document passes, choose how the simulated destination responds. Approval is bound to the checked payload. A retry uses the same operation identifier.
For the offline case, change this to “Online” before retrying. For a lost reply, retry to reconcile the existing record.
Ready to inspect
JavaScript enables the working example. The explanation and fixtures are available without it.
Synthetic destination: 0 records.
This destination exists only in page memory. Resetting the example, changing the document or reloading the page clears it.
What this demonstrates — and what it does not
The same control functions run here and in the published test suite: required fields, exact matches, revision checks, approval binding and simulated duplicate handling.
There is no OCR, language model, database or real identity service. All fixtures are public. The browser’s simulated permissions are an illustration, not an access-control boundary. A production implementation needs server-enforced policy and durable, transactional state.
Working example 02 · evidence selection
Show the source. Stop when the sources disagree.
A procedure lookup should carry its authority with it. This example selects a literal passage from a tiny synthetic source set. It checks the simulated identity and approved revisions before returning evidence.
Possible application: finding a current procedure for a service or operations team, with the source and revision visible.
Synthetic · no generated answerQuestion being checked
What must be checked before a work order is released?
Inspect the selection rule
Filter by the simulated identity, then select the highest approved revision within each source series before looking for the fixed question. A claim removed from a newer revision cannot be recovered from an older one. If the remaining passages differ, withhold an answer and show both for review.
This is exact passage comparison, not semantic understanding. Different wording is treated as disagreement. A real retrieval system needs access enforcement, source ownership, ranking and model evaluation against representative questions.
Run the check to inspect the selection.
Ready to inspect
JavaScript enables the working example. All source passages are included in the downloadable fixture.
The restricted source is public synthetic test data. Filtering demonstrates an expected control result; it does not protect data in this browser.
Find the approved procedure. Draft the work order.
Scripted simulation with synthetic data.
- 01Identify
- 02Retrieve
- 03Prepare
- 04Draft
- 05Approve
- 06Record
Ready to inspect.
Follow one request through the system.
View the event trace
The request is identified, its permissions checked and the approved procedure retrieved. A draft is validated before a human approves any change. Denied access stops retrieval. A failed connection retains the draft rather than claiming success.
JavaScript enables the interactive walkthrough. The rest of this website works without it.
This example follows a single control flow. In production, the same flow runs with authenticated identities, durable state, independently enforced policy and tests against the real dependencies.
Estimate the recovery. Then test it.
Estimate restore time from data volume, sustained throughput and validation time. Use a recovery test to verify the result in your environment.
What can it really reach?
Choose a Microsoft 365 permission an AI agent might request, and see what it allows, how far it reaches and the narrower option.
Where the seconds actually go.
Add up the model calls, tool calls and retrieval steps in an agent task, and see what dominates and what to change.
Start with the warning signs.
Answer six questions to identify reasons for a closer review. This illustrative score helps prioritise that review; it is not a security, compliance or business-risk assessment. Nothing you enter leaves your browser.