docs(roadmap): tighten v1 acceptance criteria per pillar

Restructure each pillar's Acceptance block into shippable artifacts and
demonstrable signals. Add bare-metal (BCM) coverage and Vera Rubin to the
accelerator axis. Reframe the contribution bar around per-persona
self-service thresholds for user, integrator, and contributor.

Author: mchmarny

ROADMAP.md

@@ -24,7 +24,12 @@ four axes plus the validation that backs it.
 **Service axis.** Validate end-to-end AICR on managed Kubernetes services — both Cloud Service Provider (CSP) and partner-cloud offerings — alongside vanilla Kubernetes.
 
 **Accelerator axis.** H100 is mature; v1 needs L40 and B200 in addition to the
-GB200 work already in flight, with GB300 framed as a near-horizon target.
+GB200 work already in flight, with GB300 and Vera Rubin (VR) framed as
+near-horizon targets.
+
+**Service axis (bare metal).** Bare-metal service classes — including BCM and
+equivalent operator-managed Kubernetes distributions — are represented in the
+v1 matrix alongside CSP and vanilla Kubernetes.
 
 **Intent axis.** Both training and inference per (service × accelerator) cell once
 that cell is in scope.
@@ -37,14 +42,24 @@ hand-authored criteria.
 advisory on PRs (Tier 1 generic plus diff-aware Tier 2) with the full matrix
 running on merges to `main` and nightly. v1 closes the gap by adding a nightly
 UAT cadence on live managed Kubernetes services and tightening these signals
-into the merge path so coverage stays validated between releases.
+into the merge path so coverage stays validated between releases. Results are
+published through a Testgrid-style dashboard so the matrix has a single,
+durable evidence channel anyone can read.
 
 **CNCF AI Conformance.** Certify AICR-on-EKS as conformant once the WG finalizes
 requirements. Treat conformance evidence as a first-class output of the validator.
 
-**Acceptance:** every (service × accelerator × intent) cell in the v1 matrix
-validates against a snapshot, generates a bundle, deploys via UAT, and is exercised
-by nightly automation.
+**Acceptance:**
+
+*Shippable artifacts:*
+- v1 matrix of (service × accelerator × intent) cells declared in this document, with bare-metal classes (BCM) and forward-looking accelerators (GB200, GB300, VR) represented as in-flight slots.
+- CNCF AI Conformance evidence emitted by the validator and regenerated per release.
+- Nightly UAT cadence on live managed Kubernetes wired into the merge signal.
+- Testgrid (or equivalent dashboard) brought up as the canonical evidence channel for recipe validation.
+
+*Demonstrable signals:*
+- Sustained green-rate across the matrix in Testgrid across multiple release cycles.
+- Recipe portfolio carries enough gravity that the dominant service / accelerator / platform needs of most users land inside the supported matrix.
 
 ### 2. Stability
 
@@ -66,9 +81,16 @@ content so bundles are portable.
 **Versioning policy.** Document the major-bump policy for each surface in
 `RELEASING.md` and wire compatibility tests into CI.
 
-**Acceptance:** `v1.0.0` ships with a frozen, documented contract for the CLI,
-REST API, and bundle layout; any subsequent breaking change is detected in CI and
-gated behind a major-version bump.
+**Acceptance:**
+
+*Shippable artifacts:*
+- Frozen baseline tag for CLI flags, REST endpoints (`api/aicr/v1/server.yaml`), Go SDK exported surface (`pkg/client/v1`), and bundle layout + schemas (recipe, validation, snapshot kinds).
+- CI diff-gate that fails on unintended breakage of any of the four surfaces.
+- Deprecation channel documented in `RELEASING.md`.
+
+*Demonstrable signals:*
+- Sustained external use of the Go SDK, REST API, and schemas by consumers outside the AICR team, exercised against the frozen surface across release cycles without breaking-change requests.
+- Deprecation channel exercised at least once in practice before tagging `v1.0.0`.
 
 ### 3. UX
 
@@ -88,9 +110,21 @@ contributors aren't copy-pasting drift into the tree.
 the review pipeline fast and predictable; a local registry for nvkind keeps the
 inner-loop tight for contributors without cloud access.
 
-**Acceptance:** an external contributor adds a new validated leaf recipe using
-only public docs and the CLI, and the review pipeline merges community PRs at the
-cadence the inbound flow demands.
+**Acceptance:** the bar is *self-service without filing a support issue or
+reading source code* for three personas — **user**, **integrator**, and
+**contributor**.
+
+*Per-persona self-service thresholds:*
+- **User** — install through bundle generation, deployment validation, and evidence collection completable using only `docs/user/`. The same path eventually submits that evidence to the Testgrid pipeline described in §1.
+- **Integrator** — Go SDK or REST API embeddable into a downstream pipeline using only godoc and `docs/user/api-reference.md`.
+- **Contributor** — new or modified leaf recipes authorable and mergeable using only `docs/contributor/` plus CLI tooling, and every recipe change carries validation evidence that the CI gate verifies before merge.
+
+*Shippable artifacts behind the thresholds:* `aicr recipe validate` verb, scaffolding generator, reusable overlay template, KWOK e2e auto-generation for new leaves, mixin-based composition discipline, merge queue + unified merge-gate, recipe-change CI gate that requires verifiable validation evidence.
+
+*Demonstrable signals:*
+- A community-authored leaf recipe merged end-to-end without maintainer hand-holding.
+- An independent user deploys a bundle and submits evidence through the documented pipeline.
+- An external integrator reference exists (in-tree example, downstream repo link, or recorded user story).
 
 ### 4. Security
 
@@ -116,17 +150,18 @@ as the binaries that read it.
 **End-user verification.** A top-level guide that walks a consumer from a
 downloaded bundle to a fully-verified deploy, covering all signing modes above.
 
-**Acceptance:** every artifact (binary, image, recipe data, bundle) has retrievable
-provenance and a documented verification path that works in air-gapped, private,
-and public-trust deployments.
+**Acceptance:**
+
+*Shippable artifacts:*
+- SLSA attestation on every artifact (binary, image, recipe data, bundle) with cosign signing.
+- `aicr bundle verify` honoring trust-level evaluation across signing modes.
+- Air-gapped signing flow, private Sigstore deployment, and KMS-backed key custody documented and tested.
+- Verify-on-deploy path documented and tested.
+- Signed validator catalog and component registry.
+- End-user verification guide published in `docs/user/`.
 
-## Revision History
+*Demonstrable signals:*
+- Consecutive releases pass the full provenance chain in CI.
+- An independent party verifies a release end-to-end across the supported signing modes.
 
-| Date | Change |
-|------|--------|
-| 2026-04-28 | Restructured around v1 objectives |
-| 2026-02-17 | Expanded Recipe Creation Tooling with validation framework details, scaffolding, and workflow integration |
-| 2026-02-14 | Moved implemented items to Completed: EKS H100 recipes, snapshot-to-recipe, monitoring, Nodewright Ubuntu |
-| 2026-01-26 | Reorganized: removed completed items, streamlined structure |
-| 2026-01-05 | Added Opens section based on architectural decisions |
-| 2026-01-01 | Initial comprehensive roadmap |
+*Epic:* #1149.