These records answer six questions in the same order for every starting format:
- What source did we start with?
- Which exact configuration did we review?
- Which ConfigHub Space, Unit, or revision held it?
- Which OCI did we publish?
- Which controller or command consumed that OCI?
- What did we observe on the target?
The record is companion information for people and tools. Kubernetes controllers do not need to read it. The format is experimental while the project looks for a compatible public standard.
Current Coverage
5/6 source paths reach a ConfigHub-managed OCI, delivery, and a recorded live result. AICR currently stops after ConfigHub republishes the 17 reviewed Argo CD Applications. It does not yet claim EKS, H100, controller, or GPU workload health.
| Starting format | Example | ConfigHub record | Output OCI | Delivery | Observation | Full record |
|---|---|---|---|---|---|---|
aicr | AICR EKS H100 training configuration captured as 17 Argo CD Applications | yes | yes | not run | not run | record |
cub-installer | A public NGINX installer package rendered once and delivered three ways | yes | yes | yes | yes | record |
helm | A team-supplied NGINX chart and values, reviewed and promoted to staging | yes | yes | yes | yes | record |
kubara | A Kubara platform configuration prepared, approved, and delivered through Argo CD | yes | yes | yes | yes | record |
rendered-config | Literal NGINX OCI promoted through ConfigHub and rolled out to two clusters | yes | yes | yes | yes | record |
sveltos | A Sveltos Kyverno profile expanded from a pilot to two clusters | yes | yes | yes | yes | record |
Why The Digests Can Differ
The input OCI and the ConfigHub release OCI are different artifacts, so their manifest digests normally differ. The chain must say whether the Kubernetes content was unchanged, changed deliberately, or gained ConfigHub's confighub.com/origin annotation.
The digest used by Argo CD or Flux must match the output OCI named by that delivery step. A live observation is separate: it records what the cluster showed at a particular time and, where available, when that observation expires.
Files
chains.jsoncontains every record for tools.matrix.csvis a compact source-by-boundary table.records/contains one readable YAML record per starting format.schemas/oci-evidence-chain.schema.jsondefines the record fields.
Verify
npm run oci-evidence:verifyThis verification is network-free. It rebuilds the six records from committed receipts, checks their digests and links, and refuses to call the AICR path delivered or observed before that work has actually run.