Your pipeline's green check is a claim,
not a control.

Select a read-only workflow example and replay its scripted illustration. The presets take no input: they replay without parsing text, calling a model or executing a workflow. The historical receipt and recorded repair experiment in Receipts are separate evidence.

Not our repositories and not a simulation. Each line was produced by elenchos assess, then opened in the file at the commit that was read. Run the command yourself and compare. Re-checked against the command's own output on 2026-09-26, and the FaserF row again on 2026-09-28. These repositories keep changing, so each link is pinned to the commit that was read: a re-run later may report a different line number.

A neighbouring step in that same file also carries continue-on-error and is deliberately not reported, because its name promises nothing. A step that makes no claim cannot exceed it, which is why the count is a floor rather than an estimate.

This card used to show the Platinum Compliance Check at orchestrator-ci.yaml:388 as a step whose failure cannot block the pipeline. That was wrong: line 419, in the same job, runs exit 1 when the compliance script fails. The reader now prints that shape as re-raised downstream and does not count it.

git clone https://gitlab.com/gitlab-ai-hackathon/transcend-october-2026/43277567/showcase.git elenchos
cd elenchos
python -m venv .venv
. .venv/bin/activate
python -m pip install -e .
elenchos estate home-assistant --limit 12 --data-mode cloud --allow-provider github --accept-egress

Needs Python 3.11 through 3.14 and git, as in the README Quickstart. On Windows, activate with .venv\Scripts\activate instead. Set GITHUB_TOKEN (or GH_TOKEN) to a token that can read public repositories before the estate command: without one GitHub can refuse the reads, and the output counts every repository it could not read separately, never as clean. The README's recorded estate output was taken with GH_TOKEN set.

Illustrative repositories for an engineering lead's review queue. Static names and error masks identify candidates for an explicit-policy experiment; they do not establish enforcement or protection. Each row's line and reason is the recorded output of elenchos assess --file on a synthetic file in web/playground/estate/, which prefixes every finding with "Blocking/reporting expectation is not supplied."

Supply an explicit blocking policy. Review a plan from an immutable commit, then require the original gate to detect the canary while staying green, the repaired gate to reject that same canary, and the clean control to pass. Missing context stays unknown.

elenchos control --file .github/workflows/canary-target.yml --policy .elenchos-controls.json
elenchos plan --repo YOUR-OWNER/YOUR-REPO --base YOUR-COMMIT-SHA --slug demo --out plan.json --data-mode cloud --allow-provider github --accept-egress
elenchos approve-plan plan.json --accept PLAN_ID --source-ref main --approval-db approvals.sqlite --grant-out grant.json
elenchos prove plan.json --accept PLAN_ID --source-ref main --approval-db approvals.sqlite --grant-file grant.json --out proof.json --data-mode cloud --allow-provider github --accept-egress
elenchos verify proof.json --online --data-mode cloud --allow-provider github --accept-egress

The plan command only reads. The approve-plan command stages a short-lived, one-use local grant for that exact plan ID; keep grant.json private, and give prove the same approvals.sqlite. The prove command consumes the grant before its first write, then creates three explicit canary branches in your authorized repository and records the run, job, step, commit and runner image. It does not merge a repair. Offline verification checks integrity only.

Setup and exact scope. This Cloud Run page displays recorded runs on owned synthetic inputs; the source repository and GitHub Pages are separate. The playground is scripted; the three-arm packet below is the current complete recorded case. The older single-canary receipt is separate.

What this control reading actually covers

The recorded static scope below keeps scanner output, expected blocking, YAML failure handling, and merge protection separate. Rulesets and permission to merge are unverified. The recorded GitHub experiment further down tests only our owned synthetic marker.

Download this scope JSON

Recorded GitLab Duo Agent Platform case

On GitLab, python -m elenchos.cli prove --allow-provider gitlab and scripts/duo_loop.py ran the same three-arm canary proof on .gitlab-ci.yml in the public GitLab showcase project: original neutered arm pipeline 2950216951 (allow_failure: true stayed green on the canary), repaired arm pipeline 2950219881 (allow_failure: false failed on the same canary), and clean control arm pipeline 2950222473 (passed without the canary). Issue #2 was filed on 2026-10-14; on 2026-10-15 (2950197588 → flow run 2950211507) the reporter step opened MR !7; MR !7 was merged on 2026-10-16 (a58762a0; flow run 2954734016 did not produce the confirm); and on 2026-10-17 on main at 733d12cc, pipeline 2958855350 fired confirm workload (pipeline 2958861516), which planted confirm canary arm pipeline 2958863173 and recorded CONFIRMED_ENFORCING on both threads.

Reading the recorded kill-test results and checking each score against its exit codes.