Unit type: Phase (of Epic lattice-platform-development)
Unit ID: phase-0
Promotes to: phase-0-plan.md
Status record: phase-0-status.md
Phase 0 is everything that cannot be safely retrofitted once a triple is durably written: identity policy, dataset topology, provenance conventions, bi-temporal design, PII/erasure, canonicalisation, and the store SPI’s Core write surface. The epic’s own framing (Part 4) states the exit gate as hard: nothing in Phase 1+ starts until every Phase 0 ADR is ratified and M0/M1 pass. That framing is sound and this decomposition does not revisit it — Phase 0’s boundary is the epic author’s boundary, not a new one drawn here.
What decomposition adds is not a new boundary, but the machinery a phase needs to be independently executable: its own plan and status file, an explicit inventory of the docs/architecture and README obligations buried across ~90 slices, and a delta plan for solution-design-specification.md, which Phase 0 will contradict or extend more than any other phase (it is the phase that replaces the SDS’s current single-writer-per-store, no-role-split, no-store-SPI picture with the graph-primary, role-profiled, three-tier-SPI one).
The full slice tables (P0.1 through P0.10) are not duplicated here. phase-0-plan.md points back to Part 4 of the epic as the authoritative slice-level scope, test taxonomy, and hard-ordering source. Duplicating ~90 rows into a second document would create two places that can drift; the plan cross-references instead, per the repository’s own “say it once” guidance.
Three mechanical corrections were made directly in the epic document because they are not architectural decisions, they are typos against already-established convention:
deploy/ → deployment/ (the root already exists under that name; copilot-instructions bans introducing a second top-level root without an ADR).make/just task runner → mise tasks (copilot-instructions: “mise is the only task-orchestration entry point unless ADR-A29 is superseded”; ADR-A29 is not superseded).docs/adr/ → docs/architecture/decisions/ (copilot-instructions explicitly forbids docs/adr/ references).Two things were found that are not mechanical and are not resolved here, because resolving them would be exactly the kind of unilateral design decision the Agentic Development Contract reserves for the human:
platform/graph-spi vs platform/semantic-dataset-spi. Part 1’s target topology names a new graph-spi/graph-adapter-tdb2/graph-adapter-fuseki family for the A75 three-tier SPI. platform/semantic-dataset-spi and platform/semantic-dataset-fuseki already exist and are the SPI the current solution-design-specification.md §4.1 describes. Nothing in the epic states whether P0.5 renames these in place, replaces them outright, or the two coexist during a migration window. P0.5.1 cannot start cleanly until this is answered — flagged as a pre-P0.5 decision point in phase-0-plan.md.apps/surface-studio/apps/mork-bench vs apps/surface-contract-studio/apps/mork-review-workbench. Part 1’s target topology uses shorter names than the apps that already exist and that P0.7.5’s walking skeleton explicitly reuses (“Studio calls it”). Whether this is a rename, a fresh pair of apps, or Part 1 simply using informal short names is not stated. Lower urgency than the SPI question (Phase 1’s P1.10 is the first slice that actually touches app naming), flagged the same way.