Skip to main content
Date: 2026-09-07. Channel: the pilot channel on channel.vexa.ai — the live registry, not a test rig. Station: our own rehearsal station, not a customer’s. Cluster: the rung-4 rig from 2026-09-06, unchanged. Container work ran on an internal build host, never on a laptop. Two sentences, so a reader skimming does not take the wrong one away. A contract that admits a candidate entry was written, recorded in the state ledger by pull request, and rendered ELIGIBLE against entry seq 5 by kit v0.1.6 — that half works and is durable. The install did not run, because the channel carries no chart for that release, so nothing here proves that the cluster runs the entry’s bytes and this receipt does not claim it.
The subscriber is not named. Their registry hostnames, project names and estate details are not in this document. The channel is written as <pilot-channel> and the rig’s pull-through registry as <harbor-host>.

​
The rung, unchanged

Rung 4 of 4, and it is NOT OpenShift — a kind cluster with PSA restricted and Kyverno emulating restricted-v2. No oc, no SCC objects, no OLM, no Routes, no internal registry, no GitOps operator. PROFILE_TESTED on the openshift profile stays no, and nothing below changes that.

​
Why a candidate lane exists at all

Entry seq 5 is published candidate. Three things follow from that, and every existing contract on the channel refuses it for at least one of them: Those refusals are correct. A candidate lane is the shape that consumes such an entry without weakening the published lane, which is untouched — a second contract for a second station, not an edit to the first.

​
The contract

contract_id: bbb-rehearsal-candidate-2026-09-07, sha256 da5d15d4a2e63c062741a2a7fcf33727ecde7269cfadffa27f56ccd9571ce533. JSON in the 2026-09 carriage{} shape, in the state ledger, moved there by pull request as contracts must be.
What it deliberately omits, and why each omission is a reading of the entry rather than a convenience. report_scope.allowed_sections is the current spelling, and this matters beyond our own file. kit/validate refuses a contract carrying the older allowed_files rather than ignoring it — “a bound we cannot read is not a bound we will guess at”. The pilot’s own contract in the ledger still carries allowed_files, so its next submit will be refused locally until that clause is renamed. That is a one-line edit, and it is a pull request against their contract, not something we can do on their behalf.

​
Proof 1 — the kit came from the channel, verified before it was unpacked

The public key was the ledger’s own channel.pub, sha256:f6aac70ec20248f977403f256594ef50a5ea14b2b42e4d4ca1e456742db8fab9 — byte-identical to the copy on the build host and to the one the rig’s admission policy pins. The pull used a pull-only station credential, supplied through the environment as bootstrap.sh reads it, never on a command line.

​
Proof 2 — ELIGIBLE

A candidate entry on a private channel, signature-verified offline against a key delivered by a separate route, admitted by a contract that names the candidate mode explicitly. The gate works and the lane is real.

​
Where it stopped, at the exact line

The channel carries no chart for this release. The entry says so itself, in its own evidence_absent block:
and the channel’s chart repository has exactly one tag:
Three consequences, each measured:
  1. The installer would render the wrong release. install.sh renders the delivered set with helm template … oci://…/charts/<chart> and no --version, so it resolves the newest chart — 0.12.35, the previous entry’s. Installing under an entry-5 lane would put the previous entry’s bytes on the cluster.
  2. The digest sets are disjoint. Of the entry’s 11 candidate-map image digests, 0 appear in chart 0.12.35, which pins six application images at the previous release’s digests. The intersection is empty — not narrow, empty.
  3. The in-cluster gate would ask for the wrong entry. The PreSync verify hook derives its --entry-ref from Chart.AppVersion, so chart 0.12.35 asks the verifier for the published entry — which this candidate contract correctly refuses. The lane and the chart disagree by construction.
The OSS chart in the product tree at the matching tag is not a substitute either: it pins no digests at all, referencing images by a floating tag, so the rig’s own digest-pinning admission policy would refuse it. Producing a digest-pinned chart is the publisher’s chart step, and publishing it is a signing act on the channel key — neither is a station’s act, and neither was attempted. Nothing was relaxed to get past this. The contract was not widened, the admission policies were not touched, --skip-preflight was not used, and install.sh was run only with --dry-run. The rig is byte-for-byte as the previous run left it.

