A small, inspectable engineering demonstration
From evidence to
an approved action.
Inspect how a bounded workflow checks source references, rejects unsupported fields, limits retries and requires approval before changing a synthetic record.
What is real: JavaScript validation, control flow, payload hashing and an in-memory write in this tab.
What is simulated: agent roles, research evidence, approval identity and the CRM. No LLM, MCP server or external API is connected.
01 · ResearcherLoad fixture evidence
02 · VerifierCheck cited fields
03 · Human gateMatch payload approval
04 · OperatorApply one local change
Choose a test case
Each run starts from fresh synthetic fixtures. Replay and conflict cases run twice within one session. No real approval or business action is created.
Tool boundaries
researcher → evidence.lookup
verifier → evidence.validate
operator → crm.apply_local
This is deterministic role sequencing, not process isolation or a production access-control system.
Evidence fixture
READY
Run a scenario to inspect the result
The default path stops before any local write.
0local writes in scenario
0external API calls
Inspect the actual browser result
Evidence and limits
- Every company and field is fictional. Example URLs are labels for fixtures and are never fetched.
- The evidence date check uses a fixed reference date of 17 October 2026 for reproducibility. It checks consistency with supplied records, not the truth of real-world claims.
- Approval uses a payload digest and a synthetic actor. There is no authenticated user or cryptographic signature.
- The ledger is in memory. It has no concurrency, crash-recovery or cross-restart guarantee.
- The Python tests and browser-port parity checks cover rejection paths, approval binding, bounded retries and duplicate-write prevention. It is not an independent security audit.