Spherity Research · Paper overview and full PDF
Governed Memory for Physical AI
Evidence Roles, Integrity and Revocation from Experience to Action
Browse this paper
In brief
What does this research establish?
Robot memory can change physical actions without changing model weights. This paper proposes Memory Supply Chain Security: link experience, assessments and scoped authority to the actual memory view, receiving robot configuration and final operation gate. Conditional proofs and a finite protocol study support the admission and withdrawal logic; physical reliability, interoperability and deployment performance remain to be evaluated.
Key takeaways
- Assure the combination of robot, software, skill, AI model, memory, task and operating conditions—not a memory file in isolation.
- Retain useful failed experience under claim-specific roles; recognised copies and additional signatures do not create independent physical observations.
- Separate evidence provenance, permission to reuse and permission to execute; protect the representation and retained state actually consumed.
- Withdraw affected reliance through current context and unused permits, while accounting separately for already committed effects and physical recovery.
- Use existing validation where an assessed memory-update contract covers the new use; require targeted or broader revalidation for uncovered changes.
Read the full research paper
Governed Memory for Physical AI: Evidence Roles, Integrity and Revocation from Experience to Action — Dr. Carsten Stöcker, Spherity GmbH. Prepared 20 October 2026. 48 pages, open access under CC BY 4.0.
This page is a research overview, not the full manuscript. The PDF contains the formal model, assumptions, finite-study results, prospective evaluation and proposed credential profiles.
Abstract: why governed memory matters for Physical AI
A robot can change its next action by retrieving an earlier experience without retraining its model. Memory therefore belongs inside the control and assurance boundary. This paper proposes Memory Supply Chain Security: preserve the distinction between what was recorded, what is claimed, what evidence supports that claim, who may reuse it and who may execute an action. A Memory Bill of Materials traces the experience and its transformations; a Robot Bill of Materials identifies the receiving configuration. An access-controlled, verifiable evidence graph connects both to scoped authority, current assessments and operation-specific permits.
The industrial opportunity is controlled reuse of experience across robots and companies: retain useful failures, assess transfer between configurations, and restrict reliance when a calibration, claim or authority changes. These are proposed benefits to test, not measured gains in productivity or robot reliability. The paper provides conditional proofs and a bounded executable protocol study; robot-level behavioural evaluation remains prospective.
Keywords: governed robot memory; Physical AI; Memory Supply Chain Security; Memory Bill of Materials; Robot BOM; verifiable evidence graphs; European Business Wallet; runtime assurance.
A grasping example: preserve experience, govern its use
A robot tries to grasp a container. Its completion classifier reports success, but the object slips. The recorded episode may still contain an informative force trace and a successful approach segment. Treating the entire episode as either “trusted” or “untrusted” loses those distinctions.
- Withdraw the incorrect completion claim. It no longer supports a whole-task demonstration.
- Assess the force interpretation separately. It may support diagnosis or a counterexample, subject to the sensor, acquisition and calibration evidence.
- Assess the approach segment for its own role. A valid segment-level demonstration requires its own scope; the failed task does not supply that approval automatically.
- Check the receiving configuration. Experience from a parallel gripper does not automatically justify grasp-force advice for a suction tool. Geometric observations may remain useful if an assessment supports that transfer.
Figure 1 shows why claim-specific withdrawal can preserve useful evidence. Copying this episode to twenty robots improves availability, but creates neither twenty observations nor independent confirmation. Nor does a role label prove that a neural policy will interpret a counterexample as intended. Those behavioural effects require testing. [Paper §§3.1–3.3, 4.5.]
The memory supply chain: from capture to consequential action
A memory supply chain is the path through which an experience is captured, transformed, assessed, distributed and allowed to influence a receiving robot. It includes sensor traces and calibration, segmentation and labels, embeddings and summaries, model and software dependencies, assessment methods, issuer authority and current status. Protecting the downloaded file is only one part of protecting that path.
| Record | What it identifies | Why it matters |
|---|---|---|
| Memory Bill of Materials (MBOM) | Episode origins, capture conditions, processing artifacts, model/encoder versions, assessments and authority dependencies | Makes the sources and selected premises of a memory use inspectable |
| Robot Bill of Materials (Robot BOM) | Installed robot and tooling, software platform, base and task skills, AI artifacts, interfaces and memory harness | Establishes which receiving configuration the evidence must cover |
| Selected support witness | The actual evidence and authority paths accepted for a specific decision | Makes a later withdrawal or change traceable to the uses that relied on it |
Here, MBOM is a proposed memory-specific profile, not an established interoperability standard and not the manufacturing BOM meaning of the same acronym. A Robot BOM is likewise a proposed configuration graph. SBOM, AI/ML inventories and robot-description files can contribute information; none alone establishes the complete assurance case.
The assessed unit is the robot–software–skill–model–memory combination in a defined task and operating envelope. Individually approved parts do not establish that their combination is covered. The receiver must also check the actual context assembled from multiple memories, since individually eligible memories can form an unsupported combination.
This matters when a shared calibration fault, poisoned label or withdrawn assessment affects many consumers. The graph supports dependency-aware restriction and impact analysis instead of treating all distributed copies as equally reliable or deleting every later observation. Authentic but misleading content remains possible: a valid signature proves neither measurement truth nor assessor independence. Commercially sensitive traces and metadata also require purpose limitation, access control and retention rules. [Paper §§3.4–3.6, Appendix C.]
Evidence roles, integrity and revocation from experience to action
The architecture separates five decisions that often become conflated in a single “trusted memory” flag:
| Decision | Meaning | Separate obligation |
|---|---|---|
| Capture | An identified service records an episode and its conditions | Establish measurement quality and the sensor-to-record binding |
| Assessment | An authorised assessor evaluates an identified claim using a method and evidence | Check competence, applicability, uncertainty and relevant common causes |
| Reuse permission | A receiver may consume a particular view for a defined role and task | Verify current scope, configuration and context-composition coverage |
| Representation integrity | The consumed view and retained state match the protected decision | Cover buffers, accelerator or remote state where these affect the claim |
| Execution permission | One exact operation satisfies current mandate and assurance conditions | Enforce at the last reversible command boundary |
Legal-person identity and the European Business Wallet
Cross-company evidence needs an accountable issuer and a recognised basis for its authority. Legal-person identity answers which organisation stands behind an assertion; scoped credentials and delegation answer what that organisation, service or robot may do. A DID or signing key alone does not establish legal identity, competence or permission. A calibration provider, fleet operator, curator and third-party assessor have different responsibilities even when their credentials travel together.
The paper’s enterprise-wallet model can be related to the proposed European Business Wallet (EBW) framework, building on eIDAS 2.0, as a potential enterprise-side trust mechanism: organisational identity and appropriate attestations can support recognised issuer bindings and scoped mandates. Device-bound machine wallets complement that layer at the robot. As of this page’s review, EBW remains a legislative proposal; eIDAS 2.0 is adopted legislation. This is an architectural connection, not a claim that the paper implements an EBW robot profile or that wallet possession establishes legal compliance or physical safety. The legal framework and legislative procedure are linked in the references below.
An operator’s delegation may pass through an authorised fleet service to a named robot. Each child grant must narrow the permitted resources, reuse roles, task, configuration, validity and onward-delegation scope. A robot-specific membership and key binding is still required. Capture authority does not confer assessment authority; permission to consume a memory does not confer permission to execute a physical command.
The evidence graph must record the selected authority path, alongside the evidence path. Withdrawing a parent delegation, issuer authority or fleet membership can restrict dependent operational use without making every historical observation false. Routine expiry of a capture credential is different from a retrospective finding that its key or calibration was compromised. A valid alternative authority or evidence path requires a fresh decision; it does not silently repair an old permit. [Paper §§3.3, 4.1, 5.1–5.3; Appendix C.]
Protected memory lifecycle: two gates with different responsibilities
Figure 2 connects local capture and backend assessment to protected receiver services. New experience first enters a candidate store. Local assessment may proceed within a preauthorised scope; fleet distribution transports evidence and commitments without granting permission to the recipient.
- Receive and assess. Check the package, issuer authority, attenuating delegation, current status, evidence role and receiving configuration. Assess the proposed context before activation.
- Bind actual consumption. Install a verified view and protected state version with recorded dependencies. If selective invalidation cannot cover retained state, reconstruct the affected session from currently admissible inputs or restrict that path.
- Admit the exact operation. Check current mandate, physical assurance, dependencies, state, configuration, expiry and a single-use permit at the final gate.
The proposed credential profiles distinguish an EpisodicMemoryAttestation, a CalibrationAssertion and a RoleEndorsementCredential. These are research application schemas, not W3C-standardised memory vocabulary. They record evidence, not a universal safety certificate or a replacement for the operator’s delegation. [Paper §§4.2–4.3, Appendix C.3–C.4.]
Revocation reaches retained context; recovery remains a physical obligation
Deleting a memory from future retrieval does not remove its influence from a current model context, plan or command queue. Scoped withdrawal must reach affected representations, selected support, retained state and unused permits. Final verification and command commitment must be ordered together with local status installation, so a previously cached “allow” decision cannot bypass a newly installed restriction.
Figure 3 separates detection, adjudication, authoritative withdrawal, delivery, local installation and physical recovery. The paper derives a conditional bound on new stale-dependent admissions from delivery or enforced absolute expiry, clock disagreement and local enforcement delay. It is not a measured robot stopping time. Without bounded delivery or enforceable expiry, no finite cutoff follows.
Earlier committed effects require a separately justified continuation or recovery contract. For a robot holding a payload, recovery may require stabilisation rather than immediate loss of power. Unresolved operations remain recorded until supported completion or cancellation evidence arrives; a timeout alone does not establish cancellation. A recent status response also cannot make an old physical assessment applicable to a changed tool or environment. [Paper §§4.4, 5.5–5.6, 7.2; Appendix C.5.]
What the study shows—and what remains to be evaluated
The paper reports exhaustive reachable-state exploration of a bounded protocol abstraction, not a robot deployment. Its protected variant contains 3,192 states and 12,494 labelled transitions, with no violation among nine checked properties and 120 commit edges. The positive execution cases matter: the result is not obtained simply by disabling all action.
| Enforcement variant | Reported counterexample |
|---|---|
| Non-atomic admission | A cached decision commits after withdrawal; expiry and context checks can also become stale |
| Database-only restriction | Existing context and an old permit still commit after installed withdrawal |
| Reset on restart | Status rollback, lost unresolved work and repeated commitment |
| Untyped admission | An endorsement for one role grants another role |
The finite model does not test a complete delegation implementation, robot-configuration matching, arbitrary fleet size, cryptography, hardware isolation or physical motion. Behavioural benefits, latency, availability cost and resistance to authorised poisoning remain evaluation questions. The paper describes supplementary code and schemas; downloads of that executable supplement are not included on this page.
During each assessment interval, the formal scope assumes an identified, stable robot/skill/model baseline within declared tolerances. Memory-conditioned behaviour can change, but online weight learning and unmodelled drift are outside that interval. A configuration change or adverse finding requires reassessment. Proposed trials compare frozen memory, controlled memory additions and a limited heterogeneous fleet while holding safety-controller and evaluation budgets consistent. [Paper §§5–8.]
Guideline recommendation: approve an assessed use, not a memory in isolation
The paper recommends developing an engineering guideline for controlled memory use in Physical AI. Its six requirements provide a practical agenda for robot manufacturers, fleet operators, assessors and identity-infrastructure teams:
- Trace configuration and evidence. Maintain linked Robot BOM and MBOM records, including calibration, uncertainties and missing dependencies.
- Grant claim-specific permissions. Separate observation, assessment, reuse role and execution authority. Preserve useful failures and prevent recognised copies from inflating support.
- Revalidate proportionately. Record whether existing evidence covers the proposed memory, combined context and use. Apply targeted assessment or broader validation where coverage is missing; stage candidates before activation.
- Protect admission. Verify issuer authority, delegation, status and actual configuration. Bind the consumed view, retained state, selected support and exact operation while preserving a separate physical-assurance check.
- Specify withdrawal and recovery. Persist nonce consumption and pending-operation records before command release. Define inherited expiry, offline limits, restart reconciliation and continuation or recovery contracts.
- Make evaluation auditable. Retain reasons and change history, test rejection cases alongside valid use, and report availability costs. Distinguish model checks, implementation tests and physical experiments.
Start with one instrumented manipulation task: trace a grasping episode through capture, assessment, reuse and final dispatch, then test a wrong completion label, shared calibration fault, duplicate memory, withdrawn parent delegation and restart with pending work. Record which prior evidence can be reused and which change requires new assessment.
This is a research and implementation recommendation, not an adopted standard or certification scheme. The goal is to make memory-conditioned action inspectable, scope-bound and withdrawable while testing whether those controls deliver useful operational benefits. [Paper §9.1.]
Selected standards, research and identity references
The full PDF contains 49 references and the detailed contribution boundary. The following sources explain the main building blocks; naming a standard does not establish conformance of the proposed architecture.
- Stöcker, C. (2026). Governed Memory for Physical AI: Evidence Roles, Integrity and Revocation from Experience to Action. Spherity GmbH, 20 October 2026. CC BY 4.0.
- W3C. PROV-O: The PROV Ontology and Verifiable Credentials Data Model v2.0: attributable claims and provenance, distinct from truth and use permission.
- W3C. Bitstring Status List v1.0: credential-status representation. The paper’s ordering, expiry, delegation and receiver-enforcement rules are additional application obligations.
- OpenSSF. SLSA 1.2; in-toto. Specification; Sigstore. Security model: artifact provenance and workflow/signing controls, rather than physical-truth guarantees.
- OWASP CycloneDX. AI/ML Bill of Materials; SPDX. SPDX 3.0.1: supporting component inventories. Neither defines the paper’s proposed MBOM or Robot BOM.
- OpenID Foundation. OpenID for Verifiable Presentations 1.0; IETF. RATS Architecture, RFC 9334: credential presentation and appraisal of device-attestation evidence.
- European Union. Regulation (EU) 2024/1183: the adopted European Digital Identity Framework, commonly referred to as eIDAS 2.0. European Parliament, European Business Wallets legislative procedure 2025/0358(COD): proposal under negotiation, not an operational-safety approval.
For the related Spherity architecture, see the PACE, evidence-graph, EBW and runtime-revocation papers linked below.
Open research
License and citation
The content of this research overview, the linked paper and its three original figures is licensed by its named author under the Creative Commons Attribution 4.0 International License (CC BY 4.0). Reuse must credit every named author, link to this canonical version and the license, and indicate whether changes were made.
How to cite this work
Dr. Carsten Stöcker (2026-10-20). “Governed Memory for Physical AI: Evidence Roles, Integrity and Revocation from Experience to Action.” Spherity GmbH. https://spherity.github.io/spherity-research/governed-robot-memory-physical-ai.html. Licensed CC BY 4.0.
Direct answers
Questions this research answers
What is governed robot memory for Physical AI?
Governed robot memory is a proposed way to control how past experience influences a robot's next action. It separates captured episodes, claims, assessments, reuse permissions and execution permissions, then binds each decision to current evidence, authority and the receiving robot's assessed configuration. It is not a claim that stored memories are inherently safe.
Why does robot memory need a supply chain security framework?
Experience passes through sensors, calibration, processing, labels, embeddings, assessments and distribution before reaching an acting robot. A fault or misleading assertion at any stage can affect later behaviour even when model weights remain unchanged. The proposed memory supply chain records these dependencies and checks permitted use at the receiver and operation boundary.
What is the difference between a Memory BOM and a Robot BOM?
The proposed Memory Bill of Materials records an episode's sources, transformations, assessments and authority dependencies. The proposed Robot Bill of Materials records the receiving robot's installed hardware, software, skills, AI artifacts and memory harness. Their assessed combination determines applicability. These are research profiles, not established interoperable memory or robot standards; MBOM here does not mean a manufacturing bill of materials.
Can a robot learn from a failed grasp?
A failed grasp may preserve a useful force trace, counterexample or successful approach segment. Each use needs its own assessment and permitted role. An accepted counterexample does not authorise imitation of the whole failed action, and useful behavioural effects still require empirical testing.
How are legal-person identity and European Business Wallets relevant?
Recognised organisational identity can bind an issuer to an accountable legal entity, while scoped credentials and delegation specify what it may assert or authorise. A European Business Wallet is a potential enterprise-side mechanism within an applicable trust framework, complemented by device-bound machine wallets and protected local gates. Identity does not prove evidence truth, assessor competence or robot safety, and the paper does not demonstrate EBW robot interoperability.
Does revoking a memory cancel a robot's ongoing action?
Under the stated protected-enforcement assumptions, installed withdrawal blocks new affected admissions and invalidates stale dependent permits. Commands already committed require a separate continuation or recovery contract. Removing a database record alone cannot remove its influence from retained context, and a timeout does not prove cancellation.
Does every new robot memory require full revalidation?
Every operational reuse requires current verification and applicability checks. Existing behavioural evidence may cover a new memory under an assessed update contract, including context composition. Uncovered tooling, model, skill, memory-role or operating-envelope changes require impact assessment and, where needed, targeted tests or broader revalidation.
What did the finite protocol study establish?
The paper reports 3,192 states and 12,494 labelled transitions with no violation of nine checked properties in its protected abstraction. Weakened enforcement variants expose specific counterexamples. These are finite-model results, not robot experiments, production latency benchmarks, fleet-wide proofs or certification of a concrete implementation.