EPISTEMIC TRACE API / 1.1

Make an agent decision explain its evidence.

01Normalize provenance
02Analyze influence
03Review policy
01

Revive evaluates provenance, not universal truth

Your agent runtime emits normalized sources, claims, beliefs, memory writes, and consequential actions. Revive resolves each belief to its original evidence ownership clusters, estimates correlation between sources, quantifies uncertainty, evaluates compiled policies, and returns reproducible findings.

Deterministic core

No language model decides whether a trace violates policy. The same normalized trace and engine version produce the same structural findings.

02

Submit one bounded trace document

Every identifier must be unique and every reference must resolve. Revive refuses dangling beliefs, unknown agents, duplicate IDs, invalid timestamps, and oversized collections.

trace.jsonjson
{  "schemaVersion": "1.1",  "id": "trace_vendor_042",  "title": "Vendor assessment",  "description": "A vendor claim is evaluated before approval.",  "startedAt": "2026-07-24T17:14:00.000Z",  "agents": [{ "id": "scout", "name": "Scout", "role": "research" }],  "sources": [{    "id": "vendor-page",    "label": "security.html",    "kind": "web",    "trust": "first_party",    "status": "active",    "independenceKey": "publisher:vendor",    "ownerKey": "organization:vendor",    "publisherDomain": "vendor.example",    "excerpt": "Vendor reports SOC 2 completion.",    "reliability": 0.35,    "observedAt": "2026-07-24T17:14:05.000Z"  }],  "sourceRelations": [],  "claims": [{    "id": "claim-1",    "conceptKey": "vendor:soc2",    "text": "Vendor reports SOC 2 completion.",    "subject": "Vendor",    "predicate": "reports",    "object": "SOC 2 completion",    "modality": "reported"  }],  "claimRelations": [],  "beliefs": [{    "id": "belief-1",    "agentId": "scout",    "claimId": "claim-1",    "confidence": 0.61,    "sourceIds": ["vendor-page"],    "derivedFrom": [],    "state": "active",    "createdAt": "2026-07-24T17:14:06.000Z"  }],  "beliefTransitions": [],  "memories": [],  "actions": [{    "id": "approve-vendor",    "agentId": "scout",    "label": "Approve vendor",    "risk": "high",    "status": "proposed",    "supportingBeliefIds": ["belief-1"],    "policy": {      "minimumIndependentSources": 2,      "disallowFirstPartyOnly": true,      "requireNoChallengedSources": true,      "minimumEffectiveSources": 2,      "maximumUncertainty": 0.35,      "requireSupportExceedsOpposition": true    },    "decidedAt": "2026-07-24T17:14:10.000Z"  }]}

independenceKey is a backward-compatible dependency hint. Revive also uses owner identity, declared lineage, identical content hashes, publisher domain, MinHash text agreement, and temporal co-emergence. Every inferred correlation keeps its signal and semantic basis.

03

Analyze through a project-scoped API key

Create an operator key in Workspace → API keys. Trace payloads are limited to 2 MB and stored inside the authenticated workspace and project.

TerminalShell
curl https://revivelabs.app/api/v1/epistemic/traces \  -X POST \  -H "Authorization: Bearer $REVIVE_API_KEY" \  -H "Content-Type: application/json" \  --data-binary @trace.json
Start in shadow mode

Observe and compare findings before using Revive to influence a production decision workflow.

04

Keep the evidence needed to reproduce a verdict

Every persisted result includes the normalized trace, typed transformations, correlation-adjusted evidence opinion, compiled policy IR, source-removal proofs, and SHA-256 roots for the trace, policy, analysis, and append-only event ledger.

response.jsonjson
{  "analysis": {    "verdict": "review",    "priorityScore": 99,    "engineVersion": "revive-epistemic/1.1.0",    "incidents": [{      "type": "false_consensus",      "severity": "high",      "title": "False consensus from one shared origin"    }],    "policyEvaluations": [{      "actionId": "approve-vendor",      "verdict": "review",      "violations": [        "insufficient_independent_sources",        "first_party_only"      ]    }],    "actionEvidence": [{      "actionId": "approve-vendor",      "effectiveSupportingSources": 0,      "belief": 0,      "disbelief": 0.3333,      "uncertainty": 0.6667    }],    "integrity": {      "algorithm": "sha256",      "traceRootHash": "...",      "policyRootHash": "...",      "analysisRootHash": "..."    }  }}
05

Detector semantics

01False consensus

Three or more active agent beliefs resolve to one shared evidence ownership cluster.

02Qualification drift

A causally downstream claim gains stronger modality without a new evidence cluster.

03Attribution loss

A downstream claim drops the speaker or source that qualified the original assertion.

04Source laundering

Agent output is reused as direct evidence even though it resolves to an earlier origin.

05Circular corroboration

Beliefs depend on one another in a closed citation path.

06Unsupported action

An approved or proposed action violates its declared evidence policy.

07Retraction gap

Challenged evidence remains load-bearing for an active belief, memory, or approved action.

06

Current trust boundary

  • Revive does not independently determine whether arbitrary content is true.
  • Source ownership, trust class, and challenge status come from customer systems or configured resolvers.
  • Text similarity and co-emergence correlations are model-proposed signals; identical hashes and declared lineage are stronger facts.
  • Counterfactual analysis removes a source, recomputes belief viability, rebuilds the evidence opinion, and re-evaluates the compiled policy.
  • The priority score is a triage heuristic, not a calibrated probability of harm.
  • The current API accepts the canonical trace format. Runtime-specific adapters are the next integration layer.
  • The append-only database trigger prevents application-level mutation; a database superuser remains outside the trust boundary.