CAF/DIE Roadmap v1

Four layers, one backlog, three audience views. Sponsors read L0+L1 (milestones + money). Spoke owners read L1+L2 (seams + contracts). The MLE bench reads L3 (Jira-ready). v1 updates v0 (2026-07-06) for the brigade-house consolidation and the deployment decisions of 2026-07-07 — the delta log is at the bottom.

Fixed anchors: the Snowflake-native site is needed by end of year, and the earlier it ships the earlier the funding releases · 321GO backed by CAF is already selling and demoing, deployed on client infra for two clients — that live lane stays green throughout · KB4 onsite July 15.

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 and fail-loud ingest, running now.)
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. (Proof, new this week: the same marketplace site that runs locally deployed into Snowflake via App Runtime with changes confined to the adapter/config layer — no business-logic changes.)
3. Evals built into manufacture. Skills and assessments ship with lift-over-baseline evidence, not vibes. (Proof: the execution-eval station, per-fixture lift, regression re-runs.)

Proof points already live: 321GO backed by CAF is selling now, deployed on client infra twice. And the assessment machinery has now run two full engagements end-to-end inside a week — intake → research → assessment → committed manifest → rendered site → collateral — with the governance gates visibly firing (on the first run, independent reviewers vetoed drafts mid-flight and the refires passed re-verification; human approvals recorded on both runs). Honest caveat: parts of the 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 gives every seam a contract; the circulation of L1 is how each seam gets its named owner and date.

L1 — Now / Next / Later, organized by seam

Reading rule: NOW = committed and resourced. NEXT = sequenced, waiting on a NOW output. LATER = directional, revisit each review. Cadence: 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; the running filesystem implementation cited as the conformance example; Snowflake + Neptune backend sketches included; reviewed by the Data, sponsor, and DIE owners with written comments resolved.

EPIC 2 — CAF→DCA contract (Lane B). Outcome: 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 (Lane C) — substantially de-risked since v0. Outcome: the 321GO/marketplace site runs inside Snowflake, reading manifests from the Snowflake landing path — the artifact that releases the EOY funding. What already exists (built + exercised on a sandbox account this week): App Runtime deployment from environment-as-code (provision / deploy / ingest / status driver with a preflight doctor and tiered grants); validated fail-loud manifest ingest with a schema-drift test; the site's data access fully behind the DataPort with the Snowflake adapter live; in-container configuration collision solved with a regression test. Remaining acceptance: re-provision on a phData-side account (verify App Runtime enablement — public preview) · render confirmed by a human · adapter/ingest hardening to production grade · a second engineer deploys from the runbook alone.

EPIC 4 — Jira as the bench's intake (Lane E) — reshaped since v0. Outcome: the MLE bench pulls clear, self-contained work items from Jira; objectives get queued instead of narrated. Jira is the intake surface: canonical execution state stays on the house rail, and completed work answers back to the originating Jira issue. (v0 scoped Jira as a candidate rail backend; that was rejected on consistency grounds — see delta log.) Acceptance: Jira ticket template mirrors the ticket contract (order · acceptance criteria · typed context pointers); definition-of-ready = the deterministic ticket-lint checklist; this pack's tickets loaded and at least 3 pulled by MLEs without clarification round-trips.

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

Format per ticket: Order (what) · AC (done means) · Context (pointers) · size S/M/L. Repo paths use the consolidated plugin names (ab-skill-factory, ab-assessment, ab-company-research, ab-sales-collateral, ab-registrar; marketplace repo phdata-ai-wf-plugins; site repo phdata-caf-snowflake-frontend) — adjust to the phData repo names at load time.

