Manifest

Every layer and configuration object in a manifest is referenced by its cryptographic digest (SHA-256), not by a mutable name. This creates a Merkle DAG where:

• Any modification to a single byte produces an entirely new digest
• The manifest's own digest becomes a globally unique, tamper-evident identifier
• Verification is deterministic: recalculate the hash and compare

This property is the foundation of non-repudiation and supply chain security in OCI registries.

Manifests declare their schema version explicitly through the schemaVersion field, ensuring parsers can handle format evolution:

• Schema Version 1: Legacy format with backward compatibility, uses unsigned manifests
• Schema Version 2: Current standard supporting multi-architecture images, content-addressable descriptors, and extensible annotations

This versioning prevents silent misinterpretation of manifest fields across different registry implementations and client tooling.

A manifest list (or image index) is a special manifest type that points to platform-specific manifests for different architectures and operating systems:

• A single tag like python:3.12 resolves to an index containing pointers to linux/amd64, linux/arm64, windows/amd64 variants
• The container runtime selects the appropriate child manifest based on its own platform
• Each child manifest is independently content-addressable and can be signed separately

This enables fat manifests that provide seamless cross-platform deployment without tag proliferation.

The annotations field is an extensible key-value map that attaches arbitrary metadata to a manifest without altering its digest:

• Standard annotations: org.opencontainers.image.created, org.opencontainers.image.authors, org.opencontainers.image.source
• Security annotations: SBOM references, vulnerability scan results, attestation pointers
• Custom annotations: Enterprise-specific labels for compliance, cost centers, or deployment policies

Annotations are critical for artifact discovery and policy evaluation without parsing layer contents.

The artifactType and config.mediaType fields distinguish what kind of artifact the manifest describes, extending registries beyond container images:

• application/vnd.oci.image.config.v1+json: Standard container image configuration
• application/vnd.cncf.helm.chart.config.v1+json: Helm chart stored as an OCI artifact
• application/vnd.ai.model.config.v1+json: Machine learning model weights and metadata

This OCI Artifact pattern, supported by tools like ORAS, transforms container registries into general-purpose artifact stores for SBOMs, WASM modules, and model registries.

The subject field creates a cryptographically verifiable link between a manifest and its parent artifact, enabling in-toto attestations and supply chain metadata:

• An SBOM attestation manifest references the image manifest it describes via subject.digest
• A vulnerability scan result manifest points to the exact artifact digest it analyzed
• Cosign signatures are stored as separate manifests with a subject pointer to the signed artifact

This creates a verifiable graph of related artifacts within the registry, enabling policy engines like OPA to enforce that every deployed image has a valid attestation chain.

The manifest references each filesystem layer by its cryptographic digest (SHA256), not by a mutable name. This means the content's identity is its hash. If a single byte in a model weight or config file changes, the digest changes, breaking the manifest's integrity. This property enables deduplication across registries and guarantees that a given digest always resolves to the exact same bytes.

While a tag like v1.0 is a mutable pointer, a digest reference like sha256:abc... is immutable. Pinning a deployment to a manifest digest ensures you always pull the exact artifact that passed your security scans, eliminating race conditions and tag mutation attacks. This is the foundational practice for reproducible deployments in regulated environments.

The manifest is the core object defined by the Open Container Initiative (OCI) Distribution Spec. This spec standardizes how artifacts are pushed, pulled, and discovered in a registry. It extends the registry's utility beyond container images to include:

• Helm charts
• WebAssembly (WASM) modules
• Model weights and tokenizers This standardization is what allows tools like ORAS to store AI artifacts in any compliant registry.

Cosign signs a manifest by computing its digest and storing the resulting signature as a separate OCI object in the same repository. This signature is linked to the manifest via a referrers API or tag convention. During verification, the manifest's digest is recomputed and checked against the signature, providing cryptographic non-repudiation that the artifact was published by a trusted identity without altering the original manifest.

The manifest's annotations map is a key-value metadata store that can hold structured information like a Model Card. By embedding details such as intended use, performance benchmarks, and ethical considerations directly into the manifest, the registry becomes a self-describing artifact store. This allows policy engines like OPA to make admission decisions based on model properties without pulling the full artifact.

When a manifest is signed, the signing event can be recorded in Rekor, an append-only transparency log. This provides a publicly auditable, timestamped proof that the signature existed at a specific point in time. For AI supply chains, this means an auditor can verify not just who signed a model manifest, but when, preventing backdating attacks and ensuring long-term non-repudiation.