What's proven, and where

Each row names the run that proves it. Where nothing proves it, the row says so and links what does exist. Every “proven” cell points at a receipt or a test target you can run yourself. One fact frames all of it: almost everything below was run on Linode LKE, most of it on throwaway clusters, once each. Our own production is the only estate with history that this machinery has touched. Your environment is a different one, and the gaps are where you come in — see running it somewhere new at the bottom.

Install and adoption

What	Proven where	Not yet
Fresh install on an empty cluster	Throwaway LKE, several times: preflight PASS, pinned Argo CD v3.5.1 + Kyverno v1.19.0, subscription synced, 12–13 pods Running on digests, the production pin holding at `UNPINNED` until moved by hand — M2, MVP0, week-exit rehearsal	Any cluster that is not LKE.
A whole production estate pulled onto an empty cluster	Partial. All 115 objects resolved and applied from the channel’s signed artifacts alone, images pulled from the channel and 0 from Docker Hub — clean pull	The estate coming up whole: 16 of 24 workloads reached Running (3 more Completed). Ten findings are written up in that receipt rather than fixed by it, including the published chart defaulting `database.host` to our own production host
Adoption of a live Helm-deployed estate	Twice, on LKE. A throwaway simulation: 18/18 pods kept their UID, 14 Deployments → 14 ReplicaSets, diff before sync was ownership metadata only — throwaway adoption. Then our own production: 36/36 pods kept their UID, 111 ReplicaSets before and after — prod adoption	Any estate that is not ours. The `monitoring` namespace’s own three Helm releases were not adopted in either run. No load was applied during either sync — both numbers were measured on idle estates
Adoption rollback	Pin move forward then back on the adopted throwaway: 17 s and 10 s, 17/17 pods kept their UID	The full exit — delete the Application `cascade=false`, `helm rollback` — is written down and has never been executed

Provider profiles

install.sh has no per-provider branches; a profile is a small profile.env, and each carries a PROFILE_TESTED flag the installer prints on every run.

Profile	Proven where	Not yet
`lke`	`PROFILE_TESTED=yes` — every run on this page	—
`generic` · `aws-eks` · `azure-aks` · `gcp-gke`	Nothing. `PROFILE_TESTED=no`. The per-cluster deltas on EKS, AKS and GKE are read from the vendor’s own documentation	Never run against a real cluster of that kind. The first subscriber’s preflight, smoke and station reports are what changes these lines
`openshift`	Offline only, and grounded: SCC/PSA/LimitRange logic checked against constraints recorded from a genuine MicroShift 4.18 SCC admission rehearsal — 25 chart objects admitted stock, zero SCC rejects, random-UID contexts injected on all 21 pods — plus a subscriber’s own measurements (parity detail)	`install.sh --provider openshift` has never run on OpenShift. One known defect blocks convergence there: `HOME` is absent under a random UID and the minio-init hook fails with `mkdir /.mc: permission denied` (OpenShift)

The delivered software

What	Proven where	Not yet
Preflight P1–P9	PASS on clean clusters, and every failure class seeded deliberately then caught on a throwaway LKE — taints, LimitRange squeeze, PodSecurity, NetworkPolicy, `/dev/shm`, image pull — with the console output kept verbatim beside the M2 receipt	The SCC uid-range logic is unit-tested against an audit fixture, never against live OpenShift admission
Smoke S1–S2 — delivered set healthy, control plane answers	Live on LKE: Synced/Healthy with 13 pods and both APIs answering over operator port-forwards (week-exit), and a full `vexa_validate.py` run producing a PASS smoke receipt on a real cluster (channel hardening)	—
Smoke S3 on Teams — the human loop	Partial. Bot dispatch, the digest-pinned bot image, pod lifecycle and the `ExitReason` reporting are all proven; the join then failed at our own rig tenant’s anonymous-join policy (week-exit)	Capture. No audio has reached the pipeline in any delivery run, on any platform, so nothing here says anything about transcription
Smoke S3 on Google Meet	The link parser is unit-tested (`make test-smoke`)	A live Meet run. No receipt records one
Smoke S4 — flows tier	S4 correctly reports that the flows tier is not in the delivered set, instead of crashing the run as it once did	The tier itself, and the agent/model tier behind it. The question of a model credential has never arisen

