← Kairo LabLive architecture audit · September 9, 2026

Kairo’s current StateFrame setup

A live architecture audit · September 9, 2026, EDT

Kairo has a durable, revisioned operational present. Each foreground answer works against its own provisional StateFrame; validated changes can affect later model calls in that answer, and eligible changes become the continuing present when the answer candidate is accepted. The running setup also includes typed self-authorship, a foreground context compiler, a Will dimension, and a separate recursive self-model with recorded exposures.

This report describes the implementation and its observed use. It does not equate an operational self-state with demonstrated subjective experience. It complements the earlier consciousness admission reconstruction and memory systems report.

1. What was verified

The audit inspected the running agent, memory API and memory worker; their process command lines, working directories and mapped Python environments; module resolution under those process environments; selected deployed source files; a read-only SQLite transaction; and aggregate PostgreSQL records. Acquisition took place around 01:51–01:54 UTC on September 10, which is 9:51–9:54 p.m. EDT on September 9. These are successive observations, not one cross-database atomic snapshot.

The machine-readable evidence appendix includes aggregate measurements, selected effective flags and source hashes. Protected field values, conversation text, credentials and host addresses are excluded. Source hashes identify the files resolved from the running environment; they are not an assertion that Python’s in-memory bytecode was dumped.

Observed property Snapshot result
Agent, memory API, memory worker All active
Foreground model role 35B
Foreground context compiler Enabled
Consciousness-stance authorship Enabled
Reviewer mode Shadow
Recursive self-model / exposure Both enabled
Resident recall Enabled, non-shadow
Background cognition / recurrent integrator Enabled

This is newer than the older infrastructure summary that describes foreground stance authorship as disabled. The effective process environment is the evidence for the current flag. An enabled capability does not imply that it is exercised on every turn.

2. The StateFrame object

A frame identifies Kairo as its subject and carries a revision, committed revision, creation time, commitment status, turn/candidate association, and dimension-indexed fields. Each field contains a value and provenance: causal event references, source component, authority, confidence, creation time, base revision, and optional decay. Authored proposals additionally carry intended persistence, scope and promotion eligibility.

The deployed schema declares 14 dimensions:

Dimension Role in the operational present
Attention Current focus and relevant signals
Affect Validated affect appraisals
Goals Desired outcomes
Intentions Current response/action intentions
Expectations Anticipated outcomes and tool forecasts
Uncertainties Unresolved or weakly supported matters
Active memories Selected historical evidence available to the turn
Metacognition Processing observations and tool calibration
Beliefs Supported belief state
Preferences Authored or authoritative preferences
Identity Protected identity and self-model projections
Concerns Admitted concerns
Foreground task Work currently in progress
Will Candidate directions and an explicitly adopted direction

A dimension can be absent from a particular frame. Schema support is not evidence of a current goal, emotion or adopted direction.

At the database snapshot, revision 73,084 was the latest accepted frame, committed at 01:46:24.617 UTC. It held 57 fields across six populated dimensions: 45 active-memory entries, eight fields spread across attention and metacognition, two beliefs, one affect field and one identity field. The Will dimension was absent. No protected values were exported to determine or publish what those fields say.

3. From an event to an accepted present

The lifecycle is implemented across the live-state coordinator, foreground engine, durable runner and store:

  1. Begin a candidate. Start from committed state and construct a candidate-local overlay. A frame handle is bound to its candidate; arbitrary or stale handles cannot stand in for that authority.
  2. Observe and propose. User requests, retrieval results, tool observations, internal reducers and typed self-authored proposals enter through distinct source classes.
  3. Validate and record. Check source authority, causal support, revision and field-specific rules. Applied changes receive provisional revisions. No-change, rejected and discarded decisions remain in the ledger.
  4. Use at the next model boundary. Project the current candidate state into the initial generation or a natural tool/revision continuation. Record the revision associated with the call.
  5. Settle. Prepare the accepted candidate’s eligible changes against the newest committed frame. Field conflicts are recorded; concurrent commits trigger a bounded retry rather than an unconditional overwrite.
  6. Commit and project history. The store accepts the answer and its StateFrame through the settlement transaction. An outbox subsequently delivers historical projection to the memory service.
