A care professional and technical operator review information while a service robot waits in the background.

Octeryx OS / Foundation Guide 03

Action needs
evidence.

An autonomous action is not accountable unless its source, context, authority, outcome and human boundary can be reconstructed.

Foundation Edition 0.1 / July 2026 / 15 minute read

  1. 01Source
  2. 02Decision
  3. 03Receipt
  4. 04Explain
Take it with youDownload and share with your product, operations, assurance, investment or research team.
LinkedInXEmail.md

Read this if you are

  • BuildingAgents, robots or context-aware workflows
  • OperatingSystems where actions affect people or places
  • AssuringSafety, governance, audit or incident review
  • EvaluatingWhether autonomy claims are reconstructable

01 / Opening argument

Every action creates an obligation to explain.

Capability tells us that a system can act. Evidence helps us understand whether it should have acted, what happened and what must change next.

When software recommends a task, an agent routes an instruction or a robot changes the physical environment, the result cannot be treated as a transient output. Someone may need to understand which event started the path, whose identity was resolved, what context was considered, which policy permitted the action, who retained authority and whether the outcome matched the request.

Logs are useful, but they are rarely organised around that question. They show what individual components emitted. They may omit rejected alternatives, the exact context supplied to a model, the policy version, the human confirmation or the relationship between a command and its physical receipt.

Evidence should be designed as part of the operating path. It is not an after-the-fact reporting feature. The system should preserve enough structured lineage to reconstruct material decisions while protecting sensitive context and keeping uncertainty visible.

If the next reviewer cannot reconstruct the path, the environment has an output but not an accountable outcome.

02 / Completion

A receipt is not an explanation.

“Task completed” describes a terminal state. It does not establish why the task was valid or what actually occurred.

A command can be accepted, rejected, cancelled, superseded, retried, partially completed or confirmed by a human. The physical effect may differ from the requested action. A robot can report success while the environment later shows that the intended outcome did not occur.

A durable receipt should therefore connect the command to the actor, target, capability, policy decision, idempotency key, execution state and observed outcome. It should not turn device confidence into unquestioned truth. Confirmation may need to come from an independent source or responsible human.

QuestionCompletion logAccountable evidence
RequestedA task name or API callTyped command, actor, target, purpose and constraints
PermittedThe endpoint returned successPolicy evaluation, authority and human boundary are linked
PerformedThe device reported completionReceipt and independent outcome evidence remain distinct
CorrectedThe current status was overwrittenSupersession and correction lineage are retained

03 / Decision lineage

Preserve the chain, not just the answer.

Accountability depends on the handoffs between source, context, authority, action and outcome.

  1. 01Source

    Which event, request or observation started the path?

  2. 02Identity

    Which subject, actor, device and environment were resolved?

  3. 03Context

    Which facts, confidence, freshness and conflicts were materialised?

  4. 04Authority

    Which capability, consent, policy and human boundary applied?

  5. 05Action

    Which typed command was coordinated and with what constraints?

  6. 06Outcome

    What receipt, observation, review or correction followed?

Each link should refer to stable evidence rather than duplicating unrestricted sensitive data. The chain needs enough integrity to expose missing or substituted records, while access to the underlying context remains policy-controlled.

04 / Evidence bundles

Evidence should travel at the boundary.

A reviewer should not need privileged access to every component in order to understand one material path.

An evidence bundle is a purpose-shaped collection of references, records and integrity information assembled for a defined review. It may support an operational handover, incident review, resident query, supplier discussion, assurance exercise or export.

The bundle should say what it covers, who requested it, which environment and subject scope apply, which redactions were made, which versions and keys were used and what remains unavailable. A valid signature can show integrity and origin; it cannot prove that a claim is true, a decision was lawful or an action was safe.

01

Scope

Environment, subject, event range and review purpose.

02

Lineage

References from source through decision and outcome.

03

Versions

Contracts, policy, context and canonicalisation in force.

04

Integrity

Checks, manifests and verification result at the boundary.

05

Disclosure

Classification, redactions and omitted material.

06

Review

Human owner, conclusion, correction and follow-up.

05 / Human authority

The most important action may be to stop.

A dependable system makes refusal, escalation and human confirmation observable outcomes.

Autonomy is often described as the ability to continue without interruption. In governed environments, restraint is part of capability. Unresolved identity, stale context, missing authority, conflicting instructions, consent ambiguity or unavailable evidence may require the system to withhold context, reject a command or pause for review.

