EVIDE
EVIDE Documentation

API Reference

Endpoints, request/response contracts, and intake profiles for integrating with EVIDE.

← Back
Documentation  ›  API Reference

Choose your intake

Both accept the same EVIDE JSON payload. The difference is what happens after intake.

Standard Intake
POST /api/intake/json

Anchors the submitted object immediately. The evidentiary boundary is crossed at the moment of submission. Use this when the source system has already reached a stable, closed decision.

ESB Buffer
POST /api/intake/esb

Opens a declared observation window before the boundary is crossed. Use this when the condition needs to be observed over time before a final verdict is recorded. Details below ↓

payload
↓
POST /intake/json
↓
Anchored
payload
↓
POST /intake/esb
↓
Observation
↓
POST /buffer/update (any number of times)
↓
POST /buffer/close
↓
Anchored

ESB Buffer (Epistemic Stabilization Buffer) Operational Intake Profile

An observation window before the evidentiary boundary

ESB is an optional operational profile for EVIDE intakes. Unlike the standard intake, which anchors the submitted object immediately, ESB introduces a declared observation window during which stabilization events can be recorded before the evidentiary boundary is crossed.

ESB does not modify the EVIDE JSON Schema and does not introduce a new schema version.
It changes how a payload is processed over time after intake — not what the payload means.

When to use ESB instead of standard intake

Standard intake (/api/intake/json) anchors the submitted object immediately: the evidentiary boundary is crossed at the moment of submission. ESB (/api/intake/esb) is for cases where the source system needs to observe an object for a declared period — recording how a condition evolves — before the boundary crossing is considered final. The same payload schema applies to both; ESB simply keeps the record open for observation instead of closing it at intake.

Endpoints

Endpoint Purpose
POST /api/intake/esb Opens the buffer at intake time. Accepts the same payload as standard intake, plus two additional optional fields (below). Response includes esb_status and buffer.buffer_id.
POST /api/buffer/update Records an observation on an open buffer — the state can be updated any number of times before closure. Does not close the buffer.
POST /api/buffer/close Closes the buffer with a final verdict. A closed buffer cannot be updated or closed again.

Intake-time fields

Field Description Status
buffer_window_hours Declared maximum observation window, in hours, requested at intake time. Used to compute window utilization when the buffer closes. optional
buffer.stabilization_source Declared origin of the stabilization assessment for this buffer. Same vocabulary as the field of the same name accepted by buffer/update and buffer/close below. optional

buffer/update and buffer/close fields

Field Description Status
buffer_verdict Final stabilization outcome. Accepted only by buffer/close — a buffer is created with an implicit pending verdict and cannot declare it explicitly.

pending — implicit default while the buffer is open. Never sent by the client. stable — the collected observations support a crossing-sufficient stabilization. unstable — stabilization could not be demonstrated within the declared window. Requires instability_reason. deferred — closed intentionally without a conclusive verdict. Requires buffer_notes. 		required at close
continuity_state Declared continuity of the observed condition. Accepted by both buffer/update and buffer/close.

coherent · partially_coherent · fragmented · unverifiable 		optional
stability_trend Declared direction of stability during the observation window.

improving · degrading · oscillating · static 		optional
causal_persistence_signal Declared whether the observed condition retained causal continuity from the prior state.

present · attenuated · absent · inconclusive 		optional
stabilization_score Numerical indicator between 0 and 100 supporting the stabilization assessment. Rejected outright if outside this range — never silently clamped. optional
instability_reason Declared cause. Required when buffer_verdict = unstable.

authority_conflict · evidence_gap · runtime_drift · observability_loss · contradictory_signals · threshold_fragmentation · unresolved_intervention · unknown 		conditional
closure_trigger Declared mechanism that caused the buffer to close. Accepted only by buffer/close.

manual_close · auto_threshold · timeout · downstream_dependency · escalation · evidentiary_freeze 		optional
stabilization_source Declared origin of the stabilization assessment.

human_review · automated_decay · quorum_resolution · timeout_expiration · external_override · mixed 		optional
buffer_notes Free-text notes. Required when buffer_verdict = deferred or when instability_reason is set. conditional
A buffer must observe a temporal window: buffer/close is rejected if less than two seconds have passed since buffer/update-style opening, unless test_mode: true is set. Once closed, a buffer cannot be updated or closed again — buffer/close on an already-closed buffer returns already_closed, not a silent success.

Timeline — a complete lifecycle

// 1. Open — POST /api/intake/esb
{
  "evide_schema": "2.1",
  // ... same payload fields as standard intake ...
  "buffer_window_hours": 2,
  "buffer": { "stabilization_source": "human_review" }
}
// → { "success": true, "esb_status": "active", "buffer": { "ok": true, "buffer_id": 1 } }

// 2. Observe — POST /api/buffer/update (any number of times)
{
  "buffer_id": 1,
  "stability_trend": "improving",
  "continuity_state": "coherent",
  "causal_persistence_signal": "present"
}
// → { "success": true, "buffer_id": 1, "updated_fields": 3 }

// 3. Close — POST /api/buffer/close
{
  "buffer_id": 1,
  "buffer_verdict": "stable",
  "closure_trigger": "manual_close",
  "stabilization_score": 88.5
}
// → { "success": true, "buffer_verdict": "stable", "window_seconds": 196,
//     "semantic_note": "crossing-sufficient, NOT absolute epistemic truth" }
Architectural note. ESB does not make EVIDE a monitoring system: it does not poll, does not watch runtime state on its own, and does not decide when a buffer should close. Every observation and every closure is an explicit, upstream-initiated call. EVIDE records what it is told, when it is told.

A stable verdict is crossing-sufficient — it means the observation process, as recorded, supports treating the boundary as crossed. It is not, and is never presented as, absolute epistemic truth.

How to deposit

  1. Log in to the portal with your DAPI code
  2. Create a new request and select the JSON structured type
  3. Paste the JSON payload into the dedicated field
  4. The system validates, canonicalises and computes the SHA-256 hash
  5. Receive the EVIDE code and the downloadable canonicalised file
API Access

API access available for enterprise integrations

An API endpoint is available for depositing EVIDE records directly from external systems. Access is reserved for certified partners and enterprise clients. Contact us to receive technical documentation and access credentials.

Request API access

Ready to deposit?

Log in to the portal with your DAPI code and create your first structured JSON deposit.

Access the portal Try the demo