Roadmap: Current Position

AI Parsing (thorough) as a candidate milestone for A1-PH3 (Build-out):

`docs/audit-log-spec.md` at PH1 root is the v1.0 spec for the Daily Audit Log surface. The Audit Log implements the *"Audit transparency as a sovereignty primitive"* Candidate principle (in `docs/heuristics.md` Candidate section) — visibility into what the system has captured and processed is structural proof the user owns their digital cell. The spec was authored 14-05-2026 against PH1's m2b tasks 13–17, with m2c-dependent items revisited at m2c close.

A five-stage pipeline:

Joining the Remoir platform provisions a private virtual server — owned by, paid for by, and accessible only to the user — that is architecturally part of the user's cell, not part of Remoir's infrastructure. The VPS is where the user's processing happens: clustering models, narrative assembly, photo↔voice-memo linking, sync orchestration. Remoir defines the interface/contract ("send your curated narrative as Raw Input") and receives the result. Platform-as-a-service, with the private VPS integrated into the Remoir signup/setup flow itself — making Remoir a platform more than an app.

Phase 3 generalises the access model from "the app belongs to one family" to "the app belongs to many kinds of groups". This brief is conceptual with a small concrete schema seed. It picks up the `family_group` table that originally lived in `canonical-schema-brief.md` Section 8.1 and reframes it as the v1 instance of a broader idea.

Phase 4 turns the canonical layer into a discovery surface: when two groupings have memories mapped to the same canonical entity, the platform notices and (with consent) lets them connect. This brief is the schema-level home for the `discovery` and `shared_memory` tables that originally lived in `canonical-schema-brief.md` Section 8 (Sections 8.2 and 8.3 in the post-reconciliation numbering). The conceptual framing for cross-family discovery lives in `canonical-concepts-brief.md` Section 5; this brief assumes that material as background.

This document captures the conceptual design of the canonical layer — the shared, universal data layer that sits beneath individual families' private memories. It draws on two intellectual frameworks:

This brief is one of three sibling documents that together specify Phase 2:

This document translates the conceptual frameworks in `canonical-concepts-brief.md` into concrete table schemas. It is **provisional** — a design reference, not an implementation spec. The schemas will be refined as Phase 1 stabilizes and Phase 2 work begins.

This brief is conceptual, not schema-level. Phase 5 is far enough out that table shapes would be premature — the requirements are still moving and the scale precondition has not been met. The point of this document is to fix the *vocabulary*, the *principles*, and the *boundaries* of the editorial knowledge layer so that decisions made during Phases 1 through 4 don't accidentally close the door on it.

This is a **far-future, idea-park brief**. Phase 6 should only surface once the app has:

A1+'s canonical layer (object-model L3) is the structural pin: "Boet" is *this person*, "Sarah" is *that person*, regardless of how any individual transcript happened to render them. Source-language pinning at L2 makes today's spike convergence measurable — but it punts the deeper problem to the canonical layer:

A candidate stratification that introduces plates above the object layers. The current model has four layers inside one cell. The provisional idea: the layers sit *inside plates*, and the plate is the higher-order unit. Across arcs, the layer model within each plate may carry different layer numbers and a different internal structure than A1's L1–L4.

The plate model has no referent in A1. With a single cell, there is no Negotiation plate (no second cell to negotiate with), and the four-layer model is complete and sufficient for everything A1 needs. The plate restructure becomes relevant only when multi-cell architecture opens — the same trigger as the L5 brief.

The knowledge graph is Remoir’s confirmed structural backbone. Working definition (now in `docs/glossary.md`):

A candidate fifth layer in the object model. The current four layers all live *inside a single cell*:

L5 has no referent in A1 (Self-Contained Cell). There is no "between cells" when there is only one cell — incompatible-frame contestation is internal to a single user's view, and the existing object model already handles that (`docs/object-model-open-questions.md`, "Multi-cell contestation of social membership"). L5 becomes necessary *the moment multi-cell architecture exists* — the trigger is the first arc where two cells hold potentially incompatible L4 deliberate acts about the same substrate and the system is asked to surface, rather than merely store, the tension between them.

Re-confirmed and re-parked at A1-PH2 (28-05-2026). The Foundation infrastructure-rebuild scoping deliberately deferred calendar integration. It is technically cheap (~200 lines: OAuth, token refresh, two API calls — and PH1 already built the OAuth foundation) but architecturally premature: it loads enrichment with external ground truth, which is A1-PH3+ enrichment-design territory. Pulling it into Foundation would smuggle enrichment design into a phase whose job is proving the audio capture → store → enrich → review loop on a clean stack. The A1-PH2 forward-designed storage schema already reserves the `calendar_event` slot in its `source_type` discriminator, so a future phase populates an existing slot rather than re-solving the capture-schema question. See `project-management/decisions.md` (28-05-2026, A1-PH2 rebuild scope).

A monetization model for the canonical layer (shared collaborative substrate of world-data + person-data) that enables commercial third-party activity for enriching that layer, while preserving the layer as commons and structurally preventing the failure modes of Google/Facebook (surveillance economics) and LinkedIn (proprietary person-data extraction).

Surfaced 08-05-2026 in a brainstorm on expanding Remoir's raw data capture beyond the live Capture App. Original framing: *"capture everything now, make sense of it later"* via a Mac-as-automation-hub pipeline that nightly pulls all timestamped digital activity into Supabase. Three pieces of substance survived re-examination after the membrane principle hardened in subsequent brainstorms (10-05 sovereignty framing, 17-05 four-layer object model, 20-05 local-capture pipeline): the 12-source inventory itself, the Mac-as-puller-hub architecture for non-iPhone-native sources, and storage tiering for high-volume telemetry. The original "everything flows into `raw_inputs`" assumption was partially superseded by the 12-05-2026 Moment-as-anchor directional decision (inlined below).

External reference data — fraternity rosters, alumni lists, conference attendee lists, member directories — treated not as ad-hoc lookup tables but as a first-class feature of Remoir.

Two borrowable mechanics from Memory Tree's per-row pipeline.

When sensitive-mode is first implemented, a new ADR is required to decide between two architectural paths for sensitive captures: