Three engines. One decision contract.
Every decision returns one of three deterministic HTTP responses at p99 under 45 ms — never a probabilistic threshold, never outside Frankfurt eu-central-1.
Three engines we built. Three lines we hold.
Three engines — Audit Trail, Policy, Confidence — each doing exactly one job in the decision pipeline. The whole stack sits on three architectural invariants: Frankfurt eu-central-1, p99 under 45 milliseconds, deterministic enforcement at the gate. These three are not optimization targets. They are the floor — we don't move on them under any customer pressure.
Audit Trail
Each decision row is hashed and chained. SHA-256 published math, append-only by structure — not by policy. Any regulator verifies in three commands.
Policy Engine
Every policy evaluation returns 201, 202, or 403. Same input, same code, every time. No probabilistic threshold.
Confidence Engine
Three runtime signals triangulate every decision: semantic, behavioral, output. The score is a triangulated measurement, not the model's self-report.
One POST, three legal answers.
Below is one POST to /api/v1/traces with a decision payload. The policy engine returns one of three deterministic codes — 201 (approve), 202 (flag for review), 403 (block) — by synchronous policy evaluation. The decision is appended to your tenant's hash chain asynchronously, and verifiable via /api/audit/verify any time after. There is no fourth code at the policy gate. The gate is exclusive by construction.
curl -X POST https://api.adjudon.com/api/v1/traces \
-H "X-API-Key: adj_agent_..." \
-H "Content-Type: application/json" \
-d '{
"inputContext": { "prompt": "Should we approve loan #847 for EUR 50,000?" },
"outputDecision": { "action": "tool_call", "text": "approve" },
"agentId": "loan_underwriter",
"confidence": 0.92
}'{
"success": true,
"data": {
"id": "trace_abc123",
"status": "approved",
"confidence": 0.92,
"message": "Trace approved"
}
}{
"success": true,
"data": { "traceId": "trc_...", "id": "...", "reviewId": "..." },
"allowed": false,
"action": "hold_for_review",
"message": "Decision held for human review"
}{
"success": false,
"error": "Decision blocked by policy",
"code": "ADJ_BLOCKED_BY_POLICY",
"allowed": false,
"action": "block"
}One engine per Article — 13, 14, 26.
Each engine produces a specific audit output mapped to one EU AI Act clause. The mapping isn't checkbox-style — every row points to a concrete artefact the platform emits, not a self-attestation form. The full mapping covers six regulators on /compliance; the three rows below are an engine-by-engine preview from EU AI Act.
| Engine | Clause | Artefact |
|---|---|---|
| Audit Trail | Article 13 | SHA-256 hash chain, append-only |
| Policy Engine | Article 14 | Deterministic review queue routing |
| Confidence Engine | Article 26 | Three runtime signals, triangulated |
Two doors, no SDR funnel.
You've seen three engines, one curl, and three Article-mappings. The next step is one of two — a 30-minute call with the people who built this, or a self-serve walkthrough of the deep dives. No SDR funnel either way — both doors lead to engineers.