Brain — single-source transition

1. mem.jbnx.io (the store itself) — jbnx Supabase mem_entities/mem_facts/mem_relations: ~105 entities, ~470 facts, 101 relations, 221 sealed rows. Schema carries entity/attribute/value/source/source_date/confidence/status/supersedes_id + FTS. Almost no application code consumes it. Class: source. 2. Brain local files (~/workspace/brain/) — facts.jsonl + graph.json are policy-cache since the Nov 10 sync, but lanes still append locally with no guaranteed re-sync; extract.py writes candidates locally first. Drift risk. 3. fedm8.com — static build + fedm8 Supabase (transactional app data, fine). But OFFER knowledge (grant model, prices, launch dates) is hardcoded in HTML across home, /plans, /faq, legal. Proven harm: AUD-A/B found pages contradicting each other on the grant model the day before launch. 4. fedm8.com/trust — static HTML with data baked in. /trust/p is a hand-made Nov 9 snapshot (200 items). /trust/f carries the entire dev-stack cost ledger inline (~$1,560/mo); updating a price means patching HTML. 5. fedm8.org (Foundation, repo jbnx/fvf) — own Node server + data/f.json (13 formation items, $675 planned) + auth/users.json. Same foundation, second source: its formation view differs from fedm8.com/trust/f. users.json exposure = AUD-E-13 (boss declined rotation; fix queued). 6. jbnx.io (Flask) — /w4l canon = repo static file character-bible.md (exists in 3+ places); /design (Kaylee m/001) canon in model_design.py + templates; /rh reads jbnx Supabase. 7. projects.jbnx.io + command center — portfolio.* + pf_* in jbnx Supabase. Work state is genuinely transactional, but its DOCS are knowledge that also gets mirrored into local markdown and drifts. 8. pw.jbnx.io — Edge Function vault, encrypted hints, self-contained. Mem holds only pointers — the model pattern for secrets. 9. star.jbnx.io — star-room Edge Function + own tables (live session state). Fine as-is; mem holds design pointers. 10. Email index (~/workspace/email-index/) — local SQLite + commitments.jsonl; upstream Gmail (5 accounts) + mail.jbnx.io mirror (138k rows). Deadlines live in a local file; mem learns them only via the local-first extract pipeline. 11. Finances — local markdown + Nov 6 NodeDough snapshot + live Plaid. Three versions of the money story aging at different rates; only Plaid is live. Boss ordered multi-AI reconciliation against mem. 12. Kaylee canon (@heykayleedmv) — design page + local anchors + batch folders + QUEUE.md; voice lock also in mem. Canon in 3 places. 13. W4L canon + voice sheet — bible x3 + voice folders + mem summary rows. Worst offender #2: every recast propagates by hand.

