Publication Implementation Roadmap

The minimum sequence to stand up the Publication Model, ordered contract → generated JSON → validation → Lovable integration → automation → future-live. Each phase is independently shippable and gated by the pipeline. Nothing here builds the frontend; it builds the truth-side bridge Lovable consumes.

Design invariant: ship the contract and empty-but-valid feeds first, so Lovable can integrate against real (possibly awaiting) data on day one, then fill feeds behind a stable schema.

Phase 0 · Contract freeze (this deliverable)

Do: ratify these seven docs as the design contract. Author publication/schemas/*.schema.json for all feeds (envelope + per-feed, incl. canonical/spine, navigation, search-index) and the closed enums (status, feedClass, publicationClass, shape, entityType, spineRole, …). Output: JSON Schemas; agreed layout under content/editorial/, publication/, and reserved live/. Exit: Lovable and Claude both accept the schemas. No generators yet.

Phase 0b · Establish the Editorial Source Layer

Do: create content/editorial/** (Claude-owned) and migrate the authored copy currently living in presentation (PlatformHero.astro hero copy, story.astro chapters) into it — resolving the ownership inversion the review flagged (C-1). Author content/editorial/arrival.md, story/01…10, overview.md, gallery/flagship intros, captions.md. Output: the authored narrative has a truth-layer home. Exit: no editorial truth remains in presentation. Why here: Phases 2–3 generators read from this layer; it must exist first.

Phase 1 · Skeleton feeds (contract-first, empty-but-valid)

Do: emit every feed schema-valid and empty/awaiting — correct envelope (incl. feedClass/publicationClass/ shape), correct status, empty arrays, populated missing[]. Wire manifest.json, routes.json, navigation.json, and canonical/spine.json (all fully derivable from the graph + layer model today). Output: publication/** passing schema-valid, manifest-integrity, routes-resolve, render-safe, classes-valid, spine-single-source, navigation-single-source. Exit: Lovable loads the manifest + nav + spine and every destination renders its awaiting state, no crashes. Why first: unblocks Lovable integration immediately against a stable, safe contract.

Phase 2 · Live projections (Tier A/B, no new data)

Do: write the deterministic generators that project existing truth (all auto-publishable):

1. reference-library.json (thin graph index — not a copy) — highest coverage, lowest risk.
2. portfolio-gallery.json (capabilities + systems + edges; ventures awaiting).
3. architecture-gallery.json (Mermaid exhibits; canonical exhibit spineRef).
4. arrival.json (spineRef + architectural stats — reuse the homepage’s real numbers).
5. evidence-plates.json (harvest source citations from the estate).
6. search-index.json (index reference entities; keyword now, embeddingRef reserved).
7. living-platform.json snapshot (wrap health.json + current-state/roadmap/changelog). Output: seven live/buildable feeds; evidence-sourced, no-invented, stats-cross-check, search-single-source green. Exit: Reference Library, Portfolio Gallery, Architecture Gallery, Arrival, Search, and the Living-Platform snapshot render real data.

Phase 3 · Narrative feeds (Tier B, editorial + graph) — human-approved

Do: build the feeds that combine the editorial layer with sourced facts:

1. story.json — generate the 10 chapters from content/editorial/story/* (Phase 0b); bind each fact to an EvidenceRef; reference the spine.
2. flagship-experiences.json — generate the Website Assessment experience from its narrative capability page + content/editorial/flagship/* + evidence plates. Other flagships stay awaiting.
3. engineering-manual.json — project governance + operating-model pages. Output: Story, Flagship Experiences (1 live), Engineering Manual render real content; editorial-boundary green. Exit: the First-time and Executive journeys have full data end-to-end.

Phase 4 · Validation harness (make the gate real)

Do: implement the full acceptance-test suite (validation) as a runnable gate, plus the manual-review report at gate ⑦. Add CI so no publish bypasses it. Output: validate command + report; publish blocked on any red. Exit: every publish is provably evidence-first and render-safe.

Phase 5 · Lovable integration hardening

Do: (Lovable-side, tracked here for sequencing) Lovable pins manifest.json, renders each destination from its feed, and implements the awaiting/planned placeholder components. Claude provides fixture feeds (live + awaiting variants) for Lovable to test render-safety against. Output: the Lovable portal renders the full experience from published feeds. Exit: all 9 destinations render; awaiting/future states display correctly.

Phase 6 · Automation (with class-routed approval)

Do: wire triggers (estate/editorial change → regenerate affected feeds), integrity checks, and the publish step. Route publishing by publicationClass: auto-publishable feeds (reference/generated, no new claims) publish on trigger unattended (enabling scheduled publishing); claim-bearing/editorial feeds always stop for human approval. (Natural home of the future portfolio-portal-orchestrator.) Output: estate change → validated staged feeds → auto-publish (reference) / one-click approve (claim-bearing). Exit: the bridge maintains itself; humans approve only what bears claims.

Phase 7 · Awaiting feeds → live (Tier C, as sources land)

Do, per source as it becomes available (each needs an ADR):

• intelligence-products.json ← intelproducts pack-manifest export.
• FIP mechanics (finding, knowledge-asset, recommendation, asset, draft) ← FIP feeds when emitting. Promote each feed awaiting → live only when its real source exists. Never before. Exit: Intelligence Products and platform-mechanic feeds carry real data.

Phase 8 · Living Platform live layer (Tier D, last — the reserved live feed class)

Do: implement the live feed class (§8 model) under live/ — mutable, TTL-bound, unpinned — for live health, telemetry, and agent-driven updates (Hermes/orchestrator). The immutable publication/ contract is untouched; the reservation made at freeze means this needs no structural redesign. Remains future until built; the Phase-2 static snapshot serves until then. Exit: the Living Platform destination becomes genuinely live, alongside (never inside) the static contract.

Sequencing summary

Start now with Phase 0 → 1 → 2: contract + empty-valid feeds + the six zero-new-data projections. That gives Lovable a stable contract and real content for five of nine destinations without emitting a single invented fact.

Dependencies & non-goals

• Depends on: the existing build-graph.mjs, build-health.mjs, the route resolver, and the estate — all live.
• Non-goals (this track): building Lovable components, changing the estate’s meaning, emitting FIP data before the platform produces it, or promoting any awaiting/future feed to live without its source.