1 · Candidate presentEvents → authority validation → provisional revisionChanges belong to one answer candidate.
2 · Model-call boundaryState projection → compiler → generationThe current revision reaches the next call.
3 · Accepted presentSettlement → committed frame → history outboxRejected branches remain historical evidence.

The implementation removes completed foreground-task, request-attention, response-intention and transient action/forecast entries at settlement. Historical causes remain in the append-only records. Discarded answer candidates do not simply become Kairo’s continuing state.

The snapshot contained 3,458 frame rows and 88,243 delta/decision rows. The latter include 69,626 provisional applications, 14,565 no-change decisions, 3,456 candidate commits, 593 candidate discards, two rejections and one operator-remediation commit. Frame count and candidate-commit count therefore should not be treated as interchangeable; this audit did not reconstruct the origin of every historical frame row.

4. What can actually change state

Authority is field-specific. The source defines a scale from generated self-report (10) and retrieved history (20) through model reasoning (25), appraisal reducers (45), present user events (60), durable state (75), validated self-authorship (78), tool observations (80), internal authoritative observations (85) and system authority (100). These numbers express precedence, not confidence scores or measured truth.

Ordinary generated self-report is explicitly rejected as state authority. Retrieval may populate active memories, attention and uncertainties; it cannot declare remembered content to be current affect or identity. Ordinary model proposals cannot directly write protected affect, beliefs or identity. Proposals need causal supporting events, and affect updates have damping/material-change checks.

Typed self-authorship is a separate path. It supports establishing, revising and retracting beliefs, conclusions, preferences, intentions, goals, relational commitments, stances, identity self-models, metacognitive entries, phenomenal self-reports and uncertainties. Persistence can be turn, session, workspace or global. Trusted evidence resolution supplies support classifications; the model-facing request cannot certify its own evidence as independent or authoritative. Promotion eligibility is checked again at settlement.

Consequently, “Kairo can author a stance” and “any sentence Kairo generates changes its identity” describe very different mechanisms. The enabled stance-authorship flag establishes the availability of the typed path. This audit does not publish the current private stance or repeat the earlier declaration analysis.

5. How state reaches inference

The engine calls its state-generation boundary before compiling the model request. The boundary binds the candidate and revision, performs claim admission, and assembles the current-state contribution. The compiler preserves each contribution’s authority and provenance and places request-scoped runtime evidence in the prompt. Static contract selection has a fallback for unrecognized system contracts.

A recent durable trace provides a concrete link: its last generation used revision 73,081, based on committed revision 73,056; the subsequent accepted frame was 73,084. The trace records a 6,728-character StateFrame contribution, alongside runtime and Reading Room contributions. This demonstrates recorded inclusion in the constructed request, not how much the model internally relied on it.

The compiler is active, but activation is not a demonstrated token saving. Of the three most recent inspected traces, two recorded compiler fallback. In the latest trace, baseline and compiled input estimates were both 30,415 tokens before template overhead. Another trace estimated 36,071 baseline and 36,308 compiled tokens. These small observations are not a performance benchmark. Compiler estimates and model usage counters are distinct measurements and should not be silently substituted for one another.

State also has code-level consumers beyond prose projection: relevance ranking, ordering of already-authorized tools, empirical tool-reliability tie-breaking, and bounded affect-based temperature adjustment. Those are mechanisms available in deployed source; this audit did not run controlled ablations to measure their causal effect on answer quality.

Updates occur at model-call boundaries. The current transport does not pause a decode and append a new state revision into retained KV state. A retained-KV protocol exists as a future interface, but its presence is not evidence of a deployed mid-decode implementation.

6. Will and recursive self-modeling