1. Stack costs — 5 homes: /trust/f inline ledger, fvf data/f.json, ~/workspace/finances/*.md, mem facts, NodeDough snapshot. Hand-edited in all five. 2. W4L canon + voice sheet — bible in 3+ places; swaps propagate manually. 3. Foundation formation state — 4 views (fedm8.com/trust/f, fedm8.org f.json, projects VF-* tasks, local nonprofit docs) with divergent numbers (formation 50% vs 13 items / $675 planned). 4. FedM8 offer facts — grant model/prices/dates hardcoded across two sites + RFC doc + mem; already produced live contradictions (AUD-A/B). 5. Finance plan figures — docs vs mem vs NodeDough snapshot. 6. Deadlines/commitments — email-index local files vs brain vs mem.

(a) KNOWLEDGE -> mem is the source. Facts, costs, people, stack, canon/voice sheets, decisions, deadlines, addresses, offer terms. Surfaces render mem; they never own a copy. (b) TRANSACTIONAL -> stays in the app DB. FedM8 member accounts, VerifyPass verifications, portal work state, pw-vault entries, star-room turns, the email index itself. Mem holds pointers and summaries, never the records. (c) SECRETS -> never in mem. Values live in Supabase/Railway secret stores only; mem records name + location (the existing sealed-row pattern, 221 rows, is the template).

Small, backwards-compatible additions to mem_facts: - visibility text not null default 'private', check (private | agent | public) — what may leave the store. - kind text — fact | cost | canon | deadline | decision | pointer — consumers filter by data type, not just text search. - consumer_tags text[] — e.g. {stack-costs}, {w4l-canon}, {trust-pages} — the filter a surface subscribes to. - mem_public VIEW: status='active' AND visibility='public' only. The only mem surface a public page may ever read. - Optional mem_write_log (mirror portfolio.api_write_log). Everything else already exists: supersede chains, confidence, source, FTS. No new tables needed.

- Agents: brain/query.py (already DB-first) + a keyed read on api.jbnx.io. Promoted to THE route. - Apps already on jbnx Supabase (projects portal, pw, star-room, mem UI): direct SQL/views filtered by consumer_tags. Same database as mem — zero new infra. - Apps on the fedm8 Supabase: never reach across projects at runtime. Public offer facts only, at build time or via api.jbnx.io with the key. - Static sites (fedm8.com, fedm8.org, jbnx.io pages): BUILD-TIME pull — a build script fetches the mem_public view (keyed) and renders values into the page. The live page has zero runtime dependency on mem; if mem is down, the site serves its last built values. A "data as of <timestamp>" stamp renders next to pulled numbers so staleness is visible, never silent. - Filters available to every consumer: entity, attribute, kind, consumer_tag, visibility, confidence >= stated, active-only, as-of date.

- New Edge Function mem-write on the jbnx project: validates the entity exists, confidence/kind/visibility enums, screens values against secret patterns (card/account/SSN/key shapes -> reject, pointer only), handles supersede (new active row + old row flipped + supersedes_id), stamps source + recorded_at, writes mem_write_log. JEV classification is embedded in this door (see the JEV section). - Agents migrate to it in Phase 1; the raw SQL route becomes break-glass only. - Local facts.jsonl becomes a GENERATED mirror: a nightly job re-exports it FROM the DB (one-way). Hand-appending stops being a write path — killing the inventory #2 drift. - Conflicts: flag, never overwrite; user corrections supersede with provenance.

Stack costs: one mem entity per service (suno, apiframe, resend, ...) with facts monthly_cost, purpose, plan. The /trust/f ledger block and the fvf costs view are both generated from the same tagged rows. Change Suno's price once in mem -> both pages show it after their next build. That is the whole vision in one example. The pilot's rendered proof is tracker task BRN-13.

Phase 0 — Mem plumbing. Schema additions + mem_public view + nightly one-way jsonl mirror. Verification: view returns only public active rows; jsonl-vs-DB diff = 0. Rollback: drop view/columns (additive only). Effort S / Risk Low. (BRN-01..07) Phase 1 — One write door + costs pilot. mem-write function; stack costs become mem entities; /trust/f ledger + fvf costs generated from mem. Verification: change a price in mem -> rebuild -> both pages show the new number (rendered check). Rollback: previous generated HTML from git. Effort M / Risk Low-Med. (BRN-08..13) Phase 2 — Canon (W4L + Kaylee). Voice IDs/settings/locks + character canon into mem (tags w4l-canon, kaylee-canon); bible + /w4l/c pages + design page generated from mem. Verification: a voice swap = one supersede in mem -> regenerated pages match everywhere (spot-render 3 pages). Rollback: regenerate from previous mem state (the supersede chain is the history). Effort M / Risk Med. (BRN-14..18) Phase 3 — Trackers tell one story. Formation dataset in mem feeding BOTH /trust/f pages; /trust/p generated nightly from portfolio.tasks (its true source). Verification: both formation pages agree to the item; /trust/p shows a fresh as-of date. Rollback: static snapshots kept in git. Effort M / Risk Med. (BRN-19..21) Phase 4 — FedM8 offer facts. Prices, grant model, launch dates, office address as visibility='public' mem rows, consumed at build time by fedm8.com + fedm8.org. Verification: edit one offer fact in mem -> both sites update on rebuild; AUD-A contradiction class closed for those fields. Rollback: git revert of generated pages. Effort M / Risk Med. (BRN-22..25) Phase 5 — Agents + finance views. brain-extract writes via mem-write; finance docs generated from mem plan facts + a live Plaid section; commitments land in mem as kind='deadline' with email-index source IDs. Verification: a new commitment email -> mem row within the hour, cited source; finance overview shows its generation stamp. Rollback: docs are views — regenerate anytime. Effort M / Risk Low. (BRN-26..29)

- Credential values, API keys, passwords (pointers only — existing rule). - The pw-vault's encrypted entries and any password material. - FedM8 member PII and VerifyPass verification records (app DB + its RLS; mem holds flow pointers/summaries only). - Live session/turn state (star-room, portal sessions, claims). - Raw email bodies and the email index (a derived store; mem gets the extracted commitments, not the corpus). - Payment instruments and full account numbers (the Piney Grove hold-back is the standing example: local-only until sealed via api.jbnx.io). - Health-record detail beyond the sourced summaries already directed into mem — and those stay sealed-pattern, never public.

- Availability: the design deliberately keeps mem OUT of every public page's runtime path (build-time pull + last-built values). The dependency lands on builds and agents, not visitors. (Named exception, boss-directed Nov 10: the tracker pages themselves render mem at request time — they are the boss's own review surface, and they fail honest rather than stale.) - Latency: mem reads are one Supabase query; agents already pay it via query.py. Build-time pulls add seconds to builds, nothing to page loads. - Mis-tagging is the big new risk: a private fact tagged public would publish. Mitigations: default private, public requires an explicit tag at write time, mem-write rejects secret-shaped values, and Phase 0 includes a one-time human review of everything proposed for the public view (BRN-05). - Single point of compromise: one store = one target. Mitigations: RLS stays on with no anon policies (current state), writes only via the keyed function, write log audited. - Not everything becomes dynamic: legal pages, RFC texts, and signed documents are DOCUMENTS — mem holds their pointers and status; their text stays versioned documents (in projects), by design.

- The tracker stores NOTHING of its own. No mem_projects/mem_tasks side tables — ever. - Projects and tasks live IN mem: projects as mem_entities, tasks as mem_entities, their state (status, phase, order, claimed_by, started_at, completed_at) as mem_facts, membership as mem_relations. - The tracker pages (mem.jbnx.io/project, jbnx.io/p) are PURE VIEWS that pull from mem at request time. - Multi-agent safe by design: an agent claims a task by writing claim facts (claimed_by + started_at) into mem; completion writes completed_at + status facts. Several agents can work the same tracker concurrently with no second store. - Any middle layer (rollup view, read API, cache) may only accelerate fetching from mem — it never becomes a second copy or source. This page is the living proof: everything on it, including this plan, is rendered from mem rows.

- Mem itself must be configured so ANY AI finds things quickly and easily — not just the tracker. - Facts are stored logically: typed facts about entities, with kind, tags, source, and status on the row. - Indexed on the paths AI actually searches: entity, kind, tag, status, plus full-text search (FTS already exists) — lookups never scan the whole store. - One query door for all AI: brain/query.py (DB-first) and the keyed api.jbnx.io read. - The hard access rules for mem live IN mem itself as canon/rulebook facts that agents read first (next section).

The rules for accessing mem are themselves stored IN mem as canon facts, so every AI reads the same rulebook from the same place: entity 'mem-rulebook', facts rulebook/rule-1..8 (seeded Nov 10, 2026). In brief: 1. Single source — mem is primary; local files are cache. Adding anything anywhere means adding it to mem too. 2. One write door — mem-write validates every write; raw SQL is break-glass only. 3. No secrets in mem, ever — name + location pointers only. 4. Corrections supersede, never overwrite; conflicts are flagged, never silently resolved. 5. Sources required — every fact carries source + source_date + confidence; query the brain before asking the boss. 6. Tracker stores nothing — tasks are entities/facts/relations; pages are views. 7. Claims are facts — claimed_by/started_at/completed_at on the task entity. 8. Read fast, read first — indexes + kind/tag discipline; middle layers only accelerate reads. When the Phase 0 columns land, these facts get kind='canon' + consumer tag 'rulebook' (BRN-02/03).

JEV (TypeSafe, via the custom.typesafe connector) is the estate's decision API: classifications, choices, probabilities, scores. It returns verdicts only — it never writes text and never authorizes anything. TODAY'S GAP (named Nov 10): JEV classification/conflict-checking runs ONLY on email-extract writes (the hourly brain-extract classifies mined facts before they land in mem). Every other write path — agents writing facts directly — gets NO JEV pass. THE FIX (Phase 1, task BRN-08): embed JEV inside the mem-write door, so EVERY write from any source gets the same classification (kind/tag assignment checks) and conflict check (does this contradict an active fact?) before it lands. Conflicts are flagged for decision, never auto-resolved — the existing brain rule. The write door decides and writes; JEV only advises.

1. Public visibility tier + mem_public view: GO. Accepted recommendation: YES — those numbers are already public on /trust/f today; the view only ever exposes rows explicitly tagged public, and Phase 0 includes a review of the initial tag set before anything renders from it. 2. One write door (mem-write as the only agent write path; SQL route break-glass): GO. Accepted recommendation: YES — it is what makes provenance, secret-screening, and supersede discipline enforceable instead of conventional. Phased in at Phase 1 so nothing breaks mid-flight. (Design updated Nov 10: JEV classification embedded in the door.) 3. Boundary confirmed: single source = knowledge only; transactional app data stays in app DBs, mem holds pointers/summaries: GO (CONFIRM). Accepted recommendation: CONFIRM — the alternative (mem as the literal database for live apps) would put member PII in the knowledge store and break working apps' data models for no gain. Recorded as tracker tasks BRN-31, BRN-32, BRN-33 (status: done).