# HOME23 Inheritance and Parity Charter

Last updated: 2026-04-06
Status: canonical inheritance/parity charter
Purpose: state plainly what HOME23 canonical is inheriting from `cosmo-home_2.3`, what must become parity work, and what must be rebuilt cleanly instead of copied blindly.

---

## Core truth

`home23-canonical` is not a greenfield assistant product and not merely a dashboard scaffold.

It is the attempt to distill the real lived architecture of `cosmo-home_2.3` into a cleaner, more legible, more installable canonical full stack.

Short form:
- `cosmo-home_2.3` = the lived prototype organism
- `home23-canonical` = the effort to make that organism reproducible, coherent, and officially canonical

---

## The inheritance

HOME23 canonical inherits these architectural truths from `cosmo-home_2.3`:

### 1. COSMO vs HOME split
- COSMO is the deeper cognitive/memory substrate.
- HOME23 is the house, harness, and operator control plane around that substrate.
- Chat is ingress, not center.

### 2. Inhabited runtime, not stateless assistant
The system is meant to feel like a named self speaking from inside a running house condition.
It should preserve:
- continuity
- situated awareness
- operator relationship
- ongoing runtime state
- durable session/run history

### 3. Shared body, distinct selves
The canonical pattern is:
- one shared runtime body
- many distinct identity rooms/overlays

Agents should share runtime/tooling/body infrastructure without collapsing into identity soup.

### 4. Real loops, not request/response theater
The inherited architecture is loop-based:
- runtime/session loop
- agent tool-use loop
- workflow/objective loop
- memory/continuity loop
- introspection loop
- sleep/dream/consolidation loop
- operator control loop

### 5. Executive governance
The system is not supposed to merely think and act.
It is supposed to be governed.

Inherited doctrine:
- action should be deliverable-oriented
- drift should be rejected
- promises and real-life relevance matter
- coherence/review/gating are first-class runtime realities

### 6. Memory as living ecology
Memory is not a transcript dump.
The inherited model includes:
- decay
- reinforcement
- spreading activation
- consolidation
- bridge formation / rewiring
- hot-state vs archive distinction

### 7. House truth over decorative UI
The control plane must reflect real state.
The runtime/control surface should prefer:
- truthful receipts
- visible artifacts
- real blocked/review states
- live runtime/session history
- current hot-state surfaces

---

## What must reach parity

These are the parity domains that matter because they protect the inherited organism instead of flattening it.

### A. Runtime parity
Canonical HOME23 must keep closing the gap toward a real house runtime by preserving:
- long-lived runtime/session continuity
- house-agent execution beyond single provider turns
- checkpoint/synthesis/objective truth
- resume/review/block behavior with real consequences
- durable runtime memory refresh and workflow state

### B. Identity/voice parity
Canonical HOME23 must preserve the lived quality of a named self in-house.
That means:
- runtime turns grounded in identity + hot-state + recent conversation + house context
- less generic chatbot behavior
- explicit distinction between shared body and distinct self
- support for per-agent identity rooms/overlays

### C. Memory/continuity parity
Canonical HOME23 must preserve the continuity doctrine behind the older system:
- durable current-state surfaces
- artifact receipt discipline
- memory/brain bridge honesty
- hot-state before archive
- continuity that survives restart/resume and not just the current chat window

### D. Executive/workflow parity
Canonical HOME23 must preserve the “what gets done” layer, not just raw execution:
- objective ownership
- checkpoint/synthesis discipline
- blocked/review-required truth
- real governance over shell/tool/action behavior
- anti-drift posture

### E. Settings/provider parity
Canonical HOME23 should inherit the real maturity of COSMO 2.3 / Evobrew where it already exists:
- provider config depth
- OAuth/token storage flows
- dynamic model/provider availability
- local model handling
- settings changes with real runtime consequences
- eventual OpenClaw compatibility/import story where appropriate

### F. House/operator surface parity
Canonical HOME23 must remain a real operator house, not a generic admin panel:
- live chat/front door
- truthful runtime/workflow visibility
- tactile capability/security controls
- clear launch/readiness truth
- immediate transition from onboarding into a living house interaction

---

## What should be rebuilt cleanly instead of copied raw

The goal is not to drag every old implementation detail forward.
The goal is to preserve the organism while improving its form.

Rebuild cleanly:
- canonical repo/app/package structure
- install/onboarding flow
- operator/front-door IA
- runtime/state contracts
- control-plane presentation layer
- explicit parity docs, trackers, and handoff surfaces

Adapt carefully:
- provider settings architecture
- run continuation/resume semantics
- security/capability posture model
- workflow execution doctrine
- control-plane/runtime seams

Reuse hard where already proven:
- config/settings patterns
- provider auth/token handling
- model/provider catalog concepts
- continuity/memory doctrine
- runtime truth/receipt discipline
- house-vs-substrate architectural split

---

## Anti-drift rule

Do not let HOME23 canonical drift into any of these failure modes:
- generic assistant shell with house-themed language
- dashboard that reports fake or flattened status
- duplicate sidecar intelligence stack pretending to be the same self
- archive-first memory loading that destroys current truth
- parity claims that only cover settings/UI while losing inhabitation/continuity

If a change improves polish but weakens continuity, inhabitation, executive truth, or house reality, it is architectural regression.

---

## Working parity order

When choosing what to build next, prefer this order:
1. preserve/strengthen the live one-house launch path
2. preserve/strengthen identity-grounded runtime behavior
3. preserve/strengthen runtime/session/objective continuity
4. preserve/strengthen settings/provider parity with real runtime consequences
5. only then broaden shells/surfaces/integrations

---

## Canonical judgment question

Before landing a tranche, ask:

> Does this make `home23-canonical` a truer canonical expression of the lived `cosmo-home_2.3` organism, or does it merely add more product surface around a thinner core?

Only the first kind of work counts as real canonical progress.
