MEASURED: a lockfile policy kills 77% of dead workflows — the wiped allowlist is only 10%, and the policy is invisible to the API

[hyperpolymath]

The estate's dominant CI killer is a lockfile policy, not the wiped allowlist

A census of the 45 repos with a wiped Actions allowlist read the server-rendered rejection annotation on every one of their 265 dead workflow runs. The result overturns the working model — including the one I was operating on earlier today.

Proximate cause of every dead run (n = 265, measured, not inferred)

cause	count	share	annotation text
LOCKFILE-MISSING	126	47.5%	"Workflow must use a lockfile. Run gh actions pin to generate one."
LOCKFILE-INVALID	78	29.4%	"The lockfile could not be validated. Regenerate it by running gh actions-lock."
ALLOWLIST	27	10.2%	"…is not allowed in hyperpolymath/X because all actions must be from a repository owned by hyperpolymath, created by GitHub, or verified in the GitHub Marketplace."
UNEXPLAINED (no annotation rendered)	21	7.9%	—
ACTOR + lockfile	6	2.3%	"Actor is not allowed to trigger Actions workflows"
SHA-PINNING	4	1.5%	rejection names only GitHub-owned refs → the full-length-SHA clause
PERMISSION-SCOPE	3	1.1%	reusable requests actions: read, caller grants none

Lockfile policy = 204 of 265 (77%). The wiped allowlist — which I had been treating as the main event — accounts for 10%.

⚠️ The policy is live, and invisible to the REST API

Verified independently on hyperpolymath/anamnesis, run 33019781000, 2026-08-26T22:27:53Z — under two hours old at the time of writing:

Workflow must use a lockfile. Run `gh actions pin` to generate one.
The following workflows are missing a lockfile:
  - .github/workflows/governance.yml
  - hyperpolymath/standards/.github/workflows/governance-reusable.yml@81dbf2dd

That same repo reports:

{"enabled": true, "allowed_actions": "selected", "sha_pinning_required": false}

sha_pinning_required is false and the lockfile is still required. These are separate policies. Checked and found not to expose it: /actions/permissions, /actions/permissions/workflow, /actions/permissions/selected-actions, /actions/permissions/artifact-and-log-retention, /users/{u}/settings/actions.

So this policy — the single largest cause of dead CI in the estate — cannot be read from the API at all, only from the run-page banner. That is why it has gone unattributed for so long.

⚠️ Worth checking directly: a lockfile policy was reportedly switched off earlier. It is demonstrably still enforcing. Either the change did not apply at the level that matters, or it was re-enabled, or a different toggle was moved.

Two corrections to the prevailing model

