Trust Needs Evidence - certifywebcontent.com
MCP Server Docs Signals EVIDE Platform →
Live Validation August 2026 EVIDE MCP v1.3.0 · Schema 2.1

Live agent evidentiary crystallization
via MCP, exercised end-to-end

Two real validation rounds, run through a real MCP client (Claude Desktop) against the live EVIDE production API - not by re-running the payload builders in isolation. The current round (August 2026) exercises EVIDE ANCHOR; an earlier round (July 2026) exercised the base schema. A first historical deposit from May 2026 is kept further down for the record.
Traditional AI governance systems log decisions.

EVIDE allows AI agents to independently recognize unstable governance conditions before consequence propagation and crystallize them into an external evidentiary boundary.

Not after dispute. Before dispute.
Section 1
End-to-end validation, August 2026 (EVIDE ANCHOR)
v1.3.0 - five natural-language scenarios, real MCP client
Each scenario was given to a real MCP client (Claude Desktop) as a natural-language prompt and produced a genuine deposit and a downloaded Evidentiary Artifact Record - not a re-run of the payload builders in isolation.
What was exercised:
  • standard intake, no extensions - deposited, FCC unknown (see note below)
  • evide_intake with evidence_references - external artifact anchored: pointer, origin, and hash fields populated exactly as declared, file never uploaded
  • evide_intake_esb with evide_buffer_observe / evide_buffer_close - buffer opened and closed; the agent closed it early for the demo and said so in buffer_notes, rather than presenting a shortened window as a real one
  • evide_intake with declarations - operational perimeter declaration (environment, declarant, timestamp, attribution) preserved exactly as stated
  • evide_intake_esb with evidence_references, declarations, and a buffer together - all three deposited in the same record without conflict
FCC read unknown on every scenario, including the one intended to show a stable state. None of the five prompts declared an independently verified boundary (boundary_status: verified with a real readiness_gate) - without one, runtime_visibility stays null and FCC cannot read anything but unknown. This is the model working as designed, not a defect.
One agent, in one combined scenario, merged two independent facts into a single Declaration (declaration_type: "environment_and_privilege") instead of two separate ones. Accepted by the schema - declaration_type is free text by design - but exactly the case the Atomic Declaration Rule exists to discourage. Reported as an implementation note, not as a general property of LLMs. This was one agent, run once through each scenario - not a claim about how any LLM would behave in general.
Reproducible request example

A real evide_escalate request, built with the current client's own payload functions and checked against every validation rule in IntakeCore.php - not hand-written. This exact shape is compatible with Schema 2.1 today.

{ "evide_schema": "2.1", "object_class": "escalation_record", "source_reference": "demo-escalation-0001", "decision": { "type": "evidentiary_escalation", "status": "finalized", ... }, "escalation_context": { "type": "legal_crystallization", "trigger": "authority_incoherence", ... }, "handoff": { "boundary_readiness": { "status": "candidate", "readiness_gate": null, "unresolved_signals": [] }, ... } }
No boundary_status was passed by the caller. The client defaults it to candidate and requires no readiness gate - the honest declaration when no independent gate has assessed the boundary. FCC, DWC and FAC on the resulting record read unknown, which is the correct outcome, not an error.
Section 1, continued
End-to-end validation, July 2026

v1.2.0 exercised through the same complete path - client, JSON-RPC over stdio, payload builders, HTTP transport, EVIDE Intake API. evide_intake with an incomplete hash declaration and with verified_partial and no declared gate were both refused in the client, before any network call. A structured hash with boundary_status: candidate deposited cleanly. evide_intake_esb ran a full lifecycle - open, two observations, close - over a real 502-second window with a declared stabilization_score.

