Epistemic Stabilization Buffer (ESB)

The Epistemic Stabilization Buffer (ESB) is an optional intake profile. A record deposited through the ESB endpoint is accepted, canonicalized, hashed and finalized exactly like a Standard intake; in addition, a bounded observation window is opened on it. While the window is open, the submitting system can record declared observations of a situation that is still evolving. The window is then closed with a declared stabilization verdict, which is crystallized into a new version of the evidentiary record.

ESB is requested, not inferred. It is opened only by depositing through POST /api/intake/esb: every successful intake on that endpoint opens a buffer, whether or not the optional ESB fields described in Section 2 are declared. The Standard endpoint never opens a buffer and refuses the ESB fields.

• One buffer per intake. A buffer is opened only at the moment of intake. It cannot be added later to an intake that was deposited without it, and it cannot be reopened once closed.
• API only. ESB is available through the EVIDE API and through the EVIDE MCP server, which calls the same endpoints. It is not offered for manual deposits from the dashboard or for deposits from EVIDE Mobile.
• Everything is declared upstream. EVIDE does not observe the situation on its own. Every observation and every closure is an explicit call made by the submitting system.

The endpoint accepts the complete Standard 2.1 payload, with the same authentication, validation and DAPI binding, plus two optional top-level fields:

• buffer_window_hours — the declared duration of the observation window, as a positive integer number of hours. A string such as "2", zero or a negative number is not accepted.
• buffer.stabilization_source — the declared mechanism expected to produce the eventual verdict. One of: human_review, automated_decay, quorum_resolution, timeout_expiration, external_override, mixed. It is the only member of the buffer object that the platform reads.

On success, the response carries the Standard intake response fields, together with "profile": "esb", "esb_status": "active" and a buffer member:

If the intake succeeds but the buffer cannot be opened, the intake is not rolled back — it has already been recorded. The response reports the failure explicitly:

While a buffer is open, any number of observations may be recorded against it. Each observation declares how the situation is evolving, using a fixed vocabulary:

Every field is optional on a single call, but at least one is required: a call carrying only buffer_id is rejected with no_fields. A successful call returns the number of fields updated.

The buffer itself always holds the latest declared values. The history is not lost: every observation is written to the buffer's event log together with the state before and after it (Section 6).

Closing a buffer requires exactly one of three verdicts, declared by the submitting system. The verdict pending exists only while the buffer is open and is never sent by the client. EVIDE preserves the declared verdict and the elements declared with it; it does not establish, on its own, whether the observed system was in fact stable or unstable.

A minimum window applies: closing less than two seconds after opening is rejected as temporal_violation, unless test_mode: true is set. The closure response returns the verdict, the opening and closing times (UTC), the length of the window in seconds, the closure trigger, the score and the causal persistence signal.

Once closed, a buffer is permanently closed. It cannot be updated or closed again, and the two misuses are distinguished at the API level — buffer_closed from /buffer/update, already_closed from /buffer/close, both with HTTP 409. If two closures arrive at the same moment, exactly one is applied; the other receives already_closed with the verdict that was actually recorded. The same protection applies to an observation that arrives while the buffer is being closed.

buffer_window_hours records the duration that the submitting system declared for its observation. The platform does not run a timer on it: a buffer is not closed automatically when the declared window expires, and it remains open until the submitting system closes it.

• The dashboard shows the declared window, the actual duration and the window utilization (actual duration ÷ declared window). A utilization above 100% means that the buffer was kept open longer than declared — a fact that remains visible, not an error that the platform corrects.
• closure_trigger: timeout and stabilization_source: timeout_expiration are declarations made by the submitting system. They do not mean that EVIDE expired the window.
• A buffer that is never closed stays OPEN / PENDING in the record. The absence of a verdict is itself part of what the record shows.

Every step of the buffer's life is written to an event log: the opening, each observation and the closure. Each event records its UTC time, the declared values and the complete state of the buffer before and after it. Events are only added, never edited.

Every intake produces an EAR the moment it is finalized, with or without ESB. Opening a buffer does not delay it: the first EAR version (trigger_reason: intake_finalized) already carries an ESB section showing Status: OPEN, Verdict: PENDING and the lifecycle Open.

Closing the buffer automatically generates the next EAR version (trigger_reason: esb_closed) — normally version 2. It carries the final ESB state:

