⚓ New — EVIDE ANCHOR
Was the system authorized to be there, with those tools, before it acted?
Physical AI systems operate within zones, tool authorizations, and maneuver limits that are rarely declared in a form that survives an incident. EVIDE ANCHOR preserves the declared operational perimeter — which zone, which actuators, which maneuvers were off-limits — before the system ever crossed into it. Not runtime enforcement. Not an access-control system. An external, timestamped declaration of what was authorized, so that after an incident the record does not depend on the system whose behavior is in question.
Declared operating zone
e.g. "restricted maintenance bay" — not "public walkway"
Declared tool / actuator authorization
Which end-effector, which payload class was in scope
Declared prohibited maneuvers
e.g. no autonomous lift above 1.2m without operator confirmation
Motivated by an incident with a software agent — mistaking a production database for a disposable test environment — the same gap applies physically: a declared perimeter, absent beforehand, cannot be reconstructed afterward from memory or configuration history alone.
EVIDE ANCHOR — full field reference ↗
Building blocks for evidentiary AI governance
Every organization produces different evidence, follows different workflows, and identifies people differently. EVIDE provides a common evidentiary foundation across them all.
Complementary capabilities available across EVIDE deployments
Native capability
External Artifacts
Anchor external evidence without storing it.
Supports sensor logs, video, thermal imagery and more.
Native capability
Epistemic Stabilization Buffer
Observe evolving situations before producing a final evidentiary record.
Designed for boundary events that evolve before closure — complements the single-state MCP escalation flow in Section 8.
Integrated with DAPI Identity Certification
Verified Human Identity
Associate a declared decision with a verifiable human identity.
EVIDE anchors the declared DAPI certification reference. Identity verification remains independently provided by DAPI.
Hands-on Evaluation
Are you a robotics company? Try EVIDE free in the Lab.
The EVIDE Governance Lab lets you submit real evidentiary intakes, see FCC, DWC/FAC and the Epistemic Stabilization Buffer computed live, and download the automatically generated Evidentiary Artifact Record (EAR). No DAPI identity verification. No integration. No commitment. No cost.
Open EVIDE Governance Lab ↗
Lab environment - for exploration and testing only, no legal or evidentiary value.
Section 1
1. Why This Matters Now
Every Physical AI incident
eventually becomes an evidentiary problem.
Once an incident is investigated, the question is no longer only what happened. It becomes what can still be independently reconstructed — months later, by someone who was not there, using nothing but what was preserved outside the system itself.
Physical AI systems - humanoid robots, service robots, drones, AGVs, cobots - are increasingly interacting with people in uncontrolled environments: public events, hospitals, warehouses, homes, streets. Regulatory frameworks are catching up to this reality, but unevenly, and on a timeline that does not match deployment velocity.
The regulatory framing. Under the EU AI Act, high-risk AI systems face record-keeping obligations (Art. 12), human oversight requirements (Art. 14), and deployer obligations (Art. 26). The Digital Omnibus on AI, agreed by the Council and Parliament and signed on 8 July 2026, would defer standalone high-risk obligations under Annex III to 2 December 2027 and those for systems embedded in regulated products under Annex I - the category many physical AI systems fall into as safety components of machinery - to 2 August 2028. These deferred dates take legal effect only once the Omnibus is published in the Official Journal of the European Union; until then, the original 2 August 2026 deadline remains the operative one.
Compliance deadlines can wait.
Incidents do not.
An incident occurring before a regulatory deadline does not become uncovered. It simply arrives before the evidentiary practices that deadline was meant to enforce have been established.
Waiting for a compliance deadline to begin building evidentiary infrastructure is, by definition, too late for anything that happens before it. The gap between deployment and evidentiary readiness is not a future risk - it is the current default state for most physical AI programs.
This pattern is not hypothetical. The absence of an independent evidentiary record at the moment it mattered has already played out repeatedly across other AI-assisted sectors - insurance, healthcare, public administration, legal services.
See documented cases →
Section 2
2. Without EVIDE / With EVIDE
The same incident, reconstructed under two different evidentiary conditions.
Without EVIDE
- No independent record of what the system reported observing before the incident
- Manufacturer, operator, and insurer each rely on their own account - no neutral substrate to reconcile them
- Internal telemetry can be edited, overwritten, or selectively preserved after the fact
- Regulatory or insurance review finds no externally verifiable timestamp for the boundary moment
- Sensor logs, camera images, thermal imagery, and maintenance records exist scattered across internal systems, with no declared, externally anchored relationship connecting them to the incident record
- An evolving incident - a collision still under review, a fallback still being assessed - is captured only as whatever snapshot existed at the moment someone happened to look, with no declared window documenting how the picture stabilized
With EVIDE
- Each declared boundary state is anchored externally, independently timestamped via RFC 3161
- The record is owner-attributed through DAPI-verified identity - not anonymous, not self-declared
- Tamper-evident: the deposit cannot be retroactively altered without invalidating the chain of custody
- Available to manufacturer, operator, and insurer alike - a neutral substrate none of them controls alone
- External artifacts - sensor logs, camera images, thermal imagery, LiDAR exports, diagnostic reports, signed maintenance records - are referenced through the declared record, with their origin and an integrity hash declared by the submitter (never independently verified by EVIDE), without EVIDE ever receiving, storing, or interpreting the underlying files
- For events that evolve over minutes - a collision under review, a software fallback, a human override - the Epistemic Stabilization Buffer keeps a declared observation window open until the picture is complete, producing one finalized record instead of disconnected snapshots
Section 3
3. What EVIDE Is Not
Before anything else: this is not another system asking to sit inside your robot's control loop.
- a safety controller
- a collision avoidance system
- an emergency stop mechanism
- a robot governance engine
This distinction is architectural, not a disclaimer. EVIDE operates strictly within the evidentiary layer - observation, crystallization, reconstruction. It does not enter the territory of judgment, compliance determination, or liability attribution.
EVIDE certifies
- the system reported observing a specific state
- at a specific, independently verifiable timestamp
- under the accountability of a DAPI-verified owner
- with a tamper-evident chain of custody
EVIDE does not certify
- that the robot acted correctly
- that the deployment was compliant
- that the operator was negligent
- that the system was safe or unsafe
For robot manufacturers specifically. Integrating EVIDE does not imply that incidents are expected or that the system is unsafe. It provides an independent record of what the system reported observing - which, in most incident investigations, is precisely the evidence that demonstrates the system functioned as designed. In a contested public incident, an EVIDE deposit at crossing-time independently documents what the system reported observing before and after the critical moment - evidence that, in most investigations, supports rather than undermines the manufacturer's account. That is a manufacturer shield, not an admission of risk.
EVIDE operates after observation
and before reconstruction.
It does not intervene in physical execution. It preserves what was observed at the boundary - independently, before any party has had the opportunity to interpret it.
Section 4
4. Who It Serves
Three distinct stakeholders carry different accountability burdens after a physical AI incident. EVIDE addresses all three from a single independent evidentiary layer.
Robotics OEMs
Manufacturers
- --Independent proof the system functioned as designed
- --Defense against "autonomous malfunction" narratives
- --No IP exposure - declared state observations only
Deployment Operators
Event organizers, service operators
- --Documented compliance with safety perimeters
- --Independent record of environment conditions at event time
- --Separation of deployment responsibility from system responsibility
- --Named accountability via DAPI - the responsible engineer signs with their own verified identity, creating a personal evidentiary anchor that works both as protection and as a professional incentive for diligence
Insurers
Product liability, event liability
- --Tamper-evident record not controlled by any liable party
- --Reduces post-incident reconstruction disputes
- --RFC 3161 timestamping admissible in legal proceedings
On named accountability. When a company assigns a named engineer as responsible for a physical AI deployment and that person signs the evidentiary record with their own
DAPI-verified identity, the accountability is no longer abstract. It is personal, permanent, and independently verifiable. An engineer who knows their name is on the record works differently from one who operates behind an anonymous organizational process. DAPI does not create pressure - it creates clarity.
Section 5
5. Why Existing Logs Are Not Enough
Every serious physical AI platform already logs extensively - sensor states, decisions, error codes, telemetry. So why does any of this matter?
- Logs are mutable in practice - retained, edited, or overwritten by the same infrastructure that produced them
- Logs remain inside the manufacturer's own systems - self-declared, not independently verifiable
- Logs describe execution - what the system did - not the declared boundary condition that matters to those reconstructing it later
- Logs are not independently attributed - an internal user ID or system tag is not the same as a DAPI-verified identity
- Logs are not external evidentiary deposits - nothing prevents them from being unavailable, incomplete, or contested by the time a dispute reaches review
None of this makes internal logs useless. It means they cannot, on their own, provide what an independent reviewer needs months after the event: a record that does not depend on the trustworthiness of the system that produced it.
Section 6
6. The Observation Problem
Public incidents involving autonomous physical systems tend to follow a familiar pattern. A short clip circulates showing an isolated moment of contact. It is technically accurate. It also excludes nearly everything that came before it.
A wider recording of the same event, from a different vantage point, tells a longer story: the system's trajectory, the boundary it was operating within, the moment a person entered its path, and only then, the point of contact.
Short clip - narrow frame
Implied reading: the system was at fault
Wide recording - full frame
trajectory begins
↓
boundary visible
↓
person enters zone
↓
contact
Implied reading: a deployment or perimeter issue
Same physical event. Two divergent reconstructions. Two opposite governance implications - one pointing toward the robot system, one pointing toward the deployment context.
Neither reconstruction is necessarily false. Each reconstruction inherits the limits of its observational window.
The divergence is not a question of manipulation or altered evidence. It is a direct consequence of observational frame selection. A video that circulates is often technically accurate. It simply does not capture enough of the contextual structure to reconstruct the event at governance level.
Two observers can reconstruct the same physical event differently - not because one is lying, and not because evidence was altered, but because observational visibility differs. The frame of observation itself becomes part of the evidentiary condition.
This is particularly acute for physical AI incidents because the systems themselves generate sensor data continuously - but that data is internal, manufacturer-controlled, and not independently preserved at the moment of the event.
The question is not only
"what happened?"
The question is
"what did the system report observing
when it happened?"
These are different evidentiary questions with different accountability implications.
The evidentiary claim is intentionally narrow.
Not what the system believed.
Not what the system perceived.
But what the system reported observing at the boundary moment.
This distinction preserves the forensic value of the deposit while avoiding evidentiary overclaim.
After a physical AI incident, post-event analysis typically addresses what the robot did. It rarely independently preserves what the robot reported at the moment of the event. The missing evidentiary layer includes:
- -- what the robot reported observing in its sensor environment at crossing-time
- -- what state the system reported itself to be in
- -- what obstacles or humans the system reported detecting
- -- what safety conditions were declared active or inactive
- -- what contextual assumptions the deployment environment declared as active
Internal telemetry logs can be edited, overwritten, or selectively preserved. An independent evidentiary deposit created at the moment of the event - external to the manufacturer's systems - cannot be retroactively altered without invalidating the chain of custody.
After a physical AI incident, multiple parties have legitimate but potentially divergent interests in how the event is reconstructed. The manufacturer has an interest in demonstrating the system functioned as designed. The deployment operator has an interest in demonstrating that safety protocols were followed. The insurer has an interest in establishing whether liability falls within or outside the covered scope.
None of these interests is illegitimate. But when the evidentiary record is held exclusively by one of these parties - typically the manufacturer, through internal telemetry - the independence of that record cannot be assumed by the others.
Independence is not neutrality of content. The deposit records what the system reported - which may favor one interpretation or another. Independence means that record cannot be retroactively altered, selectively preserved, or reconstructed after the fact by any party with an interest in the outcome.
Section 7
7. What EVIDE Records
Using MCP integration, a physical AI system can submit a certified evidentiary deposit at critical moments - before, during, or at the boundary of a high-stakes event. The deposit is external, independently timestamped via RFC 3161, and not controlled by the robot manufacturer.
perimeter_violation_detected
unexpected_human_entry
obstacle_in_safety_zone
motion_continuity_active
emergency_stop_triggered
declared_sensor_conflict_event
declared_uncertainty_condition
pre_impact_state
visibility_partial
safety_zone_breach
operator_override_active
environment_classification
Note on signal labels. Signal labels shown above are illustrative examples of what a submitting system might report. EVIDE does not determine whether a perimeter violation occurred or whether any specific safety condition was breached. It records what the submitting system reported observing at the moment of deposit.
The goal is not to determine liability. The goal is to preserve reconstructability - independently, at the moment it matters, before any post-event interpretation has occurred.
EVIDE anchors the declared application event, never the internal state of the system that produced it. Every signal listed above is a condition the submitting system declares - not a value EVIDE reads from the system's internal sensor fusion, confidence scoring, or model reasoning. EVIDE does not compute confidence, does not interpret sensor disagreement, and does not access the robot's internal perception pipeline. It anchors what the system declared, at the moment it declared it.
Section 8
8. How It Works: Physical AI + MCP + EVIDE
Observation is continuous. Evidence is not. Only a small fraction of what a physical AI system perceives ever becomes a declared boundary event - and only declared events are what EVIDE anchors.
Sensors → Perception → Onboard AI → Mission Logic → Declared Boundary Event ──── Evidentiary Boundary ──── EVIDE
Not events: routine patrol, an authorized person passing by, expected environmental variation
Events: perimeter breach, unexpected human entry in the motion zone, a triggered safety condition, a reported sensor conflict
The evidentiary boundary sits at the declared event - never inside the perception, planning, or mission-control layer. EVIDE does not certify what the sensors recorded. It certifies that the application declared a specific event, with specific attributes, at a specific moment.
Via the EVIDE MCP Server, any physical AI system with an agentic layer can connect to the EVIDE evidentiary infrastructure. The integration requires a DAPI-verified owner identity and an active EVIDE subscription - the robot itself does not hold the accountability; its human or organizational owner does.
1
Event detection
The robot's onboard system detects a boundary condition - perimeter breach, unexpected entry, confidence degradation, pre-impact proximity.
2
MCP escalation call
The agent layer calls evide_escalate via the EVIDE MCP Server, submitting the current sensor state, safety context, visibility conditions, and active execution state.
escalation_trigger: "governance_uncertainty"
agent_state_summary: "Unexpected human entry detected within active motion zone. Perimeter boundary condition at crossing-time."
unresolved_signals: ["human_proximity_detected", "motion_continuity_active"]
visibility_surface: "partial"
observer_state: "degraded"
3
Independent crystallization
EVIDE receives the deposit, applies RFC 3161 timestamping, computes the evidentiary profile including FCC continuity assessment, and returns a tamper-evident record with evide_id and intake_hash.
4
Persistent evidentiary anchor
The record survives independently of the robot's internal logs, the manufacturer's systems, and any subsequent software update or incident investigation. It is verifiable by any third party against the EVIDE public registry.
Non-blocking architecture. Physical AI safety systems operate on real-time control cycles measured in milliseconds. The evide_escalate call is designed to operate asynchronously - the robot writes the state observation to a local protected buffer and the MCP agent transmits the package for crystallization in parallel, without blocking or interfering with the physical execution cycle or any safety-critical function.
IP protection by architecture. EVIDE does not receive raw telemetry feeds, proprietary sensor data, model weights, or video streams. It receives declared state observations - abstract descriptions of what the system reported at a specific moment. Cryptographic hashing ensures the evidentiary integrity of the record without exposing the manufacturer's internal systems or intellectual property.
Key evidentiary questions. When a declared boundary event is later disputed, can these questions be answered independently - without relying solely on the manufacturer's own systems or engineers?
- 1Could an independent third party reconstruct why the system's boundary state was declared at that specific moment?
- 2Which sensor inputs, internal state, or contextual signals actually informed that declaration?
- 3If the system's plan changed during execution, does independent evidence survive explaining why?
- 4Where is the evidentiary boundary between the perception/planning layer and the physical execution layer?
- 5If the system recognized an uncertain or out-of-distribution situation, what independent evidence documents that transition?
- 6Months later, could an external investigator reconstruct the sequence without relying solely on the manufacturer's own systems or engineers?
The anchored record. This is what step 4 produces - a real, API-conformant example, verified against the EVIDE intake schema v2.1.
Example evidentiary record for a declared physical-AI boundary event
{
"evide_schema": "2.1",
"source_system": "HumanoidServiceFleet-EU",
"source_reference": "EVT-2026-0714-1620",
"source_timestamp_utc": "2026-07-14T16:20:33Z",
"decision": {
"type": "declared_boundary_event",
"status": "finalized",
"closure_timestamp_utc": "2026-07-14T16:20:41Z",
"summary": "Declared perimeter boundary event crystallized following unexpected human entry within active motion zone"
},
"authority": {
"id": "fleet_owner_operator_12",
"role": "DAPI-Verified Deployment Owner",
"dapi_number": "DAPI-XXXX",
"verification": "DAPI-XXXX"
},
"system_report": {
"reported_signals": ["perimeter_violation_detected", "unexpected_human_entry", "motion_continuity_active"],
"declared_state": "pre_impact_state",
"visibility_surface": "partial",
"observer_state": "degraded"
},
"intervention": {
"type": "declared_event",
"classification_status": "stable",
"classification_context": {
"taxonomy_reference": "https://example.org/taxonomies/physical-ai-boundary-taxonomy-v1.0",
"threshold_reference": "https://example.org/protocols/perimeter-safety-protocol-v2.0",
"threshold_status": "met"
},
"rationale": "System reported a perimeter boundary condition; evidentiary deposit crystallized at crossing-time, prior to any post-event interpretation",
"trace": {
"reference": "PHYSICAL-AI-003/boundary-event-20260714-1620",
"access": "restricted"
}
},
"human_oversight": {
"is_declared": true,
"declared_level": "L1"
},
"handoff": {
"boundary_readiness": {
"status": "candidate",
"readiness_gate": null,
"visibility_surface": "partial",
"unresolved_signals": ["motion_continuity_active"]
},
"reconstruction_independence": "declared",
"submission_status": "not_submitted",
"acceptance_status": "not_claimed"
},
"extensions": ["evidence_references"],
"evidence_references": [
{
"artifact_type": "sensor_log",
"pointer": "fleet-storage://humanoid-fleet-eu/sensor-log-20260714-1620.json",
"declared_origin": "onboard sensor logging system",
"declared_description": "Perimeter and proximity sensor log at the time of the declared boundary event",
"hash": {
"algorithm": "SHA-256",
"value": "sha256:e219a4...b850_example_not_for_submission"
},
"hash_scope": "full_file",
"hashed_by": "Onboard logging service"
},
{
"artifact_type": "video",
"pointer": "fleet-storage://humanoid-fleet-eu/video-20260714-1620.mp4",
"declared_origin": "onboard camera recording",
"declared_description": "Video recording covering the moments before and after the declared boundary event"
}
],
"content_hash": {
"algorithm": "SHA-256",
"value": "sha256:8b3e...c904_example_not_for_submission"
}
}
Section 9
9. System Categories
EVIDE for Physical AI is not limited to humanoid robots. The evidentiary layer applies to any autonomous physical system that makes decisions affecting human safety or organizational accountability.
🤖
Humanoid robots
Public demonstrations, event performance, hospitality, retail interaction. High exposure to uncontrolled crowd environments.
🦾
Cobots and industrial robots
Collaborative workspace environments where human-robot proximity is by design. Safety zone management is a continuous governance condition.
🚗
Autonomous ground vehicles - AGV / AMR
Logistics, last-mile delivery, warehouse automation. Incidents in shared spaces with pedestrian traffic.
🚁
Drones and aerial systems
Urban air mobility, inspection, delivery. Proximity incidents with infrastructure or people in uncontrolled airspace.
🏥
Medical and surgical robots
High-stakes decision boundaries where the evidentiary record of what the system reported observing is critical for regulatory review and liability determination.
⚡
Critical infrastructure systems
AI-enabled inspection, maintenance, utility operations and autonomous infrastructure environments - where an evidentiary gap surfaces during regulatory review or after a service disruption, not during routine operation.
Any autonomous physical system.
One evidentiary accountability boundary.
evide_escalate - crystallize a physical boundary state
independently preserved, owner-attributed, tamper-evident.
"What did the robot do?" is one question.
"What did the robot report observing when it did it?" is another.
They require different infrastructure. EVIDE provides the second layer.
