LATTICE Platform — Agentic Development Epic (v0.2, for decomposition)

Unit type: Epic Epic: lattice-platform-development Epic status: Decomposed into phase plans (2026-09-22). Phase 0 and Phase 1 are ready to execute at full slice detail. Phases 2–4 are rolling-wave placeholders per §0.5, expanded at P1.11.3/P2.11.4/P3.6.4 respectively. Epic review: Deferred until all phase plans and acceptance tests are finalized

Purpose of this document. A dependency-ordered, slice-by-slice development epic that defines the scope, milestones, tracks, and hard orderings for the LATTICE platform delivery. This epic has been decomposed into individual phase plans per the Epic Decomposition model in copilot-instructions. Each plan is authored, reviewed, and accepted separately before its implementation begins. The final epic review will be created only after all phase plans are complete and their acceptance tests pass.

Decomposition index:

Each phase plan cross-references its Part below for slice-level detail rather than duplicating it, and adds the docs/architecture, README, and solution-design-specification.md obligations the epic’s own slice tables name but do not tabulate.

Governing model. Epic decomposition, phase plans, and slice validation follow the Epic Decomposition model in copilot-instructions. See that document for the standard approach to units of work, validation packs, traceability, and review gates.

Source of truth for scope. docs/architecutre/Architecture Review.md (G-nn gaps, C-nn components, A-nn decisions), plus the three existing design documents it critiques. Every slice below carries traceability IDs back to those, recorded in docs/traceability/matrix.csv.

Two structural commitments this plan makes, which you must ratify first:

1. The review’s Addendum 1 (A74, graph-primary) and Addendum 2 (A75, three-tier store SPI) are accepted. This changes Phase 0 fundamentally — it is not “add a Postgres outbox and carry on”, it is “establish the graph as system of record and reduce the relational realm to a disposable coordination store”. If you do not accept A74, stop and tell me; roughly 40% of this plan reorders.
2. Nothing writes durable data until the Phase 0 exit gate passes. The irreversible decisions (A82, which superseded A51, and A54, A63, A65, A67, A68, A74) shape every triple the system will ever write. We build a walking skeleton with volatile stores early (to unlock UI/CI infrastructure), but no persistent dataset is created until the identity, provenance, and temporal conventions are ratified and TCK-enforced.

v0.2 topology and documentation-governance override

This v0.2 plan is amended for repository topology and implementation-document governance by ADR-A77 and the Repository Topology and Documentation Governance Plan. Where this document’s Part 1, P0.1, P0.2, P0.3, or developer-document references conflict with that decision and plan, ADR-A77 controls.

The repository retains mise as the sole orchestration entry point and retains Maven, Yarn 4, Python project tooling, and Mix as dependency authorities. The relocation affects semantic and documentation ownership only. It does not change ontology namespace IRIs, application names, or runtime component ownership.

Before any implementation slice in this plan begins, the repository-topology-a77 unit must be accepted. Its current state is recorded in Repository Topology A77 Status, and its human decision request is Repository Topology A77 Review.

Part 0 — Plan mechanics and validation model

0.1 Note: Units of work hierarchy

The hierarchy of units (Epic → Phase → Slice → Milestone) and their validation model are now defined in the copilot-instructions Epic Decomposition section. See that document for the authoritative definitions and required validation pack structure. This section retains the specific hierarchy for the LATTICE platform epic only.

Slice sizing rule. If a slice’s Validation Pack contains more than ~15 test cases, or touches more than two modules, split it. If it contains fewer than 3, merge it. Skeleton slices are exempt (they contain 1 test: the build smokes).

0.2 Slice validation model

The mandatory shape of every slice, validation pack requirements, and human validation gate protocol are defined in the copilot-instructions Epic Decomposition section. See that document for the authoritative requirements.

0.3 Test taxonomy (referenced as L0–L8 throughout)

Non-weakening rule. No slice may delete, skip, @Disabled, or loosen a test from a previous slice without an ADR-grade justification recorded in the VP and countersigned at the gate.

0.4 Guardrails the agents must operate under (enforced, not advisory)

0.5 Rolling-wave detail

Phase 0 and Phase 1 are specified at slice granularity below and are ready to execute. Phases 2–4 are specified at slice granularity but with lighter test enumeration; each is expanded to full VP-level detail in the last two slices of the preceding phase (an explicit planning slice). This is deliberate: Phase 2’s ingestion design will be better informed by what Phase 1 learns about the store SPI.

Part 1 — Target module topology

Agreeing this early prevents the agents from inventing five layouts.

