Inferensys

Glossary

OCI Artifact

A generic term for any content stored in a container registry using the Open Container Initiative Distribution Specification, extending the registry's use beyond container images to include Helm charts, WASM, and model weights.
ML engineer running AI model benchmarks, performance charts on multiple screens, late night home office setup.
REGISTRY EXTENSIBILITY

What is an OCI Artifact?

An OCI Artifact is a generic term for any content stored and distributed using the Open Container Initiative Distribution Specification, extending the registry's role beyond container images to include Helm charts, WASM modules, and machine learning model weights.

An OCI Artifact is any arbitrary content type stored in a container registry that conforms to the Open Container Initiative (OCI) Distribution Specification. This mechanism generalizes the registry from a single-purpose Docker image store into a content-agnostic distribution hub. By leveraging the same API, authentication, and replication primitives used for container images, organizations can manage diverse assets—including model weights, SBOMs, and configuration bundles—within a unified, familiar infrastructure.

The artifact is defined by a manifest, a JSON document that references content-addressable layers and includes a mediaType field to identify the payload type. Tools like ORAS enable pushing and pulling non-image content to OCI-compliant registries. This extensibility is foundational for tamper-proof model registries, where signed manifests and immutable digests provide cryptographic integrity for machine learning assets, ensuring that a specific version of a model is exactly what was intended for deployment.

EXTENDING THE REGISTRY PARADIGM

Key Features of OCI Artifacts

OCI Artifacts transform container registries into generic, distribution-agnostic content stores. By leveraging the existing OCI Distribution Specification, they enable the secure, immutable storage of any content type—from Helm charts to machine learning model weights—using the same push/pull mechanics and content-addressable storage as container images.

01

Content-Addressable Integrity

Every OCI Artifact is identified by a cryptographic digest (SHA-256) of its manifest, not just a mutable tag. This provides immutable, tamper-evident storage where any modification to the artifact's layers or configuration produces a completely different digest. The manifest references individual layers by their own digests, creating a Merkle DAG that guarantees end-to-end data integrity. This is the foundation for non-repudiation in software supply chains.

02

Media Type Extensibility

Unlike container images locked to application/vnd.oci.image.manifest.v1+json, OCI Artifacts use custom IANA media types to declare their content format. Examples include:

  • application/vnd.cncf.helm.chart.config.v1+json for Helm charts
  • application/vnd.wasm.config.v1+json for WebAssembly modules
  • application/vnd.oci.image.manifest.v1+json for traditional images This allows registries to polyglot store any artifact type while enabling type-specific policy enforcement and scanning.
03

Annotated Metadata Layer

OCI manifests support an annotations map—arbitrary key-value string pairs—that attach metadata directly to the artifact without modifying its content. Common annotations include:

  • org.opencontainers.image.source: link to source repository
  • org.opencontainers.image.vendor: publisher identity
  • Custom keys for SBOM references, signing status, or model card pointers Annotations are indexed by registries, enabling discovery and filtering without pulling the full artifact.
04

Referrers API for Supply Chain Graphs

The Referrers API (OCI Distribution Spec v1.1) enables artifacts to link to other artifacts, forming a supply chain graph. A container image can point to its SBOM, signature, and vulnerability scan result as separate, independently signed artifacts. This creates an attestation ecosystem where:

  • Cosign signatures are stored as referrers
  • SBOMs are linked via subject field
  • Policy engines traverse the graph for binary authorization decisions
05

ORAS: Universal Artifact Client

ORAS (OCI Registry As Storage) is the de facto CLI and library for managing non-container OCI Artifacts. It extends docker push/pull semantics to arbitrary content:

bash
oras push registry.example.com/models/llama:7b \
  --artifact-type application/vnd.ai.model \
  model.safetensors:application/octet-stream

ORAS handles manifest creation, layer compression, and multi-arch indexing, making it the universal client for model registries, Helm repositories, and WASM stores.

06

Immutable Tag Enforcement

Registries supporting OCI Artifacts can enforce immutable tags, preventing a tag like v1.0 from being overwritten with a different digest. Combined with digest-based pulling (registry.example.com/model@sha256:abc...), this guarantees that a deployment always fetches the exact, verified artifact. This is critical for reproducible ML pipelines where model weights must be cryptographically pinned to a specific version for auditability and rollback.

OCI ARTIFACT CLARIFICATIONS

Frequently Asked Questions

Clear, technical answers to common questions about the Open Container Initiative Artifact specification and its role in storing non-container content in registries.

An OCI Artifact is any arbitrary content stored and distributed using the Open Container Initiative (OCI) Distribution Specification, extending a container registry's capabilities far beyond Docker images. It works by leveraging the registry's existing API to push, pull, and discover content-addressable blobs of data, referenced by a manifest. Unlike a container image, which has a specific config.mediaType and a set of ordered filesystem layers, an OCI Artifact can define custom media types for its manifest and layers. This allows the registry to store Helm charts, WebAssembly (WASM) modules, Singularity containers, and critically, machine learning model weights. The artifact's identity is its digest—a SHA256 hash of its manifest—providing a cryptographically verifiable, immutable pointer to the exact content, which is foundational for tamper-proof model registries.

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.