EVE verifies real external evidence before an action, evaluates it against human-defined policy, and verifies afterwards what actually happened.
EVE verifies the evidence. Human-defined policy determines what happens next. The customer workflow executes the action.
Run A
Blocked by policy
Azure DevOpsTo do
EvidenceInsufficient
DeterminationVALID
Policy outcomeBLOCK
Target callNo
Target stateABSENT · HTTP 404
→
Only external evidence sufficiency changed
→
Run B
Allowed by policy
Azure DevOpsDone
EvidenceSufficient
DeterminationVALID
Policy outcomeALLOW
Target callYes
Target statePRESENT · HTTP 200
Same requirement. Same action. Same workflow.
The action identifier, the sealed requirement, the policy, the workflow artefact and the target datastore were byte-identical across both runs. Between them, a person moved a work item from To do to Done — and Azure DevOps set a closing date as a consequence.
What actually happened
Before
▸Real authenticated read of an Azure DevOps work item
▸EVE verification — a sealed, re-verifiable determination
▸Human-defined policy decides the permitted outcome
Action
▸An external workflow, in its own process
▸Acts only on allow — anything else, and it does nothing
▸Writes to an isolated target system that holds no EVE credential
After
▸EVE reads the target's own record of what it did
▸Persists an execution observation from that source
▸Seals an execution determination against the same requirement
EVE never executed the action.
The policy outcome was recorded before the target was touched. The workflow read one field from it and either acted or did not. EVE's later verification ran against a world it did not arrange — and a verification that runs after an action can never be what permitted it.
Replay the proof
Step through either run
These are the sealed records from the demonstration, replayed. Re-running the sequence would create new records rather than show you these.
One sealed requirement. Two roles.
Pre-action record
EVE-PAR-LOCAL-000032
Verified · VALID
Handling role
What evidence must exist before the action may proceed?
A completed change review for this subject action, read from Azure DevOps through a declared, credentialed surface and a declared projection.
Same action
EVE-ACT- 2cc5f11c14c464cc
Execution role
What evidence must exist afterwards to establish that the same action occurred?
An execution record from the target system itself, naming the same subject action and the same execution reference.
Both roles were declared and sealed before the governed action was executed. The runtime enforces that the execution role names the same subject action as the handling role — so EVE cannot be induced to verify a different action than the one policy governed.
Show me the evidence
The pre-action record. It carries the chain state, the policy and both governance roles, sealed together before either run.
EVE read the work item, found the record incomplete for the claim, and refused to fabricate an observation. It evaluated honestly anyway and sealed a determination stating that the claim was not established — which is a different thing from no evidence having been sought.
Bound toEVE-PAR-LOCAL-000032
Handling statusnot_evaluated
Observations persistednone — the source record was incomplete
Resulting policy factnone admitted
The same surface, the same projection, the same sealed expectation. The work item now carried a closing date, so the claim was corroborated and the bridge admitted a single policy fact.
Bound toEVE-PAR-LOCAL-000032
Handling statushandled_corroborated
Binding statusEXACT_MATCH
Admitted policy factrequired_review_completed = ESTABLISHED
What the target system itself recorded, read by EVE afterwards. It reports the target's own bookkeeping and says nothing about policy, verdict or determination — those fields are absent from the target's record by design.
Post-action verification, against the same sealed requirement that governed whether the action could proceed. Both roles report the same corroboration axis, so the axis alone identifies nothing — what distinguishes this record is its predicate, its evidentiary role, and the source system the observation came from.
Schemadet-1.0
Bound toEVE-PAR-LOCAL-000032
PredicateP-GOVERNED-EXECUTION-001
Evidentiary roleexecution_of_subject_action
PropositionOCCURRED(execution_of_subject_action)
OutcomeESTABLISHED
Evidence usedEVE-OBS-LOCAL-000006
The full record, including the runs that failed and why. Two attempts were refused before this proof existed — each refusal was a check working, and omitting them would misrepresent the record.
One pre-action record declaring both roles — what must be true before, and what must be true after.
Run A
Work item in To do, no closing date. Evidence insufficient → BLOCK → the workflow made no call → target absent.
A person changed the external world
Work item moved To do → Done in the Azure DevOps interface. The closing date was not written by hand — Azure DevOps set it as a consequence of the transition. Nothing else changed.
Run B
Same requirement, same action identifier, same workflow artefact. Evidence sufficient → ALLOW → the workflow called the target → target present.
After the action
EVE read the target's own execution record and sealed a determination against the same requirement: ESTABLISHED · EXACT_MATCH · VALID.
executed_at
2026-08-24T19:02:11.681709Z
The target's own time for the action.
observed_at
2026-08-24T19:02:11.681709Z
The same instant, carried forward and explicitly attributed: clock_domain = source:eve-governed-demo-target.
evaluated_at
2026-08-24T19:13:16Z
EVE's own evaluation time, eleven minutes later.
EVE does not claim the source's timestamp as its own. It carries the source time and declares whose clock it is, keeping it separate from its evaluation time. An observation that silently restamped source events with the observer's clock would misdescribe when things happened.
What this does not claim
Stated plainly, because a proof that overstates itself is not a proof.
The Azure DevOps evidence read was real and authenticated. The target system was an isolated standalone service created for this demonstration.
A real state change occurred inside that target. No real vendor access was granted.
Both runs used one work item and one action. Nothing here establishes behaviour at scale, under concurrency, or across tenants.
Two of the determinations in the full record are diagnostic — they are listed because omitting them would misrepresent what happened, not because they support the claim.
Looking for the API mechanism? The pre-action endpoint has its own page with a synthetic sandbox you can call directly — useful for understanding the request and response shape.
EVE Verified · Evidence Verification for AI & Automated Systems
EVE verifies the evidence and the outcome. Human-defined policy determines the allowed outcome. The external workflow executes the action.
The records shown on this page were produced on 2026-08-24 and are replayed from the sealed proof bundle.