contracts/                     # normative JSON Schema + OpenAPI; source of all generated types
  events/ ontology/surface/ mork/ pack/ plan/ projection/ query/ lineage/ openapi/
ontology/                      # existing layers, unchanged in role
  ontology/foundation/ ontology/vocabulary/ ontology/quantification/ ontology/party/ ontology/eligibility/ ontology/instrument/ ontology/behaviour/
  platform/                    # NEW: lattice: namespace (authority, commitSeq, lifecycle, provenance)
  ontology/governance/shapes/           # NEW content: authority + provenance governance shapes
mork/
platform/
  lattice-bom/
  canonical-hash/              # C-11  (+ CLI)
  graph-spi/                   # A75 Core + Extended interfaces, Capabilities, CommitMetadata
  graph-spi-tck/               # conformance + benchmark kit
  graph-adapter-tdb2/          # reference, in-process
  graph-adapter-fuseki/        # reference, remote
  coordination-spi/            # leases, sequences, idempotency, counters, outbox
  coordination-h2/             # embedded default (single node, no Postgres)
  coordination-postgres/       # multi-node option
  semantic-policy/             # existing; extended Principal (A66)
  platform-outbox/             # existing; re-based on commit-marker + coordination
  partitioned-queue-spi/       # A59 abstraction
  partitioned-queue-rabbit/  partitioned-queue-pg/
  surface-workflow/            # existing; re-based graph-primary
  release-integration/         # existing; ledger → graph
  mork-review/                 # snapshots + decision nodes (graph)
  governance-ledger/           # graph, hash-chained
  tenancy/                     # C-17
  pack-builder/                # C-01
  activation-controller/        # C-02
  change-feed/                 # C-08
  reasoning-validation/        # C-13
  plan-ir/                     # shared IR types (C-04/C-05 boundary)
  ingestion-gateway/           # C-04
  query-plane/                 # C-12
  lineage/                     # C-19
  metering/                    # C-16
  push-gateway/                # C-18
  feedback-router/             # C-15
  projection-engine/           # C-07 (+ sink adapters)
  behaviour-engine/            # C-09
  writeback/                   # C-10
  runtime-host/                # single artifact, LATTICE_ROLE=control|edge|projection|behaviour
  testkit/                     # harnesses, fixtures, compose orchestration helpers
  synth/                       # synthetic data generator (CLI)
workers/                       # Python
  lattice_workers/             # existing
  mapping_plan_compiler/       # C-05 design-time
  content_pipeline/            # C-06
  agent_orchestrator/          # C-14
apps/
  surface-studio/ mork-bench/ ops-console/
packages/
  ui-kit/ client-ts/
clients/
  client-java/ client-python/
deployment/
  compose/ images/ seeds/
docs/
  architecture/decisions/ (ADRs, canonical location per copilot-instructions — never `docs/adr/`)
  developer/{sketches,plans,status,validation,review}/ (per-unit documentation lifecycle)
  traceability/ (existing)
  operator/ (existing — runbooks referenced from P3.5.3 etc. land here unless a phase plan says otherwise)

Part 2 — Epic map and dependency DAG

Dependency DAG (coarse)

T-DEC ──► T-ONT ──┐
   │              ├──► T-HASH ──► T-STORE ──► T-GPM ──► T-DEP ──► T-ING ──► T-RUN
   ├──► T-BUILD ──┤                  │           │         │         │
   │              └──► T-ID ──► T-HOST ──► T-UX   │         ├──► T-QRY┤
   └──► T-MSG ──────────────────────────────────► │         └──► T-FB ┘
        T-DATA ──► (feeds every integration level from M0 onward)
        T-SEC  ──► (adds L8 suites from P0.5 onward, never a trailing phase)

Hard orderings you cannot violate:

• T-HASH before T-STORE write paths (hashes are in CommitMetadata and in revision IRIs).
• T-ONT platform vocabulary before T-GPM (the graph form of a revision needs terms to exist).
• T-STORE Core tier + TCK before any durable write anywhere.
• C-08 change feed before C-07; C-07 reconciling cleanly before C-09 (review §9: a behaviour engine over a silently-corrupt projection is the worst failure mode).
• C-05 before C-04 runtime interpretation and before C-06 stage 6.
• C-19 provenance conventions before any durable A-Box write (A65).
• C-11 before pack determinism, idempotency digests, projection invalidation.

Part 3 — Milestones

Part 4 — PHASE 0: Decisions and non-retrofittable foundations

Decomposed into phase-0-plan.md / phase-0-status.md / phase-0-sketch.md. This Part remains the authoritative slice-level detail the phase plan references; it is not duplicated there.

