AICR's evidence, our receipts, and what this project actually adds

The short answer is that the overlap is real and the contributions are different, but some of our wording was written as though upstream had no evidence discipline at all. That wording is wrong and is corrected here and on the pages.

What AICR ships

AICR validates its own recipes against real hardware and emits attestable evidence about the result.

• Declarative health checks per component. recipes/checks/<component>/health-check.yaml holds a chainsaw.kyverno.io/v1alpha1 Test. The Kube Prometheus Stack check asserts that the operator Deployment has an available replica and that no pod in the monitoring namespace is unhealthy, with a five-minute assert timeout. Twenty-one components carry one at the version we retain.
• Validation runs that produce evidence. aicr validate runs containerized validators against a cluster, and --emit-attestation turns the result into a recipe-evidence bundle.
• Offline evidence operations. aicr evidence digest prints the canonical digest of a resolved recipe, and aicr evidence verify checks a bundle's integrity claims. Upstream describes the purpose precisely: it lets maintainers and CI verify a recipe contribution without re-running the validators against hardware they may not have access to.
• Per-recipe evidence in the repository. Current upstream carries an recipes/evidence/ tree with a directory per validated recipe shape.
• A signed recipe catalog, verified by this project's own lane.

That last sentence is the important one. A project that emits attested evidence so third parties can check its claims without the hardware is doing the same thing this project does, for the same reason.

What this project ships

The catalog's receipts cover a different span of the same problem.

• Receipts about configuration operations, not about component health. Ours record that an import was byte-faithful, that a reviewed change touched exactly the documents it declared, that a promotion carried the reviewed configuration, and that a delivery was accepted with no sync started.
• Retention and digest pinning across producers. AICR pins its own recipes. The catalog pins AICR beside charts, Kubara components, and Sveltos profiles, under one discipline, so a team can ask the same provenance question of every piece of its platform.
• Governance evidence. Dry-run previews, approvals, variant lineage, and promotion history are ConfigHub concerns that AICR does not address and does not claim to.
• Refusals as artifacts. The blast-radius checker, the credential guard, and the signature lane all record what they refuse.

Where they overlap, and who is authoritative

The honest division is that AICR answers whether a platform works, and the catalog answers whether a change to it was governed. Neither is a substitute for the other, and each is weak where the other is strong. The catalog cannot tell you that the GPU operator came up healthy on an H100 node. AICR cannot tell you who approved the storage-class change or what it touched.

What we were saying that needs correcting

Three claims were written before anyone here read AICR's evidence surface.

1. "Nobody offers governed, provenance-carrying configuration for this space." The catalog overview says this. It is defensible about governed configuration, and it is wrong about provenance-carrying: AICR carries provenance, signs its catalog, and emits attestable evidence. The claim is narrowed on the page to the governance half.
2. The implication that receipts were a novel answer. The receipts idea is good and it is not ours alone. Saying so costs nothing and makes the catalog more credible, not less.
3. "Ordering is a decision the catalog has not earned." The delivery proof said this. The ordering is declared upstream, and the ordering-parity lane now proves our bundles preserve it. The controller still stays at zero in that proof, which remains right for a config-plane proof, but the reason is that the catalog declines to run the sync, not that it lacks a defensible order.

What this does not change

The retention, the digest spine, the derivation chain, the licensing boundary, and the governance receipts all stand exactly as they were. Nothing above weakens a claim that rests on evidence this project produced. What changes is the framing around them, and framing that overstates is the kind of claim this project exists to refuse.

What is still unread

The evidence bundle format itself, the containerized validators, the snapshot schema, and the aicrd daemon. A later increment should read the bundle format and decide whether a catalog entry can carry an upstream evidence bundle alongside its own receipts, which would let the two disciplines meet in one artifact rather than two.

Trust, mirror, and skill comparison (v0.20.0)

Reviewed for #1450 on 2026-09-06 against AICR commit b8a6eadb2d6f7e5b62dcb93446874f383940de0f, the commit reported by the v0.20.0 release binary. The execution receipt records the archive checksum, binary digest, source-file digests, command results, and network-denial policy. Release checksum agreement is an integrity check, not an independent signature authentication of that binary.

The version command, trust update --help, mirror list --help, and skill --agent codex --stdout succeeded under macOS sandbox-exec with network access denied. The skill was printed, not installed. Trust update and mirror discovery were inspected in source rather than executed: the former updates a cache over the network, and the latter can acquire chart artifacts. This comparison changes no signature, publication, support, or live-proof claim.

Trust: authenticated acquisition and reviewed retention

AICR's trust command provides trust update; it refreshes trust material through TUF and can emit a Rekor v2 signing configuration. The implementation uses a cache-only TUF client for verification. Explicit update refreshes TUF metadata and targets, with signature, hash, and expired-metadata errors classified as trust failures. Signing configuration is separate from verifier trust material: refreshing it is best effort during update, and signing can fetch it when the cache is cold. Offline verification does not mean every signing operation is offline.

The catalog's trust-root review answers a narrower question: did the committed root change after its recorded review, and did its bytes match the file fetched at that review? Its implementation fetches a raw GitHub URL over HTTPS and compares SHA-256 values. It does not verify a TUF metadata chain. The existing receipt remains useful evidence of the comparison; it is not a receipt of authenticated TUF acquisition.

Keep the independent cosign verifier and explicit root pin. A stronger future acquisition lane would authenticate the TUF target, retain that acquisition evidence, and propose the resulting bytes for review. It must not silently replace the committed root. Neither the absence of end dates in active root entries nor a successful digest comparison proves TUF metadata freshness.

Mirror: discovery is different from retained dependency closure

The mirror CLI exposes mirror list, not an image-copy command. It resolves recipe values, applies component overrides, and passes the result to a discovery implementation that renders external Helm charts and scans manifests for image references. Outputs include YAML, JSON, Hauler manifests, and Zarf configuration for other tools to consume. Image bytes are not copied by this command, but discovery can fetch chart bytes; that matters for NGC-served charts.

The remote dependency closure report joins committed chart source-scan findings to maintained dependency locks. It is not a live resolver or a full runtime image inventory. The two tools do not compute the same closure: upstream discovers recipe-specific chart/image references; our report records which chart dependencies already have retained lock and provenance evidence.

Upstream rejects structural values-resolution errors, but some Helm-render and manifest-reading failures become per-component warnings. A successfully returned list must therefore be read with its warnings; it is not proof that all runtime images were found. Operator-created workloads also need evidence beyond the operator installation manifests. For this catalog, any discovery experiment must retain the selected values and warnings, use permitted public chart sources, and keep gated image/model references as data. It must not run Hauler/Zarf copying or acquire NGC chart artifacts as a side effect.

Skill: CLI syntax versus chart-specific operating guidance

The skill command generates instructions from the CLI's command metadata. Its metadata walker collects commands, subcommands, flags, defaults, and positional argument shapes while excluding hidden commands, framework plumbing, and skill itself. The stdout mode exercised here produces a version-labelled CLI skill without writing an agent configuration file.

Our chart-skill generator derives which maintained thematic playbooks apply from chart facts in the master matrix. Its output is an advisory mapping with matched signals such as hooks, CRDs, and webhook requirements. It does not generate AICR's command reference or prove that a recommended procedure succeeded. Upstream teaches how to invoke its CLI; the catalog routes a chart to the relevant operating procedure and receipts. Both can help an agent, and neither generated skill grants approval to install, publish, or claim a proof result.