Ticket 0 — precondition for everything below (S/M). Order: land both repos in phData source control (they currently ride local branches) and run the fresh marketplace install test for the four not-yet-reinstalled brigade plugins. AC: repos cloneable by the bench; all five plugins install clean from the marketplace. No L3 ticket is startable before this.

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 (ab-skill-factory 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. Context: 1.1's draft; CELLAR-SPEC v2 (ab-skill-factory).
• 1.3 Snowflake backend design note (M). Order: map each port to Snowflake objects (stage / VARIANT tables + typed spine / Cortex Search for retrieval; rail = table with compare-and-set lease — the ratified multi-operator direction). AC: object-level mapping table + open-questions list.
• 1.4 Neptune adapter working session (S, coordination). Order: map the existing AWS knowledge graph to the port set; document fits and gaps. AC: filled mapping table co-signed by its owner.

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: the DCA team validates the example without help. Context: site repo schemas/build-manifest.schema.json, scripts/validate-manifest.py.
• 2.2 DSA ingest spike (M, joint). Order: DSA reads a manifest, maps fields → discovery targets/build inputs. AC: field-mapping doc + spike branch demoed. Context: 2.1's packaged contract.
• 2.3 X-battery delivery-fields extension (S) — BLOCKED: impl_low/impl_high unit ruling pending. Order: extend the cross-checks to the delivery-view fields DCA consumes. AC: new rules + tests green. Context: site repo ingest validation (scripts/, X1–X8 rules + tests).
• 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. (The sponsor-visible milestone.)

Epic 3 — Snowflake-native site

• 3.1 phData-account provisioning + first deploy (M). Order: verify App Runtime enablement on the target account; run the environment-as-code driver (provision → deploy → ingest → status) there; confirm render. AC: site live on a phData-side account; preflight doctor green; render confirmed by a human. Context: site repo SNOWFLAKE-DEPLOY.md, scripts/snowflake_deploy.py.
• 3.2 Harden adapter + landing path to production grade (M). Order: production-grade error handling and degradation paths on the DataPort Snowflake adapter; parameterize the remaining hardcoded database/schema names. AC: adapter suite green; invalid manifest rejected with named violations on the phData account. Context: site repo lib/data-port.ts, lib/adapters/, ingest scripts + tests.
• 3.3 Runbook shakedown (S). Order: a second engineer executes the deploy runbook end-to-end without help. AC: their friction notes folded back into the runbook. Context: site repo SNOWFLAKE-DEPLOY.md.
• 3.4 UI parity groom (S, joint with the front-end PM). Order: walk current CAF design vs the site; produce a prioritized parity backlog. AC: ranked list in Jira, PM-owner split per item.

Epic 4 — Jira as the bench's intake

• 4.1 Jira template ↔ ticket-contract mapping (S). Order: envelope fields → Jira fields; deterministic lint checklist as definition-of-ready. AC: template live; one sample ticket passes DoR review. Context: TICKET-CONTRACT (ab-skill-factory) — its Gate A rules are the DoR checklist.
• 4.2 Registrar Jira-intake adapter (M). Order: the registrar reads the Jira intake queue → lints → enqueues canonical tickets on the house rail → the close-out sweep answers back on the originating issue. Truth stays on the rail ticket; the Jira issue is the requester's view. AC: one work item driven Jira → brigade → close-out with the answer-back landing on the issue. (Supersedes v0's "Jira backend for the rail adapter" — see delta log.)
• 4.3 Single-UC refinement path (M). Order: finish UC-as-ticket so one use case can be re-run without re-running half the assessment (the inner-rail fan-out already runs live; close the refinement entry point). AC: append context → re-enqueue one UC → re-merged manifest, invariants enforced. Context: ab-assessment brigade docs (inner rail / micro-ticket fan-out) + its phase-gate suite.

Delta log — changes since the 7/6 internal draft

1. Epic 3 pulled forward and largely de-risked. v0 scheduled the Snowflake-native site as NEXT (Aug–Oct) via an SPCS build. Since then the marketplace deployed into Snowflake via App Runtime from environment-as-code, with the validated ingest path and DataPort adapter built and exercised on a sandbox. What remains is account provisioning, render confirmation, and hardening — not a build. The EOY funding artifact moved from "quarter away" to "weeks away, mostly operational work." (SPCS remains available as an adapter; App Runtime is the exercised path.)
2. Epic 4 reshaped: Jira is intake, not the rail. Ratified 2026-07-07: file-sync-style and API-mapped backends were rejected for the execution rail on consistency grounds (lease atomicity, append-only work-logs, close-out signatures don't map cleanly). Jira feeds the registrar — the house role that owns intake and records — which enqueues canonical tickets and answers back on completion. Multi-operator execution scale goes to a Snowflake-table rail backend (compare-and-set lease) rather than Jira.
3. Consolidation renames. All brigades now live in one plugin marketplace on the ab- scheme; the assessment brigade IS the CAF phases 1–4 implementation (the separate caf plugin was retired); company research absorbed the scraping engine as vendored stations. Ticket context pointers updated accordingly.
4. Proof-point upgrades in L0. Second full engagement end-to-end within a week; the zero-code-change Snowflake deployment added as live evidence for the hexagonal-ports differentiator.