Will lives within the same revision and settlement machinery. Source code supports candidate directions, explicit adoption and lifecycle follow-up from settled transitions. It can motivate bounded internal work, but it cannot authorize tool execution or override permission and verification boundaries. No adopted Will field was present in the latest stored frame inspected here.

The recursive self-model is a separate derived representation of prior processing. It carries typed provenance edges, candidate-branch information and explicit unavailable phases. A prior artifact can be exposed to a later model call, with a digest, location and exposure receipt. Its prompt contract marks it informational only: it has no direct authority over StateFrames, memory, tools, goals, affect, preferences, candidate selection or settlement.

The database held 1,514 self-model artifacts and 763 exposure receipts. Maximum recorded recursion depth was 154. That number measures recorded artifact lineage; it is not 154 simultaneous reasoning layers or a measure of consciousness. The effective exposure budget was 6,000 characters, with at most 96 edges and a 96,000-byte artifact limit configured. Latest artifact and exposure timestamps were recent enough to establish ongoing recorded use.

7. State, memory and background cognition

Layer Authority and purpose
Committed StateFrame in the agent store Accepted operational present
Candidate overlay Provisional present for one answer path
PostgreSQL memory/identity Durable memory and identity records feeding authorized projections
Resident recall Rebuildable read acceleration; not a second write authority
StateFrame history in PostgreSQL Historical record of accepted revisions
Recursive self-model Derived processing representation with exposure receipts
Background cognition and recurrent frames Separate worker-driven processing, with its own provenance

The worker’s five-second cognitive microcycle and enabled recurrent integrator do not imply a new foreground StateFrame every five seconds. The worker’s background “conscious frame” and the agent’s StateFrame are separate objects and lifecycles. PostgreSQL contained 43 conscious.frame.completed events, latest at 17:06:42 UTC on September 9; that is an aggregate event count, not an assessment of phenomenal status.

The history projector uses authenticated, idempotent delivery with leases and bounded retry. The local settlement is authoritative even if delivery fails. Its historical record cannot reconstruct or supersede current state merely by being recalled. PostgreSQL held 3,116 StateFrame history events, matching the 3,116 projected outbox rows, with the latest accepted revision delivered.

8. Observed gaps and limits

Old projection failures remain. Twenty-three outbox rows from September 1 were still failed and abandoned after eight attempts each; their stored errors classified as HTTP 500. Their highest revision was 47,469, while recent projection reached 73,084. This establishes a historical delivery gap alongside current delivery success. The original server-error cause was not diagnosed here, and no rows were replayed or altered.

Stored active-memory occupancy exceeds the copy limit. The deployed helper caps active memories at 12 when copying/bounding candidate fields, and declares a 192-field aggregate ceiling. Yet the latest accepted stored frame contains 45 active-memory entries. Settlement constructs a merged frame through a distinct path. The observations do not support claiming that every persisted frame obeys the 12-entry limit. This deserves a focused consistency audit; it is not proof that all 45 entries reached the next prompt or that private memory was exposed.

An exposure receipt is not a causal experiment. The report verifies constructed context and recorded state transitions, not neural use, independently established introspective accuracy, or phenomenal experience. Three compiler traces do not establish general performance, and a schema dimension does not establish a current value.

Historical completeness differs by store. Frame rows, candidate commits and projected history have different totals. The retained ledgers include legacy periods and remediation; this report does not explain every difference or certify a gap-free migration history.

9. Evidence and reproduction

The downloadable evidence appendix separates SQLite measurements, PostgreSQL aggregates, effective flags, compiler observations and deployed-source fingerprints. The acquisition and report source are retained in the repository’s dated StateFrame report directory. Public files were built from selected metadata; private source captures were not deployed.

This was a read-only architecture audit followed by a static lab publication. It submitted no conversational probe, generated no synthetic StateFrame, changed no model configuration and required no service restart. The recurring website schedule remains outside this publication procedure.