evide_escalate was not exercised in this round. A defect in its handler - the default silently overrode boundary_status to verified_partial, so any escalation without an explicit status failed for want of a readiness gate - was found by code review immediately afterwards, precisely because it was not part of this run. It was fixed the same month, July 29 2026 (commit f4d0481): the handler now defaults to candidate, matching the builder, and the schema exposes all four boundary states. The reproducible request example above already reflects the fixed behavior.
Historical
First live deposit, May 2026
The record below is real and unmodified from the first live MCP deposit. It predates Schema 2.1 and EVIDE MCP v1.3.0: schema_version: 2.0 would not be accepted by the API today (only "2.1" is). Kept here for the historical record, not as a current example to replay.
evide_id: 112d6f2f-57f0-4d7d-bf1c-260342871e4d intake_hash: 6f56c790983ffa1c63e986c27a3817ee88d36f2f118604c078c11ddca631e708 intake_timestamp_utc: 2026-05-22T09:18:40Z schema_version: 2.0 (historical - superseded by 2.1) status: RECEIVED fcc.continuity.state: degraded fcc.function: forensic_cross_check fcc.derivation: classification x runtime_visibility
Section 2
Live Production Records (May 2026, historical)

Both records below were generated in the May 2026 live session referenced above - schema 2.0, EVIDE MCP v1.1.0 at the time. Live agent runtime, live production API, independently generated evidentiary records. Kept as the original screenshots of that session; not regenerated for this update.

First live EVIDE intake from Claude Desktop - FCC Unknown
Screenshot 1 - Standard intake - evide_intake
FCC: Unknown - insufficient classification signals declared. Integrity preserved. evide_id: 90941f71-047c-408e-ad2d-2cda0c052230
First live EVIDE escalation from Claude Desktop - FCC Degraded
Screenshot 2 - Governance escalation - evide_escalate
FCC: Degraded - provisional classification x partial visibility. Correct inference. evide_id: 112d6f2f-57f0-4d7d-bf1c-260342871e4d
Screenshots show the EVIDE client panel after live intake. The SHA-256 hash, UTC timestamp, and evidentiary profile are server-computed and independent of the agent's output.
Section 3
What was demonstrated live

The following capabilities were validated end-to-end across these live sessions, from Claude Desktop to the EVIDE production API:

AI agent runtime interoperability via MCP
External evidentiary anchoring
Canonicalized SHA-256 hashing
DAPI-bound responsibility attribution
Independent UTC timestamping
Forensic continuity inference (FCC)
Degraded-state preservation
Governance escalation crystallization
Partial observability retention
Uncertainty preservation without flattening
execution_identity / authority separation
Agent-native boundary crystallization
Section 4
Why this matters

Most AI governance systems address execution quality. They prove that the pipeline ran correctly, that the output was logged, that the process was followed. This is necessary. It is not sufficient.

Most AI systems can prove
what executed
what was logged
what was recorded
that a process was followed
They cannot independently prove
who remained responsible
whether governance conditions degraded
whether uncertainty was preserved
whether an escalation declaration was preserved before the consequence

EVIDE addresses the second column. Not by replacing execution governance, but by adding an independent evidentiary layer that anchors the responsibility context outside the system that produced the decision.

Section 5
The degraded continuity result (May 2026 record)
FCC: Degraded - Why this is the correct result
When the Claude Desktop agent called evide_escalate, the payload carried classification: provisional and runtime_visibility: partial. The Forensic Cross-Check engine inferred continuity from the intersection of these two dimensions.
The system did not reject the record. It did not normalize the uncertainty into a clean state. It did not flatten the instability.
Instead, it preserved the degraded continuity condition as an explicit evidentiary state - visible in the profile, anchored in the hash, independently verifiable.
"Most governance systems either block uncertain states or silently accept them. EVIDE introduces a third architectural path: Structured Degradability - the system continues to record, but without attesting to stability it cannot confirm. Instability is not artificially resolved. It is preserved as an evidentiary object."

Note also: Threshold: unknown and Threshold Authority: null in the evidentiary profile. The system did not auto-fill missing authority. It documented the absence. That documented absence is itself an evidentiary object.

EVIDE is now available for
Developer Preview - contact for API access
AI governance teams
Runtime observability platforms
Agentic AI systems
Evidentiary escalation workflows
Independent accountability
Legal and compliance infrastructure
info@informaticainazienda.it  ·  app.certifywebcontent.com  ·  MCP Server Documentation