• status, verdict, opening and closing times (UTC);
• stabilization score, causal persistence, stability trend and continuity state, when declared;
• instability reason and closure trigger, when declared;
• the number of observation events, the lifecycle (for example Open -> Unstable) and the notes.

The declared window and the stabilization source are not restated in the EAR; they are kept on the buffer and in its event log, and are shown on the dashboard.

A FEDIS issued for the intake references, with its SHA-256, the EAR version current at issuance, and states the trigger that generated it — ESB closed (automatic) when that version is the closure record. The FEDIS does not restate the ESB verdict or timeline: they are in the EAR it references. A FEDIS requested while the buffer is still open references the version that shows the window open.

The evidentiary profile — identity, authority, classification, threshold, boundary_readiness, runtime_visibility, and the three inferred dimensions continuity (FCC), decision_wave_compression (DWC) and formal_accountability_collapse (FAC) — is computed exactly once, at intake, from the payload declared at that moment.

ESB operates entirely afterward, on a separate set of fields, stored in a separate structure and reported in a separate section of the EAR. Observing a buffer through any number of updates and a closure never recomputes FCC, DWC or FAC — even when the declared stabilization signals evolve significantly across the window. The buffer's continuity_state and FCC's continuity are two different vocabularies: the dashboard displays them with the same four colours for readability, and nothing more connects them.

A buffer belongs to the intake it was opened on, and therefore to the user who deposited that intake. Observing or closing it requires an API key bound to that same user, which passes every check that applies to intake: a key that is active and not revoked, expired or suspended; an activated API plan; an active EVIDE account.

If the intake was deposited for an organization, the key holder must also be a current member of that organization at the time of the call, whatever key is used. A member who has left the organization cannot observe or close the buffer: the call is refused with 403 organization_authority_required and nothing is written. Authority to act is assessed at each call; historical attribution of the deposit does not confer it.

• Visibility. The ESB panel is shown read-only on the intake page in the dashboard: verdict, declared window, duration and utilization, the declared values and the events recorded. A depositor who has left the organization keeps read-only access to the intakes they deposited, including this panel, without any power to act.
• Deletion. When the deletion of an intake is authorized, its buffer and the buffer's event log are deleted together with it.

Observation and closure errors use the same response shape: {"success": false, "error": "...", "message": "..."}. Authentication, plan, account and organization errors are those of the intake endpoints.

ESB is a lifecycle mechanism for recording declared observations over a bounded window. Its scope is precisely bounded:

• A stable verdict does not establish factual correctness, legal validity or absolute epistemic truth — it records that the submitting system declared its stabilization conditions satisfied, nothing more
• ESB makes the declarative chronology before the verdict reconstructable — which observations and declarations were deposited, in which order, when and by whom — not the internal reasoning or the decision process that produced the verdict
• ESB does not independently verify the observations recorded during the window — stability_trend, continuity_state and every other observation field are declarations, not EVIDE-verified facts
• ESB does not enforce the declared window and does not close a buffer on its own (Section 5)
• ESB does not reopen, extend or amend a closed buffer — closure is final
• ESB does not alter an existing EAR version — the record of the open window remains exactly as generated (Section 6)
• ESB does not modify the evidentiary profile computed at intake — FCC, DWC and FAC are unaffected by any observation or by the closure verdict (Section 7)

ESB is declared as a vendor framework construct in the public EVIDE GLM manifest, under vendor_framework_constructs, using the vendor-local alias EVIDE:ESB. The entry below is reproduced from the live manifest (manifest_version 8.0, published 12 September 2026), without restatement or expansion.

EVIDE Framework: certifywebcontent.com - Evidentiary Deposit

API Reference — ESB Buffer: app.certifywebcontent.com/api-reference

EVIDE JSON Schema: app.certifywebcontent.com/json

EVIDE Intake Schema Documentation: Intake schema reference

Evidentiary Artifact Record (EAR): EAR versions and their triggers

EVIDE MCP Server: ESB tools for agentic systems

Forensic Cross-Check (FCC): Server-computed evidentiary inference

DWC/FAC Technical Note: Decision Wave Compression and Formal Accountability Collapse

EVIDE v2.x Roadmap: Architectural Backlog and Experimental Constructs