Manifest reference

This reference explains the manifests used to describe Capsem releases, VM runtime assets, and corporate distributions. It covers their fields, relationships, validation, and channel selection so you can identify the document that controls a package or runtime update.

A release manifest selects host packages and the VM runtime. It does not configure agents or replace corporate security policy. OCI application images are separate from the kernel/initrd/rootfs used to boot a VM.

Manifest families

Document	Purpose	Authority
Channel catalog	Lists channels and selectable manifest versions, status, URL, digest, and compatibility bounds.	Release channel publisher.
Release manifest	Host package cohort plus an optional runtime document.	Public or corporate distribution publisher.
Runtime document	One runtime revision, per-architecture images, software inventory, and evidence.	Runtime publisher.
Asset manifest v2	Materialized kernel/initrd/rootfs assets and orthogonal asset/binary tracks.	Generated by asset tooling; also consumed by compatibility readers.
Corporate configuration	Rules, constraints, reporting, and policy source.	Administrator; TOML, not a release manifest.

Release manifest

Field	Contract
version	Manifest version.
channel	Owning channel.
status	current, supported, deprecated, or revoked.
packages	Host package inventory.
runtime	Optional until the channel’s first runtime publication.

Package rows include ID/name/version/source commit, package kind, platform, architecture, URL, byte size, SHA-256/BLAKE3 digests, status, executable inventory, and evidence. Package kinds are macos_pkg and debian_package. Executable rows record their installed path, hashes, architecture, and SBOM component reference.

Runtime document

Field	Contract
revision, source_commit, status	Runtime identity and provenance.
min_capsem_version, max_capsem_version	Optional compatibility bounds.
architectures	Architecture-specific inventories, image revisions, images, and evidence.

Each architecture has exactly the required kernel, initrd, and rootfs image kinds. Image rows include name, URL, bytes, digest set, and status. Software rows name package/version/source/architecture and associated evidence.

Updating a runtime does not select a different host binary package. Binary and runtime publications are independent; compatibility checks connect them.

Asset manifest v2

The materialized v2 shape has format = 2, refresh_policy, optional asset_base, and assets / binaries tracks with current and releases. Asset architecture keys use arm64 and x86_64.

Boot resolution verifies the selected kernel, initrd, and rootfs.erofs against the expected hashes. A missing or corrupt file is not ready merely because its filename exists.

Corporate authoring

capsem-admin manifest corporate combines selected official packages with a corporation-owned runtime. Inputs include corporation/channel, official and runtime manifest paths, owned HTTPS runtime base, selected binary version, exact source commit, and output root. Official packages remain read-only inputs; runtime URLs must belong to the corporation’s declared base.

See Deploy Capsem in your enterprise for the workflow. Use capsem-admin manifest corporate --help for exact flags.

Validation and channel selection

capsem-admin manifest check manifest.json --json

Use capsem-admin manifest generate for built assets and capsem-admin assets channel check for a channel’s generated runtime artifacts. Generate manifests from owned inputs; do not hand-edit published digests to admit mismatched bytes.

Updater manifest inputs are URLs, including file:///absolute/path for local files. Selecting a corporate asset manifest records a locked corporate channel. Later public-channel or different-manifest selections fail before fetching or changing the installation.