Phase goal. Make every irreversible decision, ratify it as an ADR, encode it as a machine-checked invariant, and stand up the build/test/deploy machinery — while proving the whole chain works end to end on a volatile stack (M0).

Phase exit gate (hard). No slice in Phase 1+ starts until: all Phase 0 ADRs are ratified; M0 and M1 pass; docs/traceability/matrix.csv has zero untested claimed requirements; data-architecture.md has been rewritten for A74 and signed off.

Persistence-pattern coherence (optional, non-blocking — completes the “Phase 0.2–0.4 Integration” item from COORDINATION_REORG_HANDOFF.md). ontology/persistence and tools/persistence (Slice 2 of rdf-sparql-patterns-phase, already complete) formalise the same K/O/C/T patterns this phase’s foundations independently establish under different names. Phase 0 does not depend on tools/persistence — the compiler is Phase 2 machinery, and nothing in P0.1–P0.9 requires it to exist — but the vocabulary and primitives minted here should be nameable in dal: terms from day one, so Phase 1–2 never has to reconcile two competing stories for the same concept. Concretely:

• Pattern C (CAS) ↔ dal:ConcurrencyProfile/dal:ConcurrencyStrategy (dal:ProvidedConcurrency, dal:Optimistic, dal:AppendOnly, dal:LockingConcurrency). The SPI’s own conditionalWrite(Precondition, WriteUnit) and WriteResult.guardSatisfied (P0.5.2, TCK at P0.5.6) is the mechanism dal:Optimistic ultimately compiles to — cross-referenced below so nothing needs renaming when Phase 2 wires the compiler to it.
• Pattern T (named-graph-per-batch / provenance) ↔ dal:MetaTopologyProfile (dal:SharedSharded, dal:PerAggregate) and dal:ReceiptModel (dal:ReceiptOnly, dal:PatchLog, dal:SnapshotPerRevision). ADR-A65’s provenance-homogeneous, one-cause-per-graph convention (P0.1.5, shaped at P0.3.6) is the same idea dal:’s meta-topology and receipt-model dimensions assume — cross-referenced below so a future dal: value never silently contradicts A65.
• Pattern K (uniqueness) ↔ dal:UniquenessConstraint (dal:keyProperty, dal:scopeProperty, dal:normalizePipeline, dal:onViolation, dal:minEnforcementLevel). IRI and Identity Patterns and ADR-A82 make the selected minting and claim strategy explicit per resource role. A profile can require structural derivation, a claim registry, or an external allocator, rather than assuming one Core-tier identity policy everywhere.
• Pattern O (dense ordering) ↔ dal:OrderingProfile/dal:OrderingGrain (dal:CommitGrain, dal:EventGrain) and dal:DatasetTierModel. The CommitSequence primitive and its TCK ordering suite (P0.5.7), and the canonicalisation profile’s ordered-collection indexing (P0.4.4), are cross-referenced below against the matching dal: terms.

A new slice, P0.3.9, produces the single artefact proving these four alignments hold: a mapping table, not new code. This closes the handoff’s optional item by adding documentation cross-references and one new guardrail (G11, §0.4) — it introduces no new Phase 0 dependency or scope beyond that.

P0.1 — Decision pack (T-DEC)

Decisions are slices here, because agents can draft ADRs and humans validate them. Each slice = draft ADR + affected normative doc edits + (where applicable) an executable consequence.

Validation note for the humans: P0.1 slices produce documents, so Step 4 (adversarial probe) becomes “name one scenario the decision does not cover”. Expect to reject and re-run at least P0.1.1 and P0.1.3.

P0.2 — Repo, build, CI, codegen (T-BUILD)

P0.3 — Platform ontology & governance shapes (T-ONT)

P0.4 — Canonicalisation & hash identity, C-11 (T-HASH)

This is the single most load-bearing library in the system. Slice it finely.

Human validation focus for P0.4: ask the agent to produce a table of “these two graphs are semantically identical and hash equal” vs “these two look similar but must hash differently”. If that table is thin, the suite is thin.

P0.5 — Graph store SPI, TCK, adapters, C-03/A75 (T-STORE)

P0.6 — Coordination realm (T-STORE)

P0.7 — Identity, policy, HTTP host, walking skeleton (T-ID, T-HOST) → M0

M0 gate. Browser → HTTP → domain → response, in compose, with one correlation ID traceable across services, plus a Playwright + axe smoke. Explicitly no durable data.

P0.8 — Messaging foundations (T-MSG)

P0.9 — Synthetic data and test data foundations (T-DATA)

P0.10 — Phase 1 planning slices

