CAF/DIE Roadmap v0 Pack

Four layers, one backlog, three audience views. Sponsor view reads L0+L1 (milestones + money). Spoke-owner view reads L1+L2 (seams + contracts). MLE bench view reads L3 (Jira). Built 2026-07-06 from founder's answers (audience = plural, "we are building this plane as we fly"; format = high-level → Jira; seams thesis accepted). Companion analysis: [[2026-07-06-die-fabric-hub-spoke-map-and-roadmap-implications]].

Fixed anchors honored (source: founder iMessage 2026-07-06 ~8:53am, his words): "Anderson needs the Snowflake site by the end of the year, but the earlier it is developed the earlier the money is released" · "we are already selling and demoing 321 Go backed by CAF to clients. We already have the site deployed on client infra for two clients" · KB4 onsite Jul 15. The live 321GO/CAF client lane must stay green throughout.

DECISION NEEDED (blocks work in this pack — answer these first)

1. Person-weeks ruling (impl_low/impl_high unit) — blocks ticket 2.3.
2. Vertex demo (book it) — blocks Lane D's NOW column entirely.
3. Troy = DIE owner? ("I think" was the phrasing) — determines who L1 circulates to as sponsor.

L0 — Vision one-pager (the story for every audience)

North star. phData's Intelligence Platform Framework delivers agentic value the same way every time: a client request enters through Assess (CAF/321GO), becomes a governed use-case portfolio with a typed Build Manifest, flows to Data (DCA) for implementation, is gated by Govern, measured by Evals, and every reusable capability lands in the Registry — with all five spokes reading and writing one Governed Knowledge Graph (the Fabric). Nothing moves without a ticket; every artifact carries provenance; the platform compounds because today's engagement is tomorrow's context.

Why phData wins with this shape (the three differentiators):

1. Typed contracts at every seam. Handoffs are schemas with validators, not demos with hardcoded bits. (Proof: the CAF→Catalog Build Manifest with X1–X8 cross-checks, fail-loud ingest, already running.)
2. Hexagonal ports. Every deployment target — AWS, Snowflake, client env — is an adapter behind the same port set. No fork per client, no vendor-camp loser.
3. Evals built into manufacture. Skills and assessments ship with lift-over-baseline evidence, not vibes. (Proof: execution-eval station, per-fixture lift, regression re-runs.)

