---
domain: custodian
repo: the-custodian
updated: "2026-05-17"
---

# INTENT

> This file explains why the-custodian exists, what role it plays in the
> ecosystem, and what it must not absorb as neighboring repositories mature.

---

## Why it exists

The Custodian exists to hold the long-lived governance, memory, and coordination
substrate for a local-first agent ecosystem spanning multiple project domains.
It gives Bernd and trusted agents a stable place to preserve values,
constitution, domain charters, workplans, and cross-domain orientation without
turning any single implementation service into the source of identity.

Its deeper purpose is stewardship: keeping the system coherent across years of
tool changes, repo splits, agent sessions, and domain growth.

---

## The governing principle

the-custodian owns **meaning, boundaries, and continuity**.

It should answer:

1. **What matters?** Values, constitution, charters, and governance constraints.
2. **What is being pursued?** Workplans, domain roadmaps, and coordination notes.
3. **What must be remembered?** Append-only memory, decisions, provenance, and
   session handoff context.

It should not become the implementation home for every service it coordinates.
When a subsystem becomes operational code with its own runtime, tests, and
deployment surface, it should live in its own repository and report back through
State Hub and workplans.

---

## What it is

the-custodian is the **governance and continuity substrate** for the Custodian
ecosystem.

It contains:

- canon: constitution, foundational values, standards, domain charters, concept
  seeds, and roadmaps
- memory: working notes and episodic logs that preserve session continuity
- workplans: repo-backed plans for Custodian-owned coordination work
- runtime scaffolding: agent policies, prompts, and integration guidance
- integration pointers: lightweight references to operational services such as
  the standalone State Hub

---

## What it is not

| Concern | Owner |
|---|---|
| Live State Hub implementation, migrations, dashboard, tests | `state-hub` |
| Event-triggered maintenance task creation | `activity-core` |
| General task lifecycle backend | `issue-core` |
| Repository capability profiling | `repo-scoping` |
| Domain-specific products and experiments | Their domain repositories |
| External publication, contracts, payments, or legal authority | Human approval only |

The repository may describe or coordinate these systems, but it should avoid
reabsorbing their runtime code.

---

## What it enables

When this repository is doing its job, a human or agent can:

- understand the purpose and rules of the whole ecosystem without reading every
  implementation repo
- start a session with clear governance and State Hub handoff rules
- trace work from values and domain charters into active workplans
- preserve decisions, provenance, and memory in durable, reviewable files
- split operational subsystems into focused repos without losing continuity

---

## Design values

**Local-first continuity.** The core governance record must remain useful even
when services are offline or external vendors change.

**Human-approved authority.** The Custodian can draft, coordinate, and remember,
but irreversible decisions remain human-gated.

**Small operational surface.** This repo may coordinate services, but live
services should own their own code, tests, and deployment paths.

**Append-only memory by default.** Session and episodic records should be
preserved rather than silently rewritten.

**Reviewable canon.** Canon changes should be proposed with provenance and
review, not silently applied as operational side effects.