Part 5 — PHASE 1: Graph-primary core and the deployment plane

Decomposed into phase-1-plan.md / phase-1-status.md / phase-1-sketch.md. This Part remains the authoritative slice-level detail the phase plan references; it is not duplicated there.

Phase goal. Move all existing operational state into the graph; stand up tenancy, packs, activation, and the change feed; deliver the first operational-register UI. Milestones M2, M3.

P1.1 — Surface lifecycle → graph (T-GPM) → M2

P1.2 — Graph catalogue & lineage registry (T-GPM)

P1.3 — Change feed, C-08 (T-DEP)

P1.4 — Release ledger → graph (T-GPM)

P1.5 — MORK review snapshots & decisions → graph (T-GPM)

P1.6 — Governance ledger → graph (T-GPM)

P1.7 — Tenancy, C-17 (T-DEP)

P1.8 — Pack builder & registry, C-01 (T-DEP)

P1.9 — Activation controller, C-02 (T-DEP) → M3

P1.10 — Operations UX v1 (T-UX)

P1.11 — Phase 1 close-out

Part 6 — PHASE 2: Ingestion and query planes

Decomposed into phase-2-plan.md / phase-2-status.md / phase-2-sketch.md — a rolling-wave placeholder, per §0.5, full VP-level expansion scheduled at P1.11.3. This Part remains the authoritative slice-level detail until then.

Phase goal. Data gets in, questions get answered, lineage is provable. Milestones M4, M5, M6.

Sequencing rule restated: C-05 is the largest single piece of missing implementation and gates everything else here. Start it on day one of Phase 2 with the heaviest allocation, and run C-13 and C-12 foundations in parallel.

Persistence compiler integration (supersedes the earlier “ad hoc SPARQL” design). rdf-sparql-patterns-phase Slices 1–2 are complete: the ontology/persistence substrate and tools/persistence compiler (rdf-sparql-patterns-phase-plan.md, persistence-profile-substrate.md, rdf-sparql-patterns-guide.md) are available and tested (570 passing tests as of 2026-09-23; the compiler’s re-sync with the extended vocabulary is still in progress in persistence-compiler-iri-sync, and identity profiles, which P2.1.5 depends on, are resolved per resource role since its Slice 3). P2.1, P2.3, and P2.4 below are revised accordingly. The caller contract every step below relies on is documented once in tools/persistence/README.md, “Using the generated SPARQL directly”:

• P2.1 (mapping plan compiler, C-05) resolves, validates, and instantiates a dal:CompiledProfile for every write target as part of compile() (new slice P2.1.4a). This is a design-time step with no live-backend dependency (ADR-A78/A79); its output — a compiled profile graph plus instantiated SPARQL Update text that still carries its SPARQL variables and its Mustache request-time slots (}, }) — is the artefact P2.3 executes. No mapping hand-authors SPARQL.
• P2.3 (ingestion gateway, C-04) never constructs SPARQL at request time. Its assert step binds request-scoped parameters into the pre-instantiated templates from P2.1.4a (P2.3.1), and its commit step (P2.3.6) is the template selected by the target’s resolved concurrency/aggregate-boundary/receipt-model dimensions. This satisfies guardrail G5 (no string concatenation into SPARQL) for every profile-governed write without introducing the general-purpose Request Query Mapping library (Part 13, open question 11), which stays deferred pending A75 — C-04’s binding responsibility here is deliberately narrower than that library’s scope.
• P2.4 (query plane, C-12) reuses the same resolved profile on the read side (P2.4.1): ordering grain and receipt model shape the generated read query, keeping read and write semantics consistent by construction rather than by convention. Governed FROM/FROM NAMED scoping (P2.4.2) remains a separate, Principal-derived concern composed with this.

See docs/developer/INDEX.md for current status. The “Optional (but useful): Phase 0.2–0.4 Integration” step in COORDINATION_REORG_HANDOFF.md (walking-skeleton pattern adoption) is not part of this revision and remains open.

P2.1 — Mapping plan compiler, C-05 (T-ING, Python + shared IR)

P2.2 — Reasoning & validation, C-13 (T-RUN)

P2.3 — Ingestion gateway, C-04 (T-ING) → M4

P2.4 — Query & decision plane, C-12 (T-QRY) → M5

P2.4 — Query & decision plane, C-12 (T-QRY) → M5 (continued)

P2.5 — Lineage & provenance service, C-19 (T-QRY)

P2.6 — Metering & quota, C-16 (T-QRY)

P2.7 — Push / subscription gateway, C-18 (T-HOST)

P2.8 — Runtime feedback router, C-15 (T-FB)

