Protocols & Rails — Physical Autonomy
Physical Autonomy that stays authorised under change.
No Stamp → No Ship for robot actions that can hurt people, damage property, or breach boundaries.
Incidents don't judge your safety programme. They judge what you can prove was authorised at execution time — and whether reliance stopped when conditions changed.
- High-impact motion/force actions gated by Status Link — VALID or it does not run
- Counterparties verify by link without accounts (scope, expiry, signer, status)
- Every stamped action ships with an IDA Evidence Pack you can file and cite
- WITHDRAWN propagates stop-rely signals immediately (no chasing config drift)
Fail-closed•Append-only•Scope-bounded
Not a certification. Scope-limited verification. Acceptance depends on counterparty/programme requirements.
Why physical autonomy buyers are moving now
Drift risk, expanding deployment footprints, and post-incident scrutiny are converging.
Autonomy updates outpace approval cycles
Firmware, policy, and safety-envelope changes accumulate silently. Without execute-time verification, approvals go stale between reviews.
Shared spaces multiply boundary complexity
Mixed human-robot environments require proof of what was authorised at execution time — not what was approved last quarter.
Insurers and customers demand defensible records
Post-incident scrutiny asks what was valid at that moment. Static safety dossiers don't answer time-of-action questions.
Fleet-scale config changes widen blast radius
A single policy rollout can affect hundreds of units. Refresh/withdraw semantics contain the exposure before it propagates.
Post-incident reversals require immediate stop-rely
When a safety regression is discovered, reliance must stop immediately — not after a review meeting or change-control cycle.
Procurement requires portable, verifiable controls
Enterprise customers and integrators need contract-referenceable proof without accessing internal systems or signing NDAs.
Cyber and vendor incidents need fast containment
Compromised remote access, OTA supply chains, or third-party connector failures require instant revocation propagation.
Manual reconstruction burns safety and legal capacity
Rebuilding what was authorised at execution time from scattered logs, configs, and email chains is slow and error-prone.
Good Proof provides scope-limited verification evidence and stop-rely semantics. It is not a certification.
What a Stamp proves (and what it doesn't)
Proves (within lane scope)
- Action class + outcome marker
- Decision/execution timestamp
- Signer/authority reference
- Scope boundary + expiry + evidence window
- Validity state (VALID / NEEDS_REFRESH / WITHDRAWN / NOT_VERIFIED)
- Policy/version identifiers
Does not prove
- Functional safety certification
- Sensor truth completeness
- Algorithm/model correctness
- Legal/regulatory compliance certification
- Raw telemetry/log payloads by default
In incidents: Status Link = reliance state now. IDA Evidence Pack = fileable decision-time snapshot.
VALID means valid within scope, not a guarantee of outcome correctness.
Why this lane exists
This is an authority-and-timing problem, not just observability.
The key question in post-incident review: was this motion/force action permitted then, within scope, and should reliance continue now?
Good Proof converts meeting-checkable process trust into a contract-referenceable machine control.
Questions buyers, insurers, and auditors will ask:
- "Who approved this robot to operate in this zone with these parameters?
- "Was the safety envelope changed after the last safety sign-off?
- "Did the firmware version or policy change since last verification?
- "Can a partner verify this without logging into your systems?
- "If compromise is suspected, can we stop reliance instantly?
Capability surface (what gets verified before execution)
The Stamp covers a defined surface. Material changes trigger re-verification or revocation.
Robot/vehicle platform ID + firmware/autonomy stack version
Safety envelope parameters (speed, force, proximity limits)
Site/zone/map/geofence references
Tool/actuator permissions (grip, cut, lift, inject, dock, charge, etc.)
Authority/delegation object (including teleop handoff rules)
Evidence window + expiry + signer policy
Material surface change
→ NEEDS_REFRESH — re-verify before rely
Compromise / integrity failure
→ WITHDRAWN — stop-rely immediately
What gets stamped
High-impact physical autonomy actions gated by Status Link.
Motion & Navigation
- Autonomous navigation in shared human spaces (go / no-go)
- Force / speed / proximity limit changes (safety envelope edits)
- Safety-mode changes (including temporary overrides)
- Boundary crossing (new zone / site / map version)
Teleop & Authority
- Teleoperation sessions and authority handoffs
- Authority changes (override approvals, safety-mode edits)
- Fleet-wide policy deploy / rollback (mass change control)
Tool Use & Actuation
- Tool-use actions with physical consequence (pick, lift, cut, inject, clamp, dock, charge)
- Actuator permission changes with safety implications
Incident & Dispute
- Incident closure outcomes and dispute resolutions
- Safety sign-offs creating downstream liability
- High-liability exception approvals
Integration in 3 touchpoints
1
Issue
At action creation (zone entry, mode change, tool actuation) → require a Stamp for defined high-impact classes.
2
Communicate
Include Status Link in logs, partner handoffs, tickets, notices, and audit packets.
3
Rely
At motion/actuation/enforcement → verify Status Link (fail-closed = block or safe-stop).
High-impact gating only. Everything else runs normally.
Live status + fail-closed enforcement
If it's not VALID, the action does not execute.
VALID
Proceed within scope
NEEDS_REFRESH
Re-verify before rely
WITHDRAWN
Stop-rely immediately
NOT_VERIFIED
Fail-closed response
Fail-closed: unreachable verification returns NOT_VERIFIED.
Block or safe-stop, never assume validity.
VALID means valid within scope, not guaranteed correctness.
Status triggers
Operational definitions for when status changes.
NEEDS_REFRESH
Material change. Re-verify before reliance continues.
Firmware / autonomy stack version change
Safety envelope parameters changed (speed, force, proximity)
Map/site/geofence boundary changed
Tool attachments changed (gripper, cutter, injector, etc.)
Sensor suite change (calibration, replacement, new model)
Policy/approval threshold update
Delegation/authority object change
Operating environment materially changes (layout, hazards, human density)
Evidence window expired (time-based refresh)
Material case-context update affecting lane scope
NEEDS_REFRESH means "re-verify before you rely," not "schedule a meeting."
WITHDRAWN
Stop-rely signal. Execution must not proceed.
Suspected compromise (remote access, telemetry, command channel)
Safety regression discovered (test failure, field anomaly)
Unauthorized parameter edit or scope expansion detected
Tool malfunction creating unsafe actuation risk
Severe misconfiguration enabling out-of-scope actions
Incident command stop-rely declaration
Critical vulnerability disclosed affecting firmware/stack version
Legal/regulatory stop-work order or safety hold issued
Fail-closed: Wherever the Status Link is checked, if WITHDRAWN → block or safe-stop.
Runtime enforcement points
Before motion execution (controller / mission planner)
Before safety/mode changes (override, speed/force change)
Before teleop session start
Before tool actuation
Before boundary crossing (zone entry)
Before fleet-wide policy deployment
No VALID status, no execution. Block or safe-stop per programme policy.
How it works
1
Stamp the capability surface
Approve a defined scope: robot/firmware version, safety envelope, site/zone boundary, tool permissions, and operating limits.
2
Gate high-impact execution
Before execution, systems check the Status Link. If not VALID → block or safe-stop. This is No Stamp → No Ship.
3
Revoke fast when risk changes
If compromise is suspected or safety regression discovered, mark WITHDRAWN. Revocation propagates by Status Link wherever checked.
4
Expand lanes after proven reliance
Start with one action class. Expand when counterparties rely on the Status Link. Guardians handle exception lanes only.
Make the gate machine-checkable, not meeting-checkable.
Two artefacts, one standard
Status Link
Authoritative now
- Returns status, scope, expiry, verified_at, signer, verify_url
- Fail-closed when unreachable → NOT_VERIFIED
- Machine-checkable by any counterparty without login
- Revocation propagates wherever the link is checked
IDA Evidence Pack
Snapshot then
- Time-stamped, forwardable, citable
- Append-only history — withdrawal ≠ erasure
- Minimal disclosure by default
- Programme-gated access when required (auditable trail)
What counterparties can verify (without internal access)
No login. No portal. Just a link that fails closed.
Current validity state: VALID / NEEDS_REFRESH / WITHDRAWN / NOT_VERIFIED
Scope boundaries (capability + allowed action classes + site/zone)
Expiry + verified_at timestamp
Signer authority reference
Canonical verification route (+ optional signed response, programme-scoped)
Forwardable IDA Evidence Pack
Privacy-preserving by default (no raw telemetry/PII)
Minimal disclosure by default: prompts/logs/telemetry/PII excluded. Programme-gated access when required (auditable trail).
Global Coverage
Regulatory reality
No hype, no compliance claims — portable proof that survives cross-border review.
EU
Machinery Regulation + AI Act coordination; evidence that survives cross-border review.
UK
HSE robotics guidance + operational resilience expectations; defensible safety records.
US
OSHA workplace safety + NIST AI risk management framework alignment.
Canada
OHS frameworks + emerging autonomous systems governance guidance.
Australia
Safe Work Australia + model WHS laws for autonomous systems.
Asia
Industrial robot safety standards + emerging autonomous vehicle frameworks.
Middle East
Smart-city and autonomous mobility governance expanding; portable verification supports cross-entity reliance.
Africa
Industrial safety regulation strengthening across regional bodies; portable verification supports cross-border deployments.
Good Proof doesn't certify compliance. It makes execution decisions verifiable, refreshable, and withdrawable by link.
Not legal advice. Final legal mapping is owned by programme counsel.
Jurisdictional configuration
Programme-specific overlays for cross-border deployments.
Scope boundaries per jurisdiction
Evidence windows + retention periods
Redaction matrix + disclosure controls
Verifier checklist per deployment region
Language support + verifier access model
Appeal/dispute handling per local framework
Not legal advice. Final legal mapping is owned by programme counsel.
What's inside the IDA Evidence Pack
Decision-time snapshot for incidents, audits, and filing.
Action summary + lane scope boundary
Decision/execution timestamp + evidence window
Robot/firmware/safety-envelope identifier + version refs
Site/zone/map boundary references
Capability/policy identifiers
Signer/authority reference
Verification transcript + timestamps
Redaction matrix (what is intentionally excluded)
Proof ≠ payloads. Raw telemetry/logs/PII are not required by default. Programme-scoped access when required, with auditable access trails.
AI-Agent Era
AI-agent era controls
Autonomy stacks can drift. Reliance controls must not.
Material change in firmware/tool/vendor/configNEEDS_REFRESH
Integrity or safety boundary breachWITHDRAWN
Timeout/unreachable verification routeNOT_VERIFIED (fail-closed)
Exception lane requiring human finalityGuardian path (optional)
Good Proof does not decide outcomes; it controls whether high-impact actions are safe to rely on.
Who buys this in Physical Autonomy
Commercial buyers and external verifiers with high-impact action accountability.
Commercial buyers
EHS / Safety
Pain: Safety evidence scattered across configs, logs, and memory.
Outcome: Verifiable gate + instant revocation on anomaly.
Book a Stamp SprintAutonomy Engineering / Controls
Pain: Can't prove which firmware/policy version was active at execution time.
Outcome: Capability surface stamped with version refs and scope boundary.
Book a Stamp SprintFleet Operations
Pain: Fleet-wide changes create blast radius with no portable proof trail.
Outcome: Status Link answers 'was this valid?' for any action, any unit.
Book a Stamp SprintProduct Safety / Quality
Pain: Post-incident defensibility depends on reconstructing what was valid.
Outcome: Fileable Evidence Pack with decision-time record and scope boundary.
Book a Stamp SprintCIO / Security / Enterprise Architecture
Pain: Cyber and OTA supply-chain incidents need instant containment proof.
Outcome: WITHDRAWN propagates stop-rely wherever Status Link is checked.
Book a Stamp SprintLegal / Compliance / Audit
Pain: Evidence reconstruction for incidents and litigation is slow and brittle.
Outcome: Append-only verification history with IDA Evidence Pack for filing.
Book a Stamp SprintProcurement / Vendor Risk
Pain: Supplier safety assurances don't travel or update after contract signing.
Outcome: Contract-referenceable Status Link + procurement-ready clause template.
Book a Stamp SprintIntegrators / Partners
Pain: Multi-vendor deployments lack portable proof of boundary compliance.
Outcome: Counterparty-verifiable status across the integration stack.
Book a Stamp SprintExternal verifiers
Regulators / workplace safety authorities
Pain: Control testing depends on system-bound evidence and inconsistent logs.
Outcome: Verifier-checkable status with portable Evidence Pack for review.
Book a Stamp SprintInsurers underwriting autonomous deployments
Pain: Coverage decisions require defensible evidence of safety controls at execution time.
Outcome: Status-linked governance evidence with withdrawal propagation.
Book a Stamp SprintEnterprise customers with safety requirements
Pain: Supplier safety claims are static documents that expire silently.
Outcome: Live-status verification by link, no internal access needed.
Book a Stamp SprintWhere budget comes from
Usually funded from existing safety, risk, and procurement lines — not new category spend.
Safety governance budget
Trigger: Post-incident defensibility gap or insurer requirement
Why it fits: Portable verification + instant revocation reduces reconstruction effort.
Autonomy deployment assurance
Trigger: New site/fleet rollout or customer assurance requirement
Why it fits: Scope-bounded Status Link proves what's authorised at execution time.
Insurer / enterprise customer requirements
Trigger: Coverage renewal, partner onboarding, or contract negotiation
Why it fits: Contract-referenceable verification with live status and Evidence Pack.
Operational resilience / risk containment
Trigger: Fleet-scale config change or safety regression discovery
Why it fits: WITHDRAWN propagation contains blast radius without chasing configs.
Procurement and vendor assurance
Trigger: Supplier evaluation, integration qualification, or audit preparation
Why it fits: Counterparty verification by link without system access or NDA.
Post-incident cost containment
Trigger: Investigation, litigation, or regulatory inquiry
Why it fits: Fileable Evidence Pack reduces evidence reconstruction and legal exposure.
Cyber / OTA supply-chain resilience
Trigger: Remote access incident, OTA compromise, or vendor dependency failure
Why it fits: Instant WITHDRAWN propagation with fail-closed enforcement at gate points.
Start with one high-impact lane and prove incident defensibility before expansion.
24-month horizon
Future pressure radar
Conservative signals shaping buyer expectations in the next 24 months.
Greater autonomy density in mixed environments
More robots in more spaces with higher interaction density. Proof-of-authorization demands scale with deployment footprint.
Faster OTA/policy cycles increasing drift exposure
Continuous deployment patterns mean approvals go stale faster. Change-control evidence must keep pace.
Tighter external verification expectations in contracts
Enterprise customers and insurers increasingly require machine-checkable proof, not static safety dossiers.
Higher third-party concentration and supply-chain scrutiny
Dependency on shared OTA providers, cloud connectors, and sensor vendors creates correlated failure risk.
Stronger revocation/stop-rely expectations
Contracts will demand faster propagation of stop-rely signals when conditions change or compromise is detected.
Rising cross-party demand for portable proof
Integrators, regulators, and insurers expect verification without portal access, NDAs, or system-level credentials.
Procurement-ready clause
Template language for your legal team.
"For defined high-impact physical autonomy actions, Provider shall maintain a Good Proof Stamp with an active Status Link. Actions attempted with NOT_VERIFIED, NEEDS_REFRESH, or WITHDRAWN shall be treated as unverified and must block or safe-stop per programme policy."
Schedule A (template — programme terms)
Definitions + operating rules procurement teams can adapt.
1. Definitions
- High-Impact Action Class: the defined action lane (e.g., zone entry, safety-mode override, tool actuation) requiring verification.
- Status Link: the verification endpoint returning validity state + scope boundaries.
- Scope Boundary: the robot/firmware/safety envelope/zone configuration covered by the Stamp.
- Evidence Window: the programme-defined period and inputs considered for decision-time verification.
- Evidence Pack: the fileable, programme-configured snapshot for disputes/audit/procurement (IDA format).
2. Required states
- VALID→ may proceed within scope.
- NEEDS_REFRESH/ NOT_VERIFIED / WITHDRAWN → must block or safe-stop per lane rules.
- Fail-closed:timeout/unreachable ⇒ NOT_VERIFIED ⇒ safe-stop.
3. Withdrawal / stop-rely semantics
- WITHDRAWN is returned wherever the Status Link is checked.
- Safe-stop behavior per programme policy (immediate halt, controlled stop, escalation).
4. Anti-spoof controls
- verify_url host MUST exactly match official_verifier.
- HTTPS/TLS required; no insecure overrides.
- Redirects strictly forbidden.
5. SLA placeholders
Verifier availability target: [___]%. p99 verify latency: [___] ms. Pack export window: [___] hours. Withdraw propagation: [___] seconds.
6. Retention + privacy/redaction defaults
- Evidence Pack excludes raw telemetry, logs, and PII by default.
- Buyer controls data retention periods per programme requirements.
- Programme-gated access for sensitive fields with auditable access trail.
7. Emergency override governance
- Safety-first override paths are programme-defined.
- Mandatory post-action Stamp reconciliation with append-only override trail.
- Override is harm-reduction, not control-bypass.
Not legal advice. Template language for your legal team.
Not a certification. Scope-limited verification. Acceptance depends on counterparty/programme requirements.
OUR MOAT
We Care Defensibly
A Global Human Layer
Our Mind Chill Guardian Story
A global human layer that software can't fake.
When liability lands on a person, the sign-off should too.
Conflict-checked · Rotation-based · Audit-traceable · Programme-scoped
When Guardians are used (only when required)
Most decisions remain automated. Humans step in only where human finality is required: exception approvals, post-incident outcomes, disputes, and high-risk overrides where liability lands on people. Minimal disclosure by default. Not required in normal hot path unless programme requires.
From calming minds to defending outcomes
Mind Chill began in 2017 as immersive art built to reduce anxiety and create calm at scale. Then the same feeds that buried calm and rewarded outrage started training the systems that now make real decisions. We didn't want more rhetoric. We wanted receipts.
The moment it clicked
A message arrived: someone's child felt safer because of what they experienced. Around the same time, lived experience inside our own community made one thing obvious: the nuance that matters in high-impact decisions can't be reliably reduced to a prompt. So we designed a human layer for the edge cases—structured, scope-bound, and auditable.
Guardians are not a "panel." They're a network.
Mind Chill Guardians come from different countries, backgrounds, and lived realities. That diversity is not branding—it's risk reduction. It makes decisions harder to game, easier to challenge, and more credible under scrutiny. Guardians do not "run the system." They review only what the lane requires humans to own.
Receipts over rhetoric
Operational Guardians plug into Good Proof lanes as a controlled finality mechanism: conflict checks, rotation, multi-review where required, and an audit trace tied to a Status Link. Minimal disclosure by default. If a decision is appealed months later, you can show what happened, within scope, without dumping sensitive payloads.
Why buyers choose Guardians
Lived experience at the edge cases
Conflict-checked + rotation-based
Multi-review on high-risk lanes
Audit-traceable outcomes
Minimal disclosure by default
30-day Physical Autonomy Stamp Sprint outcome
One action class, production-ready.
One high-impact action class defined (e.g., zone entry or safety-mode override)
Capability surface documented (robot + firmware + safety envelope + site boundary)
Pre-execution gate integrated (Status Link check)
Refresh and withdrawal triggers configured
Counterparty verification route tested end-to-end
One redacted IDA Evidence Pack specimen generated
Go/no-go expansion recommendation
Due Diligence FAQs
Make physical autonomy shippable.
Start with one high-impact action class. Gate it end-to-end. Expand when counterparties rely on the Status Link.
Not a certification. Scope-limited verification. Acceptance depends on counterparty/programme requirements.