The outcome you are walking toward
A working command of the contract every edge location is designed to run under when the uplink to the global control plane drops: what must keep working, what may degrade gracefully, what is forbidden while disconnected, and how the location reconciles its history with the global plane when connectivity returns — stated precisely enough to diligence.
One honesty note before the contract itself. This guide describes the designed behavior of the Edge Runtime and the conformance gates around it. Where a capability is staged rather than generally shipped, the wording says "designed to" — and the admission mechanism (conformance evidence, covered near the end) is what turns a designed contract into an enforceable one.
Why an offline contract exists
The Edge Runtime exists so that a location remains coherent, safe, and useful even when the global control plane is unreachable. The design goals are non-negotiable requirements, not aspirations:
- Critical loops must survive total cloud loss — access control, safety signaling, core POS/ticket flow, local form feedback, and local policy enforcement cannot stop because the uplink is down.
- No silent data loss — every event generated at the edge must eventually be reconcilable, either in order or with explicit gap detection.
- Policy remains enforceable offline — the edge carries a signed, versioned subset of policy and cannot be tricked into weaker behavior while disconnected.
- Agents can still act within strict local authority — critical agents, or reduced versions of them, execute only approved local actions.
- Security posture does not degrade — device identity, attestation, encryption, and least-privilege remain intact offline.
- Reconciliation is deterministic and auditable — when connectivity returns, the system is designed to converge to a known-good state with full evidence.
- Resource isolation is mandatory — vision inference, agent runtimes, commerce, and the device fabric cannot starve each other.
The architecture that carries the contract
Each edge node pairs a hardware trust anchor (secure boot, a hardware security module, a measured runtime) with an Edge Runtime kernel that enforces process isolation, resource governors for CPU, accelerator, memory, and network, a local identity and attestation service, and a secure update and rollback manager. On top of that kernel sit the local components the offline contract depends on:
- Local Mesh agent — continuous discovery and health of every device on the location fabric; maintains local topology even when the global Mesh is unreachable; reports device identity, firmware, attestation status, and resource health.
- Local Synapse (priority event bus) — full local publish/subscribe with priority lanes (Critical / High / Normal / Bulk), guaranteed local delivery for critical events, and effectively-once semantics within the location via idempotency keys and digests — with explicit gap detection rather than silent loss.
- Local policy engine — carries a signed, versioned policy snapshot, evaluates every local action against it, and cannot be rewritten while offline except by a newer signed package that passes attestation. Emergency local overrides exist only through pre-authorized, audited break-glass procedures.
- Local agent runtime — executes approved agent packages, including reduced "edge" variants, under hard resource quotas per agent. All agent actions emit reconstructable evidence locally before any side-effect.
- Event store and state store — an append-only event log with cryptographic chaining, versioned state with clear ownership and conflict rules, and explicit gap detection rather than silent loss.
- Evidence and digest store — immutable, encrypted-at-rest storage of policy decisions, agent actions, device attestations, and critical event digests, with retention governed by policy packs.
A multi-path, priority-aware uplink manager sits between the location and the global plane; the rest of this guide is about what happens when it has nothing to carry.
The offline behavior contract
This is the section to read line by line. It is the commitment the architecture above is designed to keep.
What MUST continue while offline
- Access control decisions against cached credentials and local policy
- Critical safety signaling and local alerting
- Core POS / ticket / order capture and local display (KDS)
- Local form / activity inference and member-facing feedback (Helix)
- Local inventory reservation where configured
- Emission of all events into the local durable log
- Local agent execution within pre-approved authority envelopes
What MAY degrade gracefully
- Global optimization and cross-location intelligence
- Non-critical reporting and analytics
- Heavy model updates
- Non-essential agent features that require global context
What is FORBIDDEN while offline
- Weakening of policy
- Expansion of agent authority
- Deletion of evidence
- Acceptance of unauthenticated devices into the Mesh
- Any action that would violate the last known signed policy snapshot
Note
The FORBIDDEN list is where an offline posture is proven. Many systems can keep taking orders while disconnected; the diligence question is what they refuse to do. Here, disconnection never widens authority, weakens policy, or thins the evidence record.
Buffering rules: what every event carries
Buffering is the mechanism behind "no silent data loss":
- Critical events: never dropped. The oldest non-critical events may be shed under extreme pressure — and only with explicit gap records, so the loss is visible rather than silent.
- Every buffered event carries a stable event ID, a timestamp (device and edge), the producer identity, a schema version, a content digest, and the policy revision that governed it.
That last field matters in review: every event can be evaluated later against the exact policy that was in force when it happened.
The reconciliation protocol, step by step
When connectivity is restored, the edge and the global plane are designed to converge through seven ordered steps:
- Edge presents its event log head and attestation
- Global plane and edge agree on common ancestor
- Edge streams events in order with digests
- Global plane validates, deduplicates, and acknowledges
- Any gaps are explicitly recorded as reconciliation cases
- State convergence is performed according to defined rules
- Full evidence of the reconciliation is retained
No "best effort" merge that loses causality. Gaps become named reconciliation cases with evidence attached — they are never smoothed over.
Security and attestation while disconnected
Offline operation does not relax the security posture:
- Measured boot and runtime attestation, with device identity anchored in hardware.
- Short-lived workload credentials issued only after successful attestation.
- All policy packages and agent packages are signed and verified before execution.
- Secrets never leave the secure element in plaintext.
- Local break-glass requires dual control and is fully audited.
Resource governance
The Edge Runtime enforces hard isolation between workloads: vision inference cannot starve the event bus or access control; agent runtimes run under CPU, memory, and accelerator quotas; commerce and safety lanes hold preemptive priority; bulk and telemetry traffic is lowest priority and first to be shed. The governors themselves are policy-controlled and observable.
Updates and rollback
All updates — runtime, policy, agent packages, models — are staged, cryptographically signed, and canaried on the edge before full activation, with instant rollback to the last known good. Offline edges receive updates when they next connect; they never run unsigned code.
Failure modes and recovery
The designed behavior under each named failure:
| Failure | Behavior | Recovery |
|------------------------|------------------------------------------------------|---------------------------------------|
| Uplink loss | Continue under offline contract | Automatic reconciliation on restore |
| Primary Edge failure | Failover to hot standby if present | Manual or automatic promotion |
| Policy snapshot expiry | Fall back to last valid; alert aggressively | New signed snapshot required |
| Storage pressure | Shed bulk first; never critical evidence | Alert + expansion or purge under policy |
| Attestation failure | Device quarantined from Mesh | Re-provisioning required |
| Agent runtime crash | Restart under supervisor; evidence of crash retained | Automatic with circuit breaker |How the contract is enforced: conformance
Any device or software claiming Edge Runtime compatibility must pass offline continuity tests, event integrity and replay tests, policy enforcement tests while disconnected, resource isolation tests, attestation and secure update tests, reconciliation correctness tests, and the vertical-specific critical loop tests. No device is admitted to the production Mesh without conformance evidence. That gate — not the prose on this page — is what counsel should ask to see.
What changes per vertical
- Helix (FIT): 24/7 access + form feedback must survive prolonged outages.
- Ember (REST): Ticket flow, KDS, and payment capture are sacred offline.
- Scaffold (BUILD): Harsh environments demand higher physical resilience and store-and-forward for safety observations.
- Domain (REALTY): Access control and safety signaling are the highest priority offline loops.
What to verify in a review
Three asks turn this contract from a document into diligence: reconstruct one reconciliation case from a real or drilled outage (step 5's gap record is the artifact to ask for); read one buffered event and confirm it carries the policy revision that governed it; and request the conformance evidence for the device classes in your deployment. The audit trail & evidence model covers how evidence is captured at the moment of action, and the diligence resources page is where briefing requests and follow-up materials live.
Adjacent reading: the agent authority model is the other half of what the edge enforces — agents act inside pre-approved envelopes even while disconnected — and the conformance levels are the gate this contract feeds. The MCV.STORE kits are the hardware this runtime ships on, and Business-In-A-Box is how it all arrives as one stack.
