Entry Schema ​

Field-level reference for the two wire-format JSON shapes that carry package data: the package root and the OCI image index. This page is a summary table derived from the JSON Schemas below — the schemas are the source of truth for exact types, patterns, and constraints; consult them directly for anything this table simplifies.

• Root: https://index.ocx.sh/schema/root.schema.json
• Image index: https://index.ocx.sh/schema/image-index.schema.json
• Config: https://index.ocx.sh/schema/config.schema.json
• Enumeration index: https://index.ocx.sh/schema/c-index.schema.json

See Wire Format for URL shapes and freshness semantics, and Namespace Policy for the name/repository charset.

config.json ​

Enumeration Index — /c/index.json ​

See Wire Format for the sync protocol built on top of this shape.

Package Root — /p/<namespace>/<package>.json ​

Variants ​

A variant is a build of the same version with different software-level characteristics — an optimisation profile, a feature set, a libc. It is spelled as a tag prefix: slim-3.13.1 is the slim variant of 3.13.1, and an unprefixed 3.13.1 is the default variant.

variants is a projection of tags, not an independent declaration, and the PR gate enforces exactly that: check_variants_match_tags re-derives the set from the root's own tags and rejects a present field that disagrees. Omitting it is always allowed — an absent field claims nothing, and the catalog derives the set from tags regardless of what the root stores. Recompute it and you get the same answer: take every tag that parses as a version, keep the ones carrying a prefix, sort and deduplicate the prefixes. It is recorded so that reading "does this package ship variants" does not require re-implementing the version grammar. latest is reserved and is never a variant name.

Two consequences worth knowing:

• The default variant has no name. It is the absence of a prefix, so it never appears in this array — variants: ["slim"] on a package that also publishes 3.13.1 means two variants ship, the default and slim.
• A bare rolling tag (slim, no version) is not a version, so it contributes nothing on its own. It is legible as a variant pointer only alongside a versioned slim-* sibling — an inference the package page makes when it renders, and one this field does not make.

Owner ​

Upstream ​

Source versus upstream ​

Two different questions, deliberately two fields:

• upstream.repository_url — who wrote the software. Human-governed attribution of the third-party vendor the namespace names, set once in the claim PR.
• source — who built these artifacts. Bot-read from the published image's org.opencontainers.image.source annotation, so it names the repository whose CI ran the build.

For a mirror they are different repositories on purpose: kitware/cmake may attribute https://github.com/Kitware/CMake upstream while its source is the mirroring repository that produced the OCI artifacts.

Desc ​

TagEntry ​

Yanked ​

OCI Image Index — /p/<namespace>/<package>/o/sha256/<hex>.json ​

The bytes at this path are an OCI image index, stored verbatim as the physical registry served them — this index defines no shape of its own here. The table below is a reading aid for the fields this site and ocx actually consume; the OCI image-index schema is deliberately not additionalProperties: false — a real index may carry subject, artifactType, annotations, or future spec fields this index does not author and must not reject.

ManifestDescriptor ​

Platform ​

Inline subset of the OCI image-spec Platform object. Field names with a literal dot (os.version, os.features) match the OCI spec's own property names verbatim — not a nested os object.

Field Provenance ​

Two disjoint sets, never cross-contaminated (see Governance Contracts G-09):

• Human-governed (only changed by a merged PR): name, repository, owners, status, deprecated_message, superseded_by, created, upstream, and tags[*].yanked.
• Bot-regenerated (rewritten from registry truth on every announce/reconcile): desc, source, and the rest of every tags[*] row.