The upgrade reporter

kit/report/ is the door for a deployment that already exists. It is fixture-tested end to end and has never read a real estate.

Claim	Proven where	Not yet
The tool itself	46 tests against a fake `kubectl`, where the fixture directory is the estate (`make test-report`)	No receipt records a run against a real cluster
It only reads	Every command a run issues is recorded by the fake `kubectl` and asserted to be `get` or `version`. A source scan fails the build if a database client, any SQL, or a flag taking a password appears	—
`--dry-run` touches nothing	It runs with `subprocess.run` replaced by a raising stub, and is asserted to write no files	—
`--dry-run` tells the truth	The commands it prints are compared against the ones a real run actually executed. A drifting dry run fails the build	—
Redaction	A withheld value that survives into the report exits `3`, naming the count and never the value. Two fields shipped named after secrets and were emptied by the blunt rule; the leak scan caught both, and a test now guards the whole class	A leak found in a real estate

The channel and its guarantees

What	Proven where	Not yet
Signature admission	Against the live channel with stock Kyverno 1.19 holding no registry credential: signed ADMITTED, unsigned DENIED, correct layout with the wrong key DENIED — signature layout, authenticated channel. The day before, the same gate denied a correctly signed release as unsigned (week-exit); that is what these two receipts closed	The policy matches `vexaai/`, so the mirrored third-party images — caddy, redis, postgres, kubectl — are admitted without verification
The in-cluster verify gate	Both directions on a live cluster: ELIGIBLE on a good entry, and NOT ELIGIBLE with the sync held when the station contract required an evidence kind the entry lacked (week-exit)	It was not active for our own production adoption sync — that entry was verified publisher-side instead. And `vexa_channel.py verify` cannot yet verify an estate entry at all (prod adoption)
Entry expiry, revocation, contract clauses	Live against a scratch channel on the real registry, with the stale-entry message deliberately distinct from the signature message (channel hardening)	The deployed verifier, v0.1.1, does not check freshness — so nothing enforces expiry inside a cluster today
Kit bootstrap, verify-before-unpack, self-update	From an empty directory against the live channel with a pull-only credential: the right key unpacks, the wrong key writes nothing at all, a write attempt returns 401. Self-update ran five times in one day, each time verifying before unpacking (week-exit)	—
Mirrored pull	43 images mirrored, every destination digest verified equal to its source twice, the estate then pulled with 0 images from Docker Hub, and blob serving confirmed non-redirecting (clean pull). The pull-through-proxy lane is proven on a Harbor v2.15.2 rig: 9/9 checks through the proxy, wrong key refused (parity detail)	An install on a genuinely disconnected network, as security already states
The station bundle round trip	Once, end to end on the live edge and a real cluster: write-scoping enforced per subscriber at the edge, and redaction exercised on a values file that really did carry live credentials — 7 removed, 0 surviving the post-write scan (channel hardening)	Concurrency, a large bundle, failure injection, a second subscriber
The station gate	In the direction that matters: it refused the real v0.12.23 chart with 8 findings — four dependency images unpinned, two of them on `:latest` — and admits once the upstream fix is applied. The published entry carries the refusal as its evidence (week-exit)	—

Day-2

What	Proven where	Not yet
Pull upgrade	Chart 0.12.31 → 0.12.32 arrived 26 seconds after publish with zero kubectl writes (week-exit)	One measurement, on a two-node cluster with a warm image cache. It says the transport works unattended; it is not a latency figure
Rollback by pin	On the adopted throwaway: back in 10 s, every pod kept its UID (throwaway adoption)	On our own production, or on any estate under traffic. Two steps back is a data restore and has not been rehearsed
Scale, upgrade under load, failure injection, break-glass	Nothing	Stated here once so that no row above is read as implying it