Proof point already live: 321GO backed by CAF is selling now, deployed on client infra twice (founder's own report, iMessage 2026-07-06 — "we are building this plane as we fly"). The roadmap's job is to make that flying plane's trajectory legible — and protect it while the platform grows underneath it. Honest caveat the founder himself named: parts of the current handoff plumbing were hardcoded until this month's typed-manifest work; "deployed" ≠ "hardened."

PM thesis: the platform IS its seams. Spokes have owners; the seams are where value crosses and where nobody is accountable today. This roadmap assigns every seam a contract, an owner, and a date.

L1 — Now / Next / Later, organized by seam (the strategic roadmap)

Reading rule: NOW column = committed and resourced. NEXT = sequenced, waiting on a NOW output. LATER = directional, revisit at each roadmap review. Cadence rec: review L1 biweekly with spoke owners, monthly with sponsors.

L2 — Epics (the NOW column, with acceptance criteria)

EPIC 1 — Fabric v0 spec (Lane A). Outcome: one written port set every spoke can implement against. Acceptance: spec covers store layout · ticket/envelope contract · menu/discovery · provenance + snapshot rules · close-out; filesystem reference implementation cited as conformance example; Snowflake + Neptune backend sketches included; reviewed by Murray, Anderson-side, and Troy with written comments resolved.

EPIC 2 — CAF→DCA contract (Lane B). Outcome: Murray's DSA/DPA consumes CAF output through a validated schema instead of an implicit handoff. Acceptance: manifest schema + validator packaged standalone; DSA maps manifest fields to its discovery/build inputs; one end-to-end run (assessment → manifest → DSA discovery → model stub) passes validation both sides.

EPIC 3 — Snowflake-native site path (Lane C). Outcome: the 321GO/marketplace site runs Snowflake-native (SPCS), reading manifests from the Snowflake Fabric backend — the artifact that releases Anderson's money. Acceptance: data-port Snowflake adapter production-grade with tests; manifest landing path (stage/table + validated ingest with schema-drift test) live; SPCS deploy runbook executed once end-to-end.

EPIC 4 — Jira as the bench's rail (Lane E). Outcome: the MLE dozen pulls clear, self-contained work items; founder queues objectives instead of narrating tasks. Acceptance: Jira ticket template mirrors the ticket contract (order · acceptance criteria · typed context pointers); definition-of-ready = the Gate-A checklist; this pack's tickets loaded and at least 3 pulled by MLEs without founder clarification round-trips.

Pre-mortem — what would make this roadmap wrong (read before circulating)

• SPCS egress / client-admin approval can sink Epic 3's deployment shape at specific clients — the hex matrix already flags this as the hurdle the founder predicted. Mitigation is the hex design itself: the site must degrade to the filesystem/stage adapters, so no single runtime approval blocks the EOY money.
• The hub gets claimed de facto. Murray's Neptune graph is "a weekend project away." If a running hub ships before the Fabric spec circulates, the spec becomes commentary. This is why Epic 1 is NOW, not NEXT — and why 1.4 frames Neptune as the AWS adapter rather than a rival.
• Squadron Data urgency compresses everything. James's competitive framing means sponsors may force demo-speed over contract-quality. The SLA lane vs platform-build tension the founder named is the standing risk; the L1 lanes are the argument for holding both.
• Todd/Vincent dynamics. Todd reports directly to Vincent and the PM split is still TBD. If the split lands wrong, "front-end PM" can drift into owning the roadmap surface. Mitigation: circulate L1 jointly with Todd (3.4 makes him a co-owner of a lane early).
• Falsification condition: if the L1 circulation gets no substantive response from at least two spoke owners by the stated comment deadline, OR the vertex demo shows genuine build-time-eval overlap (not a complementary run-time plane), the seam-shaped framing is not landing — revisit the shape with Troy rather than pushing harder.

L3 — Jira-ready tickets (first load, 15)

Format per ticket: Order (what) · AC (done means) · Context (pointers) · size S/M/L. Repo paths below are the private-workspace names; adjust to phData repo names at load time.

Epic 1 — Fabric v0 spec

• 1.1 Draft FABRIC-SPEC v0 (M). Order: genericize the existing cellar contract into a DIE-vocabulary spec: store layout, envelope/ticket, menus/discovery, provenance/snapshots, close-out scan. AC: all five sections + conformance rules; no brigade-internal jargon unexplained. Context: CELLAR-SPEC v2, TICKET-CONTRACT, MENU-SPEC, RAIL-SPEC (skill-agent-brigade plugin).
• 1.2 Conformance checklist + reference implementation appendix (S). Order: "what makes a store a Fabric backend" checklist; cite the running filesystem implementation per item. AC: a new backend team could self-assess from it.
• 1.3 Snowflake backend design note (M). Order: map each port to Snowflake objects (stage / VARIANT tables + typed spine / Cortex Search for retrieval). AC: object-level mapping table + open questions list. Context: 2026-06-15 catalog ERD decisions; RAIL-SPEC Snowflake adapter sketch.
• 1.4 Neptune adapter working session with Murray (S, coordination). Order: map his existing AWS knowledge graph to the port set; document fits and gaps. AC: filled mapping table co-signed by Murray. (Tone: his graph is the AWS adapter — remix and credit, not rivalry.)

Epic 2 — CAF→DCA contract

• 2.1 Package the Build Manifest contract for DCA (S). Order: schema v1.1 + standalone validator + example manifest + README as a consumable artifact. AC: Murray's team validates the example without help. Context: frontend schemas/build-manifest.schema.json, scripts/validate-manifest.py.
• 2.2 DSA ingest spike (M, Murray's team + founder). Order: DSA reads a manifest, maps fields → discovery targets/build inputs. AC: field-mapping doc + spike branch demoed.
• 2.3 X-battery delivery-fields extension (S). Order: extend cross-checks to the delivery-view fields DCA consumes (blocked ruling: impl_low/impl_high unit = person-weeks — needs founder decision first). AC: new rules + tests green.
• 2.4 E2E seam demo (L, joint). Order: live assessment → manifest → DSA discovery on a sample source → dbt model stub, validation passing both sides. AC: recorded run + written gaps list. (This is the sponsor-visible milestone.)

Epic 3 — Snowflake-native site

• 3.1 Harden the data-port Snowflake adapter (M). Order: production-grade errors, missing-ranges degradation paths, tests. AC: adapter test suite green; degradation behavior matches the cellar adapter's. Context: frontend lib/data-port.ts, MARKETPLACE.md matrix.
• 3.2 Manifest landing path in Snowflake (M). Order: port the validated ingest (fail-loud, schema-drift test) to stage/table landing. AC: invalid manifest rejected with named violations; drift test wired to the canonical schema.
• 3.3 SPCS deployment runbook (M). Order: close the MARKETPLACE.md SPCS gaps; execute once end-to-end. AC: a second engineer can deploy from the runbook.
• 3.4 UI parity groom with Todd (S, founder+Todd). Order: walk current CAF design vs site; produce a prioritized parity backlog. AC: ranked list in Jira, split PM-owner per item.

Epic 4 — Jira as rail

• 4.1 Jira template ↔ ticket-contract mapping (S). Order: envelope fields → Jira fields; Gate-A checklist as definition-of-ready. AC: template live; one sample ticket passes DoR review.
• 4.2 Jira backend for the rail adapter (M/L). Order: enqueue/pull/append/ack against the Jira API inside the canon rail_adapter (vendored-from-canon pattern holds). AC: adapter tests green; one ticket driven Jira→brigade→close-out. Note: the hex matrix left Jira-as-rail as an open question pending a fidelity stress test (work-log/markup fidelity in Jira fields) — this ticket IS that stress test; timebox the spike before committing the backend.
• 4.3 Single-UC refinement path (M). Order: finish UC-as-ticket so one use case can be re-run without re-running half-CAF (inner-rail design exists; close the refinement entry point). AC: append context → re-enqueue one UC → re-merged manifest, invariants enforced.

How to use this pack (founder's next three actions)

1. Circulate L1 (just the table + reading rule) to Troy, Murray, Anderson-side, Todd — "this is the shape; comments by Friday." It forces the audience question to answer itself: whoever responds is your roadmap audience. (Reversibility note: this and #3 spend political capital — once circulated, you own the seam thesis publicly. That's the point, but it's a one-way door; edit L1 to taste before sending.)
2. Stand up Epic 4.1 first (an afternoon): the bench can't pull anything until Jira speaks ticket-contract.
3. Hand 2.1 to Murray personally — it's a gift, not a review. The seam thesis lands better as delivered value than as a slide.

(The three blocked founder decisions are at the top of this pack, not buried here.)

Related: [[2026-07-05-caf-technical-pm-role-framing-and-roadmap-kit]] · [[2026-07-06-die-fabric-hub-spoke-map-and-roadmap-implications]] · [[2026-07-03-hex-deployment-matrix]] · [[2026-07-01-caf-ecosystem-map-and-brigade-restructure-read]]