# Baseline Self-Model Control Loop

Copyright 2026 Conscious Effort Company. Licensed under CC BY 4.0.

The accompanying Python reference implements a subset of this design: state
records and action-boundary decisions. The architecture below includes
intended behavior beyond the five unit-tested examples. No physical control
or integrated perception, learning, or recovery system is demonstrated.

## Purpose

This architecture describes a simple metacognitive control loop for an embodied intelligence system. The goal is to make the robot track what it is doing, what it believes, what it can safely attempt, and when its own internal model may be stale or wrong.

## Scope

This document is a baseline pattern, not a complete robot stack. It focuses on the relationship between perception, memory, self-modeling, planning, action, and feedback.

Included:

- Self-state representation
- Confidence and uncertainty tracking
- Action gating
- Feedback-based model updates
- Failure detection

Out of scope:

- Specific robot hardware
- Low-level motor control
- Full perception models
- Cloud infrastructure
- Private calibration or deployment details

## System Assumptions

- The system has sensors that observe the environment or robot state.
- The system can issue actions to simulated or physical actuators.
- The system has a memory layer with some notion of source and recency.
- The system can distinguish commanded state from observed state.
- Safety constraints exist before action execution.

## Core State

The system maintains four related state groups.

### Observed State

Information directly measured by sensors or runtime instrumentation.

Examples:

- Joint positions
- Camera frames
- Battery state
- Contact events
- Error codes
- Latency measurements

### Inferred State

Information estimated from observations, history, or models.

Examples:

- Object identity
- Task progress
- Confidence score
- Estimated pose
- Environment affordances
- Likely cause of failure

### Self-Model

Information about the system itself.

Examples:

- Available sensors
- Available actuators
- Current control mode
- Known degraded components
- Current safety envelope
- Recent failures
- Capabilities and limits

### Intent State

Information about what the system is trying to do.

Examples:

- Active goal
- Candidate plan
- Next action
- Expected outcome
- Stop conditions
- Recovery policy

## Control Loop

```text
observe -> update world model -> update self-model -> propose action
        -> check action boundary -> execute or reject -> compare feedback
        -> update memory -> continue, recover, or stop
```

Diagram source: [../../media/diagrams/metacognitive-control/baseline-self-model-control-loop.mmd](../../media/diagrams/metacognitive-control/baseline-self-model-control-loop.mmd)

## Action Boundary

Before execution, each action should be checked against:

- Physical limits
- Safety limits
- Current confidence
- Required preconditions
- Hardware availability
- Staleness of relevant state
- Permission level

An action can be:

- Accepted
- Rejected
- Reduced in scope
- Converted to a simulation-only preview
- Deferred until better evidence is available

## Memory Requirements

Memory entries should preserve:

- Source
- Timestamp or sequence
- Confidence
- Scope
- Whether the data is observed, inferred, simulated, or user-provided

The control loop should not treat stale memory as live evidence.

## Failure Modes

| Failure | Detection | Response |
| --- | --- | --- |
| Stale self-model | Required state is older than the action policy allows | Refresh state or reject action |
| Commanded state differs from observed state | Feedback does not match expected outcome | Stop, reduce authority, or enter recovery |
| Confidence collapse | Planner uncertainty crosses threshold | Ask for more evidence or switch to conservative behavior |
| Missing capability | Action requires unavailable sensor or actuator | Reject action and report missing capability |
| Unsafe action proposal | Action violates safety envelope | Reject action before execution |

## Evaluation Questions

- Can the system explain why an action was allowed or blocked?
- Can it distinguish observed facts from inferred beliefs?
- Can it detect when its self-model is stale?
- Can it recover when commanded and observed state diverge?
- Can it reduce action authority under uncertainty?

## Initial Implementation Target

A first reference implementation can be simulation-only:

- Define a small robot state object.
- Define observed, inferred, self-model, and intent state.
- Add an action proposal function.
- Add an action boundary checker.
- Add feedback comparison.
- Log why each action was accepted, rejected, or reduced.