The from-docs run, 2026-08-27

A fresh anonymous clone, on a throwaway Linode cluster provisioned for the purpose, following Install and Upgrade as written.

What	Result
Anonymous `git clone`, then the reporter’s `--dry-run`	ran, exit 0
Preflight on a never-before-seen cluster (LKE, Kubernetes v1.35.7)	PASS, all nine checks
`install.sh` — pinned Argo CD v3.5.1, pinned Kyverno v1.19.0, both ClusterPolicies, the ApplicationSet, both Applications	installed
Staging synced chart `0.12.35`; production created and parked at `UNPINNED`	as documented
Postgres, Redis and MinIO admitted and Running under the admission policy	Running
The state reporter against that live deployment	one `state-report.yaml`, 270 lines, exit 0 — the example on the upgrade page is that file
Vexa’s own images admitted	denied — see below

Two defects the fixtures could not have found, both fixed the same day. Node capacity printed as 8138636Ki, and because the grouping key carried that exact figure, two identical machines appeared as two shapes — on a fifty-node cluster that is fifty rows instead of one. Capacities now round to 7.8Gi and identical nodes group. And one that mattered more. Run with the install command the docs carried that morning, every Vexa image was refused by our own policy — no signatures found — because without --signature-repository the installer strips the repository line from the admission policy and Kyverno looks for signatures beside the image on Docker Hub. The cluster installs clean, Argo reports Healthy, and not one Vexa pod is admitted. The flag is now in the documented command, in install.sh --help, and in the onboarding template. With it set, the signatures are found; verifying them needs the channel’s public key, which the operator holds.

Known gaps, and the issue each one lives in

Stated so you can pick one up, not so we look complete.

Gap	Issue
The free channel does not exist. Every channel is credentialed; the landing’s step 3 describes a service that is not running.	#9
Required values are documented, not enforced. A deployment missing its transcription configuration reports Synced and Healthy and cannot dispatch a bot; the contract should refuse it instead.	#6
Only Linode LKE is exercised end to end. Every other provider profile is declared and never run.	per-provider pages
No audio has reached the pipeline in any delivery run. The smoke step is implemented and never completed on any platform.	—
The docs gate depends on the Python patch release. `gen-cli-reference --check` can disagree with itself between 3.12 patches; the pin is minor-only.	—

Running it somewhere new

Running this in an environment nobody here has seen is the contribution. A row moves from not yet to proven when someone posts the artifacts that make it true, and most of those artifacts are things a normal install produces anyway:

The station report. vexa_validate.py writes station-report.yaml — one commented file carrying your provider profile, your values with every secret-shaped value replaced by REDACTED, the contract, and the preflight and smoke receipts, each with the sha256 of its own text. Read it, then send it. That report is exactly what a PROFILE_TESTED=no line is waiting for.
What broke. Open an issue with the preflight output and the refusal message. Half the findings on this page arrived that way — from a run that failed, not one that passed.
A patch. The reporter takes a new collector as one function; a provider profile is one small profile.env. Everything is Apache-2.0, inbound and outbound.

Commits carry a DCO sign-off — git commit -s, name and email your own. The whole of it is in CONTRIBUTING.md, and it is two things: the license and the sign-off. Next: Install · Upgrade · Environments · Verify

Start

1 · Install

2 · Subscribe to the channel

3 · It updates itself

Reference

Not yet published

What's proven, and where

Install and adoption

Provider profiles

The delivered software

The upgrade reporter

The channel and its guarantees

Day-2

The from-docs run, 2026-08-27

Known gaps, and the issue each one lives in

Running it somewhere new

​Install and adoption

​Provider profiles

​The delivered software

​The upgrade reporter

​The channel and its guarantees

​Day-2

​The from-docs run, 2026-08-27

​Known gaps, and the issue each one lives in

​Running it somewhere new

Install and adoption

Provider profiles

The delivered software

The upgrade reporter

The channel and its guarantees

Day-2

The from-docs run, 2026-08-27

Known gaps, and the issue each one lives in

Running it somewhere new