​
The one-line fix, named

Publish a digest-pinned chart for this release to the channel, with appVersion equal to the release version, and the same run becomes an install. Until then the channel’s installable state is still the previous entry, and a candidate lane can verify but not deliver.

​
The claim this run was for, answered honestly

“The cluster runs exactly the entry’s bytes.” It cannot be answered here, because none of the entry’s bytes were delivered. The station report’s own release block is the evidence: An empty answer, said out loud, rather than a green one assembled from a different release’s pods.

​
What the kit did right — four defects closed

Measured against the seven recorded on 2026-09-06, with v0.1.6 pulled from the channel: Defect 6’s closure is the one worth stating twice. The previous receipt called it the sharpest thing that run found: the path that breaks is the failure-reporting path, so a subscriber whose install goes wrong cannot file the receipt that would represent them. This run drove a failing estate all the way through:
vexa_validate.py then wrote a 402-line station-report.yaml carrying a smoke_receipt section — exit 1, redaction verified, three values removed, zero leaks — and the ingest gate that refused at S2 on 2026-09-06 accepted it, wrote the station’s first state.yaml, and derived the contract-breach flag from the non-PASS verdict. A failure is now representable end to end. Phase verdicts, for the record: preflight FAIL (exit 1 — P4 alone, on the dynamic bot pod that carries no securityContext; seven of eight PASS with an admin snapshot, and the live cluster contradicts P4 because a mutating webhook runs before PSA validation) · install skipped · smoke FAIL (exit 1) · validate exit 1 · ingest accepted, verdict REFUSED.

​
Three new findings

1 · A kit bootstrapped from the channel reports no version. vexa_validate.py fills its kit: block from git describe / git rev-parse, and a bootstrapped tree is not a git checkout — so kit.commit, kit.describe and the state ledger’s kit_version are all null, while the tree itself knows: VERSION beside install.sh reads version=v0.1.6. The ledger row for a station that used a git clone carries a revision; the row for a station that followed the documented onboarding path does not. That is backwards, and it means we cannot currently say which kit produced any real subscriber’s report. Suggested shape: read VERSION first and fall back to git, rather than the reverse. 2 · --entry-seq and --entry-digest are cross-checked against nothing. A first pass of this run passed both flags, and the report recorded the entry sequence and digest as fact while listing six running image digests, none of which belong to that entry. The report was discarded and regenerated without the flags, so the one filed asserts no position — but a mistyped number would have been ingested as an observation. The tool already has both sides in hand: the asserted digest and the observed image list. Suggested shape: refuse, or mark the position asserted rather than observed, when the entry’s images are not the ones running. 3 · A station’s write path is its account name, and a station whose ledger name differs cannot submit. The channel edge confines a station credential to /v2/vexa/stations/<account>/** and compares the authenticated user against the path segment, while --submit pushes to …/vexa/stations/<station-name>/…. A station whose directory name in the ledger is not its account name gets a 403 at the moment it tries to file its report — which is, again, the failure-reporting path. Not exercised in this run (no write was attempted); recorded from the edge’s own scope matrix and the submit path composition.

​
The pull path, since it is a standing question

The rig’s pull-through registry proxies the public image host anonymously — its upstream endpoint carries no credential — and the cluster node has a mirror entry only for the rig registry, so the delivered workloads’ own image pulls go directly to the public host from the build host’s address. Neither path spends the publishing account’s budget. Measured at the time of this run: anonymous, from the build host, limit 100/h · remaining 100; the publishing account, limit 200/h · remaining 11. Budget was not a constraint on this run and did not cause the stop.

​
What this receipt does NOT claim

  • No OpenShift or OKD was involved. Unchanged from 2026-09-06.
  • The cluster does not run the entry. Nothing was installed, nothing was synced, no application pod of this release exists.
  • Nothing is said about the release’s quality. This is a delivery-path run.
  • Defects 4, 5 and 7 from 2026-09-06 were not re-tested — they live past the install, and the install did not run. They are neither closed nor reopened.
  • Revocation fail-closed remains unverified, exactly as it was.

​
Final state

The rig is left running, deliberately: it is the environment the install runs against on the day a chart for this release exists.