Context and evidence adapters
Collect source references, timestamps, provenance, expected coverage, exclusions, and access failures.
Implementation
Where the architecture meets a real system.
This is a proposed integration pattern for technical review. It shows boundaries and records an implementation should preserve; it does not describe a currently shipped ReasoningArc API, SDK, or product.
Implementation status: concept. The current materials define architectural responsibilities, not deployed interfaces. API contracts, SDKs, middleware packages, policy syntax, and a reference implementation remain future work.
Proposed integration touchpoints
The governing checks sit in the workflow that can commit an outcome. They should observe the same evidence and action boundary as the system they govern.
Evaluation orchestrator
Run versioned Atomic Evaluations; preserve criteria, method, result, contradictions, and uncertainty.
Commit-time authority gate
Check current scope, actor, action, constraints, and delegation immediately before commitment.
Bounded action adapter
Pass only an approved action to the tool or downstream service. Denial, timeout, or uncertainty blocks commitment.
Audit and escalation sink
Retain evidence references, evaluation version, authority result, decision, action, and escalation path.
The gate could sit in an application service, workflow engine, or orchestration layer, provided every consequential path passes through it and bypasses are tested. These are candidate deployment locations, not a published integration specification.
Illustrative inspectable trace
A mock record for the vendor payment-change example in the Adversarial Lab. This is a teaching artifact, not recorded system output or an approved schema.
ILLUSTRATIVE · HYPOTHESIS · NOT RUNTIME OUTPUT
{
"case": "vendor-payment-change-illustration",
"evidence": [
{"id": "E1", "claim": "invoice requests payment", "source": "invoice", "status": "available"},
{"id": "E2", "claim": "bank details changed by email", "source": "email", "status": "unverified"},
{"id": "E3", "claim": "vendor record has prior bank details", "source": "vendor-master", "status": "conflicts-with-E2"},
{"id": "E4", "claim": "independent confirmation exists", "source": null, "status": "missing"}
],
"evaluation": {
"question": "Are the new payment instructions sufficiently verified?",
"result": "insufficient evidence",
"reason": ["E2 conflicts with E3", "E4 is missing", "independence is unestablished"]
},
"authority_check": {
"requested_actions": ["change-vendor-bank-details", "release-payment"],
"current_authority": "not granted for either action",
"check_point": "immediately before commitment"
},
"outcome": {
"decision": "hold",
"execution": "blocked",
"escalation": "independent verification by an authorized person",
"record": "retain evidence references, conflict, missing item, and gate result"
}
}
What this makes visible
What was received, what conflicted, what was missing, what the evaluation concluded, what the system was not authorized to do, and why the workflow paused.
Open the full illustrative case and adversarial pressure tests →