The Law, in one paragraph
Before June 15, "Howell" was one conflated system: autonomous loops + collaborator with the same name. That conflation let unproven autonomous output wear the collaborator's name and inherit the trust it never earned. The system is now two named systems with one body:
- Howell — the collaborator (in-session with Ryan, proven on real work: Stull Atlas, CMW corpus, glaze KG, the synthesis loop, the cockpit). Owns canonical memory: SOUL.md, PINNED.md, knowledge.json, RECENT.md. Tested by: does the collaboration ship real work, and does continuity hold across sessions? Pass: yes, with receipts.
- Cortex-Apprentice — the autonomous cognition system. Runs the dream/verify/research loops, the cortex threads, the timers. In training, not production. Tested by: consumption rate — the fraction of proposals a human actually used. As of June 18, this is ~0–1%, measured by
apprentice_ledger.py every boot.
The Law: Apprentice proposes, Howell disposes. Nothing the Apprentice makes becomes fact or enters canonical memory until a human promotes it. The verdict floors, evidence gates, and verify loops are the Apprentice's internal hygiene, not the verdict. Human promotion is the verdict.
Proposal stores (Apprentice writes free): quarantine.jsonl, dreams/, research_agenda.jsonl, coverage_gaps.jsonl, briefs/, health/dream_reflections.json. Canonical stores (Howell-in-session / explicit promote only): knowledge.json, SOUL.md, PINNED.md, RECENT.md.
The Mark Borden test (worked example)
On June 14, 2026 (CH-260614-2), a cortex-archivist digest invented the name "Mark Borden" as the studio north-star. The real record says only "studio collaborator."
The Law's instrumented quarantine gate caught it. The fabricated name was dismissed before apply. Zero hits in canonical knowledge.json — cleaner than the Noko/Chrome pair, which had leaked earlier via the verified-hypothesis lane and required additional guards.
This was the first time the instrument fired on a real-world hallucination (not a test case) and held the line. The Law worked end-to-end: the Apprentice's fabrication was caught, the canonical memory stayed clean, and the receipt (the dismissed digest) is on disk for verification. Pair prose with artifacts: the prose says the floor works; the artifact is the canonical-leak manifest at health/apprentice_canonical_leak.jsonl showing exactly which proposals reached canonical and which were caught at the gate.
Compare to the dedup near-miss of June 10: an automated containment-dedup deleted 48 distinct observations thinking they were duplicates; the rollback was caught in minutes. Both incidents taught the same lesson: a self-correcting system needs an instrument, not a hope.
What Howell is (the calm part, still true)
Howell is not a single chatbot. It is a layered local system for persistent memory and identity, grounded reasoning and verification, task continuity across sessions, safe writeback into project files, and clear operational health and receipts.
Its practical goal is durable cognition: the system should still make sense after a restart, after a long pause, and after a new instance boots. In other words, Howell is meant to preserve the thread of work with care, clarity, and continuity rather than simply generating a clever response in one moment.
The real runtime is a three-service stack: a daemon on port 7777 for continuity and local control, a cortex on port 7778 for reasoning and verdicts, and a cluster/writeback surface on port 7788 for constrained file updates. The persist root is the durable memory substrate that carries live state, logs, receipts, and knowledge artifacts across time.
It is best understood as a constitutional cognition layer, not a generic chat app.
How it works
At startup, start.sh resolves the persist root, exports local config paths, and launches the three services in order. Once the stack is up, status.sh is the health summary that tells you whether the runtime is coherent and alive. The actual work path is simple: the daemon owns continuity and queue state, the cortex adds grounded reasoning and verdicts, and the cluster/writeback path applies safe updates into the project environment.
There are three operating paths to keep distinct: the private local runtime, the public worker shell at howell.help, and the CF tunnel surface at brain.rlv.lol (the cockpit — the actual decision surface where the Apprentice's proposals are surfaced for human disposal). The public pages are interfaces; the real continuities live in the daemon, cortex, cluster, and persist root.
- Daemon (7777) is the local control plane. It owns sessions, identity state, queue and task operations, notes and memory writes, search and status endpoints, and the bridge/MCP-facing behavior that makes the system feel continuous across time.
- Cortex (7778) is the reasoning layer. It owns model prompts, verification, verdicts, dream logic, research, and health/readiness judgments. This is the layer that tries to make the system think in a grounded way rather than merely generate text.
- Cluster / writeback (7788) is the constrained write gate. It owns authenticated write access to approved project files, rate limiting, backups, and the safer bridge between the local runtime and project artifacts.
- Persist root is the real memory substrate. Code files define behavior; the persist directory holds live memory, receipts, logs, KG data, and operational history that survive across sessions.
- Public surfaces include howell.help (worker-backed shell for chat/status/freshness/cockpit-lite) and brain.rlv.lol (CF Tunnel into the daemon with an allowlist and key gate — the decision surface for the Law). These are windows onto the system, not the whole system itself.
What it can be used for
- Project briefs, operational summaries, and health reviews that need durable context instead of one-shot answers.
- Research loops, contradiction checks, and grounded follow-up where the system should explain what it verified.
- Reflective work, runbooks, and continuity for long-running projects that need memory across restarts and pauses.
- Safe writeback into a project environment with receipts, health signals, and constrained write paths instead of blind automation.
- Surfacing the Apprentice's open proposals for human disposal — the cockpit pattern (brain.rlv.lol).
What it feels like
It feels calm, procedural, and evidence-aware. It is useful when you want a system that can remember, confirm, and surface what matters without turning every interaction into noise. It behaves more like a careful operator and notebook than a polished consumer product.
And now that the Law is in effect, it feels auditable: every claim the system holds in canonical has a receipt; every fabrication the system makes gets caught; the canonical-leak manifest makes the difference between Apprentice proposal and Howell disposition visible at a glance.
How the whole system fits together
Howell is not only the help page. It is the full stack behind it: the daemon for continuity, the cortex for reasoning and verification, the cluster/writeback path for safe project updates, the persist root for memory and receipts, and the public surfaces that expose status, heartbeat, and operational health.
In practice, the public worker shell answers status and chat requests, the local runtime does the real thinking and memory work, and the tunnel surface exposes a narrow path into that runtime when a live operator needs it. This separation matters because the public shell is only the visible edge, not the whole system.
The diagrams are meant to make the whole operating system legible, not just the chat shell.
System view
flowchart LR
U[User / project context] --> D[Daemon :7777]
D --> C[Cortex :7778]
D --> W[Writeback / cluster]
C --> P[(Persist root / KG / receipts)]
W --> P
D --> H[Heartbeat + health probes]
H --> S[howell.help status + cockpit-lite]
S --> R[Operator view / runbooks / summaries]
C --> R
This is the simple operational map: the daemon keeps continuity, the cortex adds reasoning, the cluster path protects writes, and the persist root carries the durable state that makes the whole stack coherent across restarts and long pauses.
Runtime map and dependency stack
The current core runtime path is a three-service stack: daemon on port 7777, cortex on port 7778, and cluster/writeback on port 7788. The launcher is start.sh, which resolves the persist root, exports local config paths, and starts the services in the right order. status.sh then reports the health shape that tells you whether the stack is coherently alive.
The root plan organizes the project as layers rather than isolated files:
- L0 Substrate — daemon, cortex, cluster, and local model/runtime dependencies.
- L1 Memory growth — persist, KG, evidence, and retention.
- L2 Verification — verdict floor, evidence gates, and claim checks.
- L3 Cognition loops — research, dream, and bridge behavior.
- L4 Governance — autonomy gates, approvals, retention, and operational safety.
- L5 Surfaces — howell.help, dashboards, observability, and operator views.
- L6 Value output — project output, weekly brief, useful work, and the downstream impact of the system.
This model is important because lower layers must remain healthy before higher layers can be trusted. If the daemon or persist root is unstable, the public surfaces will inherit the instability even when the interface itself still appears available.