ADR-001 — Community & Messaging architecture

Decided by adversarial design panel (data · build-vs-adapt · AI-native · simplicity + estate-scout), 2026-07-22. Brand-free — capability language only. Read top→down: who enters → what they see → the record it derives from → the AI moat → what we rent → what we defer.

Access plane — one door, one identity
One shell + design system
Every surface rendered from one component/token set. Tier-aware, choose-your-own-home.
One identity (IdP)
Self-hosted IdP; its stable subject id is the join key every object FKs to.
sub → member_sub
flows down to renders · carries member_sub + current tier
Derived read-models — projections over the log (droppable, rebuildable)
Boards view
Threaded, tagged, searchable.
DM / group threads
Per-conversation ordered.
Member directory
Tier-scoped listing.
Home-feed query
NOT a stored timeline — a query; tier evaluated at read (no downgrade leak).
derived from log (up) · append-only writes (down) derived-from ▲  ·  ▼ append-only writes
Source of truth — owned, by construction
Append-only conversation event log
The single system of record. Every post · message · RSVP · membership-change · AI-query is an immutable event. Edits/deletes are new events — history never rewritten.
event_id · conversation_id · seq (per-conv monotonic, store-assigned) · member_sub FK · tier_visibility (immutable) · type · payload
Tier check
A pure deterministic function applied before any ranking. reader.currentTier ≥ object.tier_visibility.
flows down to outbox — at-least-once, idempotent index writes
AI moat plane — owned (largely existing estate)
Outbox
Emits every write into the index. The AI home reads the index, never a surface's store → engine swap = repoint.
Permissioned index
The governed knowledge brain (estate). Content born chunkable + tier-tagged; retrieval filtered by the tier check.
Governed agents
Run via the agent-governance plane (estate). Read+write the index: curate, synthesize threads, "talk to the platform".
Required evals (an invariant with no eval is a wish)
P0 · Retrieval-permission tier-leak eval — fail-closed golden set (T0–T3 fixtures × must/must-not-return), on every model bump · prompt change · schema migration. Built before any agent reads a board.
P1 · Home-ranking regression + engagement proxy · P1 · per-flow prompt eval for each governed agent. Fixtures are source code under review.
Rented / borrowed — never the record
Rendering engine ⇠ log
A mature threading / full-text-search / moderation engine as a derived view fed from our log — IF the E4 spike proves it runs as a pure projection, presentation owned by our shell, our tier as sole authority. Else build boards custom.
Realtime transport ⇠ log
A borrowed AP, best-effort pipe for DM/message fan-out that resyncs from the log. Never the system of record.
Notifications
Async ("3 new replies") from the estate email platform's digest scaffolding — covers ~95% of realtime value at ~5% ops cost.
Deferred to post-v1 — substrate built now, sophistication later
Presence service
Green dots / typing. Soft-state; async notifications cover v1.
Ranking agent
Home ships as "Latest / Top this week" queries; agent-ranking is a repoint once the index exists.
Dedicated fleet
v1 on one box; split by workload only when the AI/live-event footprint demands.
Preserved dissent (do not resolve away)
Simplicity vs the moat: the ranking agent is deferred, but the cheap log/tier/index substrate is built from day one — because it is catastrophic to retrofit. If members never hit a firehose, the agent may never earn its place (a reversible bet).
"Don't build a database" & C-vs-custom: renting the rendering as a derived view only holds if we never let the engine's DB become the record. The rendering-engine choice is handed to the E4 spike; the log/tier/index spine is decided.