# Memory Needs Governance

**Octeryx OS / Foundation Guide 02**

Persistent context only becomes dependable when identity, authority, time, policy and human responsibility travel with it.

Foundation Edition 0.1 / July 2026 / 15 minute read

- [Canonical web edition](https://www.octeryx.com/guides/memory-needs-governance/)
- [PDF edition](https://www.octeryx.com/guides/octeryx-memory-needs-governance-foundation-guide.pdf)
- [Current proof boundary](https://www.octeryx.com/proof-boundary.md)

> This Markdown edition is generated from the canonical web guide. Edit the web guide, then rebuild the portable artifacts.

## Stored is not the same as governed.

*01 / Opening argument*

**A memory can persist perfectly and still be unsafe, misleading or inappropriate to use.**

Once an autonomous system can carry context forward, a second problem appears. What exactly has been remembered? Who or what does it refer to? Which source supplied it? Is that source authoritative for this fact? Is the context still current? Who may see it, for what purpose, and who remains responsible for deciding what happens next?

Storage answers none of those questions. A database can preserve a claim long after its usefulness has expired. A model can compress contradictory observations into a confident summary. An application can copy information into a workflow without carrying forward the conditions under which it was collected.

Governed memory keeps the qualifying context attached. Identity, source, time, confidence, policy, purpose, correction and human review are part of the memory rather than optional metadata around it.

> A memory becomes dependable when the system can show what it knows, why it may rely on it and where human authority begins.

## Context is unsafe before identity is resolved.

*02 / Identity*

**A useful observation attached to the wrong person, device, place or episode becomes confidently wrong context.**

Physical environments contain overlapping identifiers. A resident may be represented by a room label, a local application record, a wearable, a voice profile, a family reference or a temporary hospital identifier. Devices and robots maintain their own local identities. Places change purpose. People move.

A resident graph is intended to connect these references without pretending that every match is certain. Resolution should preserve candidates, confidence, source evidence, corrections and the distinction between an account, an actor, a person and the subject of context.

When ambiguity remains material, the safe result is not a convenient guess. The system should constrain disclosure and action, request clarification or route the case for human review.

| Question | Local record | Governed identity context |
| --- | --- | --- |
| Reference | One system identifier | Opaque subject reference with source mappings |
| Ambiguity | Often hidden by a selected match | Candidates, confidence and review remain visible |
| Change | Current value overwrites the old one | Merge, split and correction lineage are retained |
| Authority | Possession implies use | Purpose and policy still determine access and action |

## Authority belongs to claims, not systems.

*03 / Source trust*

**A source may be reliable for one kind of fact and inappropriate for another.**

A sensor may be authoritative for its own reading but not for the identity of the person nearby. A care application may hold an approved plan but not the most recent observation. A family member may provide valuable context without becoming the authority for a clinical fact. A model may contribute an inference without owning truth.

Governance therefore needs source authority at the level of claim type, purpose, environment and time. It should distinguish reported fact, observed signal, approved instruction, inference and disputed assertion. A source name alone is not enough.

- **01: What was supplied?** — Observation, instruction, preference, inference or correction.
- **02: Who supplied it?** — Human, device, application, model or imported record.
- **03: For what purpose?** — The context in which the source may be relied upon.
- **04: Until when?** — Validity, decay and required revalidation.

## Time changes what a fact can safely mean.

*04 / Temporal truth*

**A true observation from yesterday is not automatically valid context for an action today.**

Governed memory needs more than a creation timestamp. It should preserve when something was observed, when it was received, the period for which it is considered valid, the policy that controls decay and the event that should trigger revalidation.

Different context decays at different speeds. A stable preference may remain useful for months. A location may become stale in seconds. Capacity, consent, risk, medication instructions and delegated authority may change according to their own rules and circumstances.

The point is not to delete history when current validity ends. Historical context can remain valuable evidence. The point is to stop old context quietly presenting itself as current authority.

1. **01 / Observed** — Record when the source encountered the fact.
1. **02 / Received** — Keep transport delay and ordering visible.
1. **03 / Valid** — State the period and purpose for which it may be used.
1. **04 / Revalidated** — Require a new source or review when the boundary expires.

## Conflict is context, too.

*05 / Uncertainty*

**A system should not manufacture one clean answer when its sources disagree.**

Operational truth is often contested. A resident's stated preference may differ from an older record. Two sensors may observe different conditions. A model may infer a change that a human has not confirmed. A corrected identity may invalidate context previously attached to it.

Flattening these states into a single current value destroys the information needed to govern the next step. A context layer should retain competing claims, their sources, timing, confidence, truth lane and correction lineage. Policy can then decide whether one claim is authoritative, whether the context must be withheld or whether human review is required.

Uncertainty is not an implementation failure. Hidden uncertainty is.

## Availability is not permission.

*06 / Policy and purpose*

**The fact that context exists does not mean every actor may see it, infer from it or act upon it.**

Policy should shape context before disclosure and action. The relevant questions include who the actor is, which capability and authority they hold, the purpose of the request, the environment, the resident or subject involved, consent and capacity, delegation, jurisdiction, data classification and whether an emergency pathway is valid.

A role alone cannot carry that burden. Neither can a browser toggle, a robot setting or a database row-level rule in isolation. Governance is a decision path that should produce a durable evaluation record and preserve human care-decision ownership.

- **01: Actor** — Who is asking, acting or receiving context?
- **02: Purpose** — Why is this context needed now?
- **03: Authority** — Which capability, role or delegation permits it?
- **04: Consent** — What scope, lifecycle and capacity conditions apply?
- **05: Setting** — Which environment and jurisdiction constrain use?
- **06: Review** — Where must a human decide, confirm or stop?

## The right memory is not the whole memory.

*07 / Context minimisation*

**Governance should produce the smallest context slice that is sufficient for the permitted purpose.**

Dumping an entire resident history into an agent, robot or interface is not continuity. It increases disclosure, confusion and attack surface while making it harder to see which facts actually governed the outcome.

A context slice should be compiled for the actor and task. It can include relevant identity, current facts, applicable preferences, constraints, source and freshness indicators, policy outcome, confidence and the required human review path. Everything else remains behind its proper boundary.

- **Carer: Handover context** — Changes, exceptions, owners and unresolved questions.
- **Robot: Permitted task context** — Target, constraints, stop conditions and escalation route.
- **Agent: Bounded reasoning context** — Relevant facts, provenance, policy and uncertainty.
- **Reviewer: Decision context** — Sources, evaluation path, outcome and correction state.

## Governance must travel with the memory.

*08 / Operating path*

**Every material handoff should preserve the reason the context was admitted, qualified and disclosed.**

1. **01 / Resolve** — Associate the request and source with the correct scoped identities.
1. **02 / Qualify** — Apply authority, time, confidence, conflict and correction state.
1. **03 / Authorise** — Evaluate actor, purpose, consent, capacity and policy.
1. **04 / Materialise** — Compile the minimum permitted context slice.
1. **05 / Coordinate** — Route it to the responsible human, system or machine.
1. **06 / Evidence** — Retain the path without converting evidence into unquestioned truth.

## Governed memory canvas.

*09 / Working tool*

**Use this to find the first point where stored context loses identity, authority, time, permission or human ownership.**

### Printable Governed Memory Canvas

Record the status, owner and evidence for each governance boundary. The first unowned boundary is the most urgent design gap.

| Area | Governance Question | Status / owner / evidence |
| --- | --- | --- |
| **Identity** | Can the subject, actor, device and environment be resolved without hiding ambiguity? |  |
| **Source authority** | Is each source authoritative for this claim type, purpose and setting? |  |
| **Temporal validity** | Are observation, receipt, expiry, decay and revalidation explicit? |  |
| **Conflict** | Can competing claims and uncertainty remain visible until resolved? |  |
| **Purpose** | Is the reason for disclosure or action stated and bounded? |  |
| **Authority** | Are capability, consent, capacity and delegation evaluated together? |  |
| **Minimisation** | Does each actor receive only the context required for the permitted purpose? |  |
| **Human review** | Are decision ownership, stop conditions and escalation explicit? |  |

The canvas is not a compliance score. It is a design conversation. A named owner without observable evidence is still a weak boundary; an evidenced mechanism without clear human responsibility is not complete governance.

## A governance design is not operational assurance.

*10 / Current public boundary*

**Octeryx OS is in active R&D. This guide describes the intended category and target operating principles.**

### Currently evidenced

- Accepted modular product doctrine, architecture and implementation plan
- Typed identity, context, authority, policy and evidence contracts with deterministic proof
- Synthetic fixtures, repository validation and explicit claim controls
- Target PostgreSQL, Kasa and Film ownership boundaries

### Not currently claimed

- Live production or care deployment
- Clinical validation, certification or regulatory approval
- Production readiness or universal robot compatibility
- Unsupervised autonomous care decisions or robot operation
- Replacement of carers, clinicians, OEM software or safety systems

Typed contracts, deterministic tests and architecture controls are meaningful evidence of design progress. They are not proof of live operation, safety performance, certification or regulatory status. Read current product statements alongside the canonical [facts](https://www.octeryx.com/facts.md) and [proof boundary](https://www.octeryx.com/proof-boundary.md).

## Octeryx OS is building governed context beneath autonomy.

*11 / Company at a glance*

**One context operating system, with Kasa as the primary care profile and Film as one isolated adjacent profile.**

- **Category:** Context operating system for safe, explainable physical-world autonomy
- **Care framing:** Resident-context operating layer for autonomous care
- **Durable asset:** Governed operational context in PostgreSQL and pgvector
- **Current stage:** Active R&D / Accepted architecture and deterministic repository proof
- **Human boundary:** Human care-decision ownership remains explicit

**Octeryx OS** — The context operating system for safe, explainable autonomy

[Mark Nicoll / Founder](https://www.linkedin.com/in/marktnicoll/)

This guide is educational material, not a clinical, safety, engineering, procurement, regulatory, legal or investment recommendation. Product and maturity statements should be read with the current Octeryx OS proof boundary.