The human pathway should identify who owns the decision, what evidence they receive, which alternatives remain available and how their confirmation or correction becomes part of the record. A generic “human in the loop” label is not enough.

In care, human care-decision ownership remains explicit. Robots, models and software can contribute signals, context and coordination without quietly acquiring clinical or care authority.

ProceedPermit within constraints

Record the authority, conditions and responsible owner.

ClarifyRequest missing context

Keep the original uncertainty and new evidence linked.

EscalateRoute to the right human

Preserve who received the case and why.

StopRefuse or suspend action

Treat safe non-action as a first-class outcome.

06 / System boundaries

Evidence disappears at handoffs unless it is designed to cross them.

Every interface should state what it can attest, what it merely reports and what remains outside its authority.

Source systemOrigin, observation time and source record
Octeryx ingressNormalisation, scope and immutable event envelope
Identity and contextResolution, truth lane, freshness and materialisation
PolicyCapability, consent, authority and evaluation record
RuntimeCommand, coordination, idempotency and receipt
Human reviewerDecision ownership, correction and conclusion
Export boundaryPurpose, redaction, manifest and verification

A robot's onboard control and safety systems remain responsible for their own physical guarantees. A model remains a contributing component, not an authority for identity, consent, policy or truth. An application can present evidence without becoming the canonical operational record.

07 / Correction

Correct the record without erasing the path.

Accountability requires a visible relationship between the original state, the correction and every downstream consequence.

Operational context changes. An identity match can be reversed. A source can retract a claim. A human can discover that an action receipt was incomplete. Sensitive material may require redaction from an export while remaining under stricter internal control.

Overwriting the original record makes later review impossible. Keeping every copy without access controls creates a different risk. The evidence design should append corrections and supersession links, preserve the reason and authority for the change, and apply policy to each representation.

Correction lineage allows the environment to learn without pretending that earlier decisions were made with information that did not yet exist.

08 / Operational continuity

The next actor should inherit a reconstructable handover.

A good handover carries changes, unresolved questions, owners and evidence rather than a flattened summary.

Humans, agents, applications and machines enter and leave an environment at different times. Each handover is a risk that context will be reduced to a sentence without sources, certainty or responsibility.

A reconstructable handover should distinguish what changed, what remains disputed, which action was taken, who owns the next decision, what must be revalidated and where supporting evidence can be accessed. The recipient should see the minimum necessary context, not the unrestricted history.

ShiftOperational handover

Changes, exceptions, owners, open actions and evidence references.

MachineTask handover

Command state, constraints, stop conditions and receipt history.

ReviewAssurance handover

Decision trace, versions, redactions, correction and conclusion.

ResidentHuman explanation

Plain-language purpose, action, responsible owner and next step.

09 / Working tool

Decision reconstruction canvas.

Use this after a proposed or completed action to find the first point where explanation, authority or outcome becomes unverifiable.

Decision reconstruction0 / 8 areas evidenced
First unowned area: Trigger. Name the responsible party before the architecture hardens.

The canvas does not prove that an action was correct. It tests whether the path can be examined. A complete reconstruction may still expose a poor decision; an incomplete one prevents meaningful review.

Portable edition

Bring reconstruction into the review.

Download the A4 edition with the evidence framework and printable decision canvas.

Download PDF

10 / Current public boundary

An evidence architecture is not operational assurance.

Octeryx OS is in active R&D. This guide describes intended evidence principles and accepted target architecture.

Currently evidenced

  • Accepted modular product doctrine, architecture and implementation plan
  • Typed event, provenance, policy, decision, command, receipt and evidence contracts
  • Deterministic 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
  • Operational cryptographic assurance or post-quantum protection
  • Unsupervised autonomous care decisions or robot operation

Contracts and deterministic tests can show that the intended evidence vocabulary is precise and reviewable. They do not establish production safety, certified operation, regulatory compliance, live key custody or real-world outcomes. Read current statements with the canonical facts and proof boundary.

11 / Company at a glance

Octeryx OS is building context that can explain its path.

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
Evidence thesis
Material actions should link source, context, authority, receipt and outcome
Current stage
Active R&D / Accepted architecture and deterministic repository proof
Human boundary
Human care-decision ownership remains explicit
Octeryx OSThe context operating system for safe, explainable autonomy
Mark Nicoll / Founder

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.

Keep the path visible

The action is only one moment. Preserve what made it accountable.