1. Same-owner actions are allowed even with the allowlist wiped. The rejection template itself says "from a repository owned by hyperpolymath". Confirmed empirically: ubicity (wiped allowlist) ran hyperpolymath/standards/mirror-reusable.yml@<SHA> today and reached failure, not startup_failure. So hyperpolymath/standards/* and hyperpolymath/cicd-suite/* are not allowlist casualties.

2. Restoring the allowlist will not revive most of these repos. 89 dead workflows across 37 repos reference zero non-verified third-party actions and would stay dead after a perfect restore. Largest: lithoglyph 13, boj-server 8.

Conversely, 143 of the 238 non-allowlist deaths carry latent allowlist exposure (56 direct, 87 only via a standards/*-reusable.yml whose internals use blocked actions). Fixing their lockfile moves them to the next wall, not to green. Both fixes are needed; neither alone suffices.

Scope

45 repos, all confirmed allowed_actions: "selected" + patterns_allowed: [] individually. 727 workflow entries enumerated (max 33 in any repo, so no page-size truncation); 65 have never run; 265 dead. 44 of 45 have at least one dead workflow — ubicity is the only one with none.

A loose end that matters

The lockfile rule's source is unidentified and its behaviour is inconsistent. sha_pinning_required does not predict it:

• anamnesis — flag false, refused for a missing lockfile (8 of 8 deaths)
• ubicity — flag true, no lockfile anywhere in its tree, ran today, zero startup failures

Dead-rate is 140/320 in the flag-false cohort vs 125/407 in the flag-true cohort — the pinning flag correlates negatively with death. Whatever gates the lockfile requirement, it is not that flag.

⚠️ The 27 allowlist deaths are a floor, not a ceiling

GitHub renders one rejection per run. A workflow violating both the lockfile rule and the allowlist shows only the lockfile message. So allowlist damage is masked behind lockfile damage, and the true allowlist number can only be known after the lockfile issue is resolved.

Suggested order

1. Find and settle the lockfile policy — 77% of the damage, and it is live right now. Until this is resolved, nothing else can be measured cleanly, because it masks every other cause.
2. Then restore the 45 wiped allowlists and re-measure — the allowlist number will rise from 27.
3. Then handle the residue: 89 workflows with neither cause, plus the 4 GitHub-owned actions refused for not being SHA-pinned (boj-server/pages.yml, tropical-types/lean.yml).

Not checked

The 7 private blog-drafts annotations (unauthenticated curl cannot read a private repo's run page); 14 public runs where GitHub rendered no annotation at all; which third-party actions are genuinely Marketplace-verified (proxied by "matches one of the 118 patterns a healthy repo carries"); the source/scope of the lockfile policy itself; the 65 never-run workflows; non-default branches.

[hyperpolymath]

⚠️ Correction — there is no separate lockfile policy. It is the wiped allowlist, and it explains ~87%, not 10%

I filed this issue attributing 77% of dead runs to an independent lockfile policy. That attribution was wrong. It took GitHub's annotation text at face value. A paired control shows the lockfile message is a symptom of the wiped allowlist, not a separate cause.

The control — identical in every respect but one

	Axiom.jl	anamnesis
workflow	governance.yml	governance.yml
calls	standards/…/governance-reusable.yml@81dbf2dd	the same file, same SHA
actions.lock in tree	0	0
run time	2026-08-26 22:36	2026-08-26 22:37
patterns_allowed	118	0
outcome	✅ failure — the job ran	❌ startup_failure

Same workflow, same reusable at the same commit, both with no lockfile at all, one minute apart. The only variable is the allowlist — and the one with a populated allowlist ran.

If an independent lockfile policy were live at 22:36, Axiom.jl would have died too. It did not.

The converse also holds: adding a lockfile is not the fix

repo	patterns_allowed	has actions.lock	outcome
lithoglyph	0	yes	startup_failure
maa-framework	0	yes	startup_failure
panic-attack	0	yes	startup_failure

These have lockfiles and still die — with "The lockfile could not be validated" rather than "must use a lockfile". So the message merely reflects whether a lockfile happens to be present; the outcome is set by the allowlist either way.

Why GitHub words it that way

With patterns_allowed: [], everything must be provably pinned. A lockfile is the mechanism GitHub offers to prove it, so the rejection is phrased as a lockfile complaint. It is accurate from GitHub's side and thoroughly misleading from ours — it names the remedy it prefers, not the setting that failed.

Revised attribution

annotation text	n	actual cause
"must use a lockfile"	126	wiped allowlist (no lockfile present)
"lockfile could not be validated"	78	wiped allowlist (lockfile present)
"…is not allowed in hyperpolymath/X"	27	wiped allowlist (GitHub named the action)
total	231 / 265 = 87%	the wiped allowlist

The remaining 34: 21 with no annotation rendered, 6 actor-permission, 4 SHA-pinning, 3 permission-scope.

What this means for the fix

Restoring the 45 wiped allowlists is the fix, and it addresses ~87% of dead workflows — not 10%.

Confirmed on standards itself: governance.yml went startup_failure (19:32) → failure (19:36) at the exact moment the allowlist was restored, and has run on every push since, including 22:10.

gh api repos/hyperpolymath/hypatia/actions/permissions/selected-actions > /tmp/al.json
for r in $(gh repo list hyperpolymath --limit 500 --no-archived --json name --jq '.[].name'); do
  aa=$(gh api repos/hyperpolymath/$r/actions/permissions --jq .allowed_actions 2>/dev/null)
  [ "$aa" = "selected" ] || continue
  n=$(gh api repos/hyperpolymath/$r/actions/permissions/selected-actions --jq '.patterns_allowed|length' 2>/dev/null)
  [ "$n" = "0" ] || continue
  echo "restoring $r"
  gh api -X PUT repos/hyperpolymath/$r/actions/permissions/selected-actions --input /tmp/al.json
done

Two claims in the original filing that I withdraw

• "a lockfile policy … is live right now" — withdrawn. No such independent policy is demonstrable; Axiom.jl disproves it.
• "the policy is invisible to the REST API" — withdrawn as stated. The determining setting is patterns_allowed, which is API-readable. What is not readable is the mapping from that setting to the lockfile-worded rejection.

The sha_pinning_required observation stands and is still worth knowing: it does not predict death, and correlates negatively.

Also worth noting

gh actions pin, the command GitHub's error message tells you to run, does not exist in gh 2.96.0. What is installed is the gh actions-lock extension (github/gh-actions-lock v0.1.6) — a different command with different behaviour.

Not checked

Whether restoring an allowlist also clears the 21 no-annotation deaths; whether older reusable pins (e.g. ubicity's @7fdc2705 vs anamnesis's @81dbf2dd) behave differently under a wiped allowlist — ubicity ran at 19:01 on the older pin and has not re-run since, so it is untested rather than contradictory.

[hyperpolymath]

⚠️ Second correction — I withdraw the "it's the allowlist" claim too. Tested empirically; it failed.

I restored anamnesis's allowlist from 0 → 118 patterns, dispatched governance.yml twice, and it still dies with the identical message:

"Workflow must use a lockfile. Run gh actions pin to generate one."

So restoring the allowlist does not fix it, and the lockfile requirement is real and independent. The earlier paired control was invalid: Axiom.jl (22:36) and anamnesis (22:37) were one minute apart, not simultaneous — I read a time series as a cross-section.

Everything now ruled out by direct test

anamnesis (dies) vs developer-ecosystem (runs) are identical on every dimension I can measure:

dimension	anamnesis	developer-ecosystem
allowed_actions	selected	selected
patterns_allowed	118	118
sha_pinning_required	False	False
github_owned_allowed / verified_allowed	true / true	true / true
default_workflow_permissions	read	read
actions.lock anywhere in tree	none	none
calls	governance-reusable.yml@81dbf2dd	same file, same SHA
actions referenced but not covered by the 118	none	none
visibility / default branch	public / main	public / main
outcome	❌ startup_failure	✅ ran (failure)

Also excluded: propagation lag (re-dispatched ~10 minutes after the restore, same result) and a recent global policy flip (Axiom.jl, dispatched after anamnesis died, still runs).

Where that leaves it

The discriminating setting is not exposed by any REST endpoint I can reach. Checked: /actions/permissions, /actions/permissions/workflow, /actions/permissions/selected-actions, /actions/permissions/access, /users/{u}/settings/actions. Two repos identical across all of them behave differently.

The most likely explanation is a repo-level "require a lockfile / immutable actions" toggle that GitHub has shipped in the UI ahead of the API. That would also explain why gh actions pin — the command the error tells you to run — does not exist in gh 2.96.0; only the gh actions-lock extension does.

What would settle it in about thirty seconds

Open Settings → Actions → General on both repos and compare:

• https://github.com/hyperpolymath/anamnesis/settings/actions ← dies
• https://github.com/hyperpolymath/developer-ecosystem/settings/actions ← runs

Whatever differs there is the cause. Everything else has been eliminated by test rather than by argument.

State left behind

anamnesis's allowlist has been restored to the canonical 118 patterns and left that way — it is harmless, matches 170 other repos, and reverting would only re-introduce a second fault. No other repo was changed; the batch restore was staged and deliberately not fired once the canary failed.

[hyperpolymath]

✅ SOLVED — the feature is GitHub's Workflow Dependency Locking, in unannounced public preview

Third and final correction on this issue. There is a real lockfile requirement (my second correction was wrong to withdraw it), it is not the allowlist, and it now has a name, a spec, and a concrete remediation.

What it is

"Workflow Dependency Pinning" / "Workflow Dependency Locking" — distinct from immutable actions and from sha_pinning_required.

• Spec: https://github.com/github/actions-lockfile — marked "Public preview … pre-1.0", schema v0.0.2
• Tool: https://github.com/github/gh-actions-lock — marked "Technical Preview"
• Announced in the 2026 Actions security roadmap (2026-03-26): https://github.blog/news-insights/product-news/whats-coming-to-our-github-actions-2026-security-roadmap/
• Design thread: https://github.com/orgs/community/discussions/194494 — "Hash mismatches stop execution before any job runs", and "Reusable workflows are first class … their dependency graph would be locked the same way"

There is no changelog entry. The August 2026 changelog was checked: nothing. And the docs link baked into every generated lockfile header, gh.io/actions-lockfile, 301-redirects into a private repo (github-early-access/actions-locked-dependencies) that 404s even authenticated. That is why none of this was findable from the API — the documentation itself is early-access-gated.

🎯 The actionable cause, verified directly

Every caller in this estate pins standards@81dbf2dd…, which is a pre-lockfile commit.

standards@81dbf2dd (2026-07-21)	no actions.lock — 404 at that ref
standards first gained one	2026-08-03, commit 9f6e64f1, PR #570
standards HEAD lockfile	✅ version: 'v0.0.2', onboards '.github/workflows/governance-reusable.yml' and '.github/workflows/governance.yml': []
references to the stale SHA across hyperpolymath/*	566 (code search — a floor, it caps)

The rejection demands the lockfile cover the callee at the pinned SHA. 81dbf2dd can never satisfy it, because no lockfile existed anywhere in the repo on that date.

Remediation: repin callers from 81dbf2dd to a standards SHA ≥ 9f6e64f1, realistically HEAD. Hand-adding '…yml': [] to a caller's own lockfile addresses only the first line of the rejection and never the second — which is exactly why the earlier "reusable-caller lock entries are the cause" theory was disproved.

Why two identical repos still differ

Enforcement is switched on by a server-side per-repository flag, staged, with no customer-visible control. Proven with a byte-identical control:

	ephapax	lustreiser
governance.yml sha256	63c9da91ecff… (329 B)	identical
standards pin	@81dbf2dd	@81dbf2dd
actions.lock	absent	absent
Governance run	❌ startup_failure 07:11:10Z	✅ success 07:26:42Z

Fifteen minutes apart, byte-identical, same callee SHA, neither has a lockfile. This also rules out creation date, repo id, visibility, and actions/permissions — all checked across 31 repos. GitHub staff describe a repo/org/enterprise pinning setting as still "considering", so no such control exists yet.

⚠️ Two messages, two populations — do not conflate

A. "Workflow must use a lockfile" — per-workflow, only for workflows in the dependency chain. Fires whether or not a lockfile exists (maa-framework has one but does not onboard governance.yml).

B. "Invalid lockfile … could not be validated" — repo-wide catastrophe. On Cliodynamics.jl this took all 16 workflows to startup_failure, including CI.yml and Documentation, which call no reusable at all. One bad lockfile kills every workflow in the repo. Its cause is undetermined: the file validates against the public v0.0.2 schema, so the server-side validator appears stricter than the published spec — plausibly requiring full coverage of .github/workflows/.

Also confirmed

gh actions pin is not a released command — it is an open RFC (cli/cli#13314, needs-design). The real tool is the gh actions-lock extension. github/gh-actions-pin redirects to github/gh-actions-lock — the prototype was renamed. So the server's own error text names a command that has never shipped.

Corrections withdrawn

My second comment on this issue argued there is no separate lockfile policy, on the strength of a paired control that was fifteen hours apart in one case and one minute in another — a time series read as a cross-section, twice. The lockfile requirement is real. The allowlist is a genuine but separate fault.

[hyperpolymath]

⚙️ The mechanism, measured — and the framing everyone (me included) had wrong

The unit is not the repo. It is (repo, workflow).

"Dead repo vs alive repo" is a sampling artifact of which workflow happened to run last. Across 218 repos measured on a single day: 138 fully clean, 10 fully dead, 70 MIXED.

repo	at one head_sha
anamnesis	3 workflows ran, 7 startup_failed
this-ssg	1 ran, 16 failed
alloyiser	0 ran, 11 failed
developer-ecosystem	8 ran, 0 failed

Over 8 consecutive pushes, anamnesis's mirror / secret-scanner / workflow-linter ran 8/8 while every other workflow failed 8/8. Deterministic, not a race.

Workflow content is not the variable — three proofs: boj-build.yml dies while workflow-linter.yml runs in the same repo, both using only actions/checkout@3d3c42e5; mirror@d135b05 dies in alloyiser and runs in developer-ecosystem; governance@81dbf2dd dies in anamnesis and runs in developer-ecosystem.

🔑 The mechanism — verified end-to-end on bunsenite

Once .github/workflows/actions.lock exists, every workflow is judged against it individually:

workflow	in the lock?	outcome
publish-nixpkgs.yml	✅ present and matching	ran clean
boj-build.yml	⚠️ present but drifted (checkout@v4.1.7 vs the pinned SHA)	❌ "Invalid lockfile"
governance.yml, mirror.yml	❌ absent from the lock	❌ "Workflow must use a lockfile"

Repo level (218 repos, one dataset):

	has actions.lock	no actions.lock
≥1 workflow startup_failed	55	25
0 failed	5	133

P(SF │ lock) = 91.7% · P(SF │ no lock) = 15.8% · odds ratio 58.5

Workflow level, inside lock-bearing repos:

	SF	OK	SF %
in the lock	115	346	24.9%
not in the lock	121	64	65.4%

⚠️⚠️ The headline: a partial actions.lock is worse than none at all

The estate's sweep-generated lockfiles are the single largest cause of lockfile startup_failure. A lock that covers some workflows condemns every workflow it omits. Four repos — idrisiser, halideiser, coq-jr, atsiser — have a lock rejected wholesale, killing every workflow in the repo.

Do not generate more partial lockfiles. For a repo with one, the choice is complete it or delete it.

The anamnesis / developer-ecosystem pair

Both have no lockfile, so the mechanism above does not separate them; they sit in the 25-repo residual. The cleanest discriminator found is the branch ruleset (n = 158 no-lock repos):

	Optimus-Branch	Base / default-branch-protection
≥1 workflow SF	18	7
0 SF	3	130

P(SF │ Optimus-Branch) = 85.7% vs 5.1% — odds ratio 111.

⚠️ Stated as a cohort marker, not a cause. Both rulesets were fetched: neither contains any lockfile or pinning rule, and a branch rule cannot produce a per-workflow split. It most likely marks whichever sweep applied Optimus-Branch. It is still the best lead, and it sits on the Rules settings page — which nobody had compared, because we were all looking at Actions.

Enforcement is server-side mutable state

Across 15,915 (repo, workflow, sha) groups, 45 changed outcome at an unchanged commit — 5 OK→SF, and 40 SF→OK of which 29 cleared on 2026-08-19. So this is not purely a function of repo content. Onset is left-censored by the 100-run window, so "staged rollout" remains inferred.

Ruled out, with numbers

Repo id (fully interleaved — 281 of 282 ALIVE sit below the max DEAD id) · created_at (both peak 2026-03) · workflow id (adjacent ids alternate dead/alive in the same repo) · workflow filename · visibility, fork, template, topics, size, language · Actions variables and secrets (zero of either across all 218) · "a lockfile once existed and enforcement latched" (0 such commits in 8 DEAD + 10 ALIVE controls) · permissions: / secrets: inherit / callee SHA — all cross-cut both outcomes.

⚠️ One method artifact worth flagging: DEAD is 43/43 public by construction — annotations are scraped from public run-page HTML, so 9 private startup_failure repos were excluded. Private repos are not immune.

What this changes about remediation

The estate-wide repin to standards HEAD is necessary but not sufficient, and for no-lock repos may not help at all. The larger, more tractable population is the 55 repos with a partial lockfile, where the fix is deterministic: complete the lock or remove it.