channel.vexa.ai carrying signed entries, the digest-pinned Helm chart, image signatures, the kit, and a current pointer. Your staging follows current; your production follows a pin only you move. Mirroring the whole channel into your own registry is first-class — the guarantees are in the signatures and digests, not the transport.
The default is the open channel of your shape. Sharing one shares nothing else: your credential reads your channel only, your values never leave your cluster, your pin is yours.
What a release is
One OCI artifact:entry.json— version, source commit, image digests, and the sha256 of every evidence file.evidence/— digest map, delivery receipt from our own production run, SLSA provenance, Sigstore trust material for offline verification.VERIFY.md— the commands, with this release’s filenames filled in.- Beside it, the Helm chart as an OCI artifact, every digest baked into its values — including the images the runtime spawns per meeting.
evidence_absent names what this release lacks, and break_glass names who authorised an incomplete chain, and why.
Each stage that validates the artifact signs it. The bytes never change; a candidate that fails stops accumulating evidence.
Your credential
One pull-only account scoped to your channel, minted, rotated and revoked withvexa_subscriber.py list | add | revoke (add also rotates; revocation lands within a minute). channel.pub is not secret — it is published and read aloud on a call. The secret half travels a different route, encrypted with age to a key you already control, usually an SSH public key from your GitHub account with the fingerprint cited in the mail. Rotation invalidates nothing you already pulled.
Freshness and revocation
Entries expire. A channel nobody has published to goes stale, and your verifier says so in its own words —FAIL STALE CHANNEL — this entry expired at … — rather than in the vocabulary of a bad signature, because an expired entry and a forged one are different incidents. Your pinned release keeps running. max_entry_age_days in your contract tightens the horizon below ours; nothing widens it.
A release found defective is named on a cosign-signed revocation list on the channel with a reason and a destination, and your verifier refuses it before the next sync. No list published at all is an empty list, not an error. Your admission controller cannot read this list — revocation is enforced by the verify gate, not by Kyverno.
Both clauses are enforced by that PreSync verify gate, and the gate is off unless you install with --verifier-image.
Rung. Neither has been exercised against a live subscriber yet, and the deployed verifier, v0.1.1, does not check freshness — so nothing enforces expiry inside a cluster today. What’s proven, and where.