P2.9 — Content ingestion pipeline, C-06 + agent orchestrator, C-14 (T-ING) → M6

Build C-14 first. Every LLM call in C-06 must go through it, so that model pinning, budgets, caching, egress policy, and the audit record exist before the first completion is requested. Building C-06 first and retrofitting C-14 is how those controls end up partial.

P2.10 — Operational and task-register UX (T-UX)

P2.11 — Phase 2 close-out

Part 7 — PHASE 3: Operation plane

Decomposed into phase-3-plan.md / phase-3-status.md / phase-3-sketch.md — a rolling-wave placeholder, per §0.5, full VP-level expansion scheduled at P2.11.4. This Part remains the authoritative slice-level detail until then.

Phase goal. Projections stay fresh, tanks respond, values flow back. Milestones M7, M8, M9.

Hard gate: no C-09 slice starts until C-07 reconciliation (P3.1.7) has been green for a full week of nightly runs against the synthetic load, including an injected-divergence scenario. A behaviour engine over a silently-corrupt projection produces wrong decisions that look right.

P3.1 — Projection maintenance engine, C-07 (T-RUN) → M7

P3.2 — Behaviour execution engine, C-09 (T-RUN) → M8

P3.3 — Write-back / reverse projection, C-10 (T-RUN) → M9

P3.4 — Tank Inspector and runtime UX (T-UX)

P3.5 — Runtime availability posture and storage lifecycle

P3.6 — Phase 3 close-out

Part 8 — PHASE 4: Maturity

Decomposed into phase-4-plan.md / phase-4-status.md / phase-4-sketch.md — a placeholder, full expansion scheduled at P3.6.4. This Part remains the authoritative detail until then.

Deliberately lighter: each item is a sub-programme sized after Phase 3 measurement.

Part 9 — Continuous Epics (run across all phases, never a trailing phase)

These are not phases; they are standing obligations with per-phase slices.

Part 10 — Parallelisation plan

Assumes multiple agent teams working concurrently with one human validator per Epic (validators may hold two Epics).

Anti-pattern to avoid: parallelising C-07 and C-09 to “save time”. The review is explicit and the risk register agrees (R-03 likelihood High). Do not.

Part 11 — Risk-to-slice traceability

Every register risk must have a slice that owns its control, or it is unmitigated.

Part 12 — Phase gate checklists

Every phase gate requires all of:

1. All slice gates in the phase signed off in docs/validation/LOG.md.
2. Phase milestone demo executed by a human against a freshly built compose stack from a clean checkout.
3. docs/traceability/matrix.csv shows zero claimed-but-untested requirements for the phase’s G-nn/C-nn/A-nn set.
4. Every phase ADR ratified; every normative document delta merged.
5. L7 baselines recorded; no unexplained regression.
6. L8 suites for the phase’s threat controls green.
7. Non-weakening audit: diff the test inventory against the previous phase; any removed, skipped, or loosened test is accounted for in writing.
8. Cold-start test: clean machine → clone → one command → stack up → seeded → E2E green. If this takes more than 30 minutes of wall clock or more than one command, the DevEx debt is the gate blocker.

Part 13 — Open questions for you before we start

These genuinely change the plan and I do not want to assume answers.

Part 14 — Summary of the critical path

P0.1.1/3/4/5/6/8 (irreversible ADRs)
   └─► P0.3.3 (platform vocabulary)
         └─► P0.4.2–P0.4.5 (canonicalisation + hashes)
               └─► P0.5.2/5.7/5.8 (write surface, commit sequence, scoping)
                     └─► P0.5.4–P0.5.6 + P0.5.14 (TCK + benchmark)  ──► M1
                           └─► P1.2 (IRI/lineage) ─► P1.1 (lifecycle in graph) ──► M2
                                 └─► P1.3 (change feed)
                                       └─► P1.8 (pack) ─► P1.9 (activation) ──► M3
                                             └─► P2.1 (C-05 mapping compiler)   ◄── longest pole
                                                   └─► P2.3 (ingestion) ──► M4
                                                         └─► P2.4/P2.5 ──► M5
                                                               └─► P2.9 ──► M6
                                                                     └─► P3.1 (projections) ──► M7
                                                                           └─► P3.2 (tanks) ──► M8
                                                                                 └─► P3.3 ──► M9

Three things on this path deserve disproportionate attention: P0.4 (canonicalisation — everything downstream is wrong without it), P0.5.8 (scoping hostile suite — the existential security control), and P2.1 (the mapping plan compiler — the largest single piece of missing implementation, which gates Phases 2 and 3 entirely and should be resourced first and most heavily).