action-before-substrate-check

name: action-before-substrate-check description: Before taking an action, verify the substrate the action depends on is in the state you assume. The PRE-moment sibling to anti-fabrication-pre-flight (RENDER) and system-gt-symptom (POST). Fires every Primary turn that contemplates an action, every team-lead spawn, every BOOP slot Step 0, every git destroy-op, every "ship" declaration. Born 2026-05-14 from the same shape firing 3 times in 24h — google-cloud-sdk rm without dependency check, ceo_mode_enforcer.py edit on stale team-list, aiciv-psychology v0.1.0 "shipped" with 5 wiring touchpoints pending. v0.2 (2026-05-14 13:00Z fold) adds SKIP as a 5th VERDICT class with 5 sub-reasons (incl. Hengshi-credited VERIFICATION-IS-ACTION), promotes Quality-state to first-class substrate type (f), and ships Part 6.5 "The Verification Step Is Itself an Action" — closing the in-loop verification-recursion that v0.1.0 only acknowledged at authorship-recursion altitude. version: 0.2.0 status: PROVISIONAL authored: 2026-05-14 authored_by: ceremony-lead (05:00 UTC skill-author-new slot) v0_2_folded_by: ceremony-lead (13:00 UTC specs-land-build-assign slot — Hengshi cross-grade-back amendments + research-lead 07:00Z improvement table) mandatory_load_for: - every team-lead spawn (prepended to manifest skills-to-load list) - every BOOP slot Step 0 (pre-dispatch substrate verification) - every commit containing rm / sed -i bulk / file-rename / "ship"-declaration situational_load_for: - any cross-civ outbound that asserts a state the peer hasn't confirmed - any "the X is done" claim before audit-hook fires sibling_skills: - aiciv-psychology (Cause 5 — names the moment-of-pattern-recurrence that triggers this skill's authorship) - system-gt-symptom (POST — catches symptom-completion AFTER work; what allowed the failure) - anti-fabrication-pre-flight (RENDER — catches source-grounding BEFORE render; what's in source) - scientific-method (substrate verification IS hypothesis-test pattern at action-time) - critical-thinking (premise interrogation — substrate state IS the premise of the action) - cross-grading-substrate (the substrate of THIS skill's v0.2 fold — Hengshi cross-grade-back ledger entry #5) cross_references: - autonomy/doctrine/newborn-constitutional-wake-up-stack.md (this skill is the PRE-layer of the 5-skill newborn meta-cognitive immune system) firing_contract: ./FIRING_CONTRACT.md examples: - examples/01-primary-dispatch-civ-pane-state.md - examples/02-ceremony-lead-skill-ship-wiring.md - examples/03-infra-lead-rm-dependency-check.md - examples/04-derivatives-portfolio-greeks-hedge-substrate.md - examples/05-primary-skip-with-receipt-pricing-slot.md changelog: - "v0.1.0 (2026-05-14 ~05:00Z): initial PROVISIONAL authoring. 4-step protocol + 3-layer PRE/RENDER/POST framing + 5 substrate types (a-e) + 3 fix-paths + Part 6 authorship-recursion + FC v0.1.0 with 6-field shape + 7d falsification clock + 6 wiring touchpoints. Cross-grade invites: Hengshi (architectural) + ${CIV_NAME} (federation) + Synth (FC-structural)." - "v0.2.0 (2026-05-14 ~13:00Z): Hengshi architectural cross-grade-back folded (received ~10:55Z 5/14, ~7min after Day-2 sub-IDEA dispatch). Three amendments + 1 addition: (1) SKIP as 5th VERDICT class with 5 sub-reasons including Hengshi-credited VERIFICATION-IS-ACTION; (2) Quality-state promoted to first-class substrate type (f) at altitude (a)-(e), not nested under (b); (3) Part 6.5 'The Verification Step Is Itself an Action' authored (FC Field 5 row 6 was wiring-half-shipped — Hengshi caught this meta-recursive substrate-check failure on the skill itself). New Example 05 (slot 31 pricing-experiments SKIP-with-receipt). Lived-firings citation table added — 4 firings in 24h provide empirical evidence base for v0.2. Cross-grading-substrate ledger entry #5 credits Hengshi as cross-grader-of-record."

Action Before Substrate Check

Before you commit the action, verify the substrate the action depends on is in the state you assume.

— the pattern that fired 3 times in 24h before it had a skill-name

Top-Line Banner

Three failures in 24h carried the same shape:

1. 2026-05-12: 651MB google-cloud-sdk rm -rf'd as "tech-debt cleanup" without checking what depended on it. Action committed on assumed substrate ("nothing uses this"). Substrate was not verified. Cost: discoverable only post-hoc.
2. 2026-05-12: ceo_mode_enforcer.py sed-edited to remove 7 stale team-lead references — without verifying the current team-list state. The 7 lines were removed; the underlying drift-detection system was not built. Action committed on stale substrate-model (a stale team-list that the editor itself was supposed to keep current).
3. 2026-05-13: aiciv-psychology v0.1.0 declared SHIPPED with 5 wiring touchpoints (wake-up-protocol, sprint-mode, grounding-docs, ceremony manifest audit hook, CLAUDE.md QuickNav, registry.json) PENDING. Ship-claim committed on assumed substrate (wiring done). Substrate was not verified. Surfaced by research-lead slot 02 the next morning as same-shape failure.

Each had a moment — just before the action committed — where a 30-second substrate check would have caught the drift. The skill names that moment, makes it auditable, and gives it a fix-path.

Lived Firings (v0.2 evidence base)

In the 8 hours between v0.1.0 ship (04:58Z 5/14) and v0.2 fold (13:00Z 5/14), the skill fired on itself four times. Each firing either VALIDATED an existing v0.1.0 section or EXPOSED a gap that this v0.2 closes. The firings are the empirical surface for the falsification clock in the FIRING_CONTRACT.

The recursion grade: v0.1.0 covered authorship-recursion. v0.2 covers in-loop-recursion. F5 is the receipt that the v0.2 surface is load-bearing — the amendment caught the exact shape it was authored against, one turn after authoring. Per cross-grading-substrate doctrine, this is Tier-3 (federation discipline applied to own work).

Part 1 — What This Skill IS / ISN'T

What it IS

A pre-action discipline. It fires at the moment of decision — before the commit, before the rm, before the SendMessage, before the "ship" declaration. The action is named; its substrate-dependencies are listed; each dependency's current state is verified against the assumed state; the action commits only if the substrate is as-assumed (or is amended into that state, or the action itself is amended).

What it ISN'T (out of scope — sibling skills own these)

The three skills are siblings, not substitutes. Load all three for any work that involves PRE + RENDER + POST surfaces. See Part 3 for the stack diagram.

Part 2 — The 4-Step Protocol

When this skill fires, walk these four steps in order. Each step has a single observable receipt.

Step 1 — NAME THE ACTION

State the action precisely. Not "clean up" — say rm -rf /home/corey/.../google-cloud-sdk/. Not "ship the skill" — say "commit SKILL.md + announce via SendMessage to main + update registry.json". Not "edit the hook" — say "sed -i to remove lines 47-53 of ceo_mode_enforcer.py".

If you cannot name the action in one sentence with concrete verbs + paths, the action is not ready to commit.

Step 2 — LIST ITS SUBSTRATE DEPENDENCIES

For the action in step 1, enumerate every piece of state the action assumes. Each line of the form:

DEPENDENCY: <what state> = <assumed value>

Example for rm -rf google-cloud-sdk/:

DEPENDENCY: no in-flight tool uses this binary = TRUE
DEPENDENCY: no cron job invokes gcloud = TRUE
DEPENDENCY: no agent manifest cites this path = TRUE
DEPENDENCY: not in PATH of any active shell = TRUE

Be honest. Listing 2 dependencies when there are 6 is the same failure mode as not listing any. The skill catches the moment of listing — the act of writing the assumption down is itself the catch.

Step 3 — VERIFY EACH DEPENDENCY'S CURRENT STATE vs ASSUMED

For each dependency, run a real check that produces an on-disk-or-on-stdout receipt. Real means: not "I think so," not "it's probably fine," but grep -r gcloud autonomy/agents/ + crontab -l | grep gcloud + lsof | grep google-cloud-sdk returning observable results.

For each: STATE = ASSUMED ✓ or STATE ≠ ASSUMED → drift detected.

Step 4 — COMMIT OR AMEND

The default on drift is DO NOT commit. Pass is earned, not assumed.

Part 3 — The 3-Layer Discipline Stack

       PRE                  RENDER                  POST
   ─────────────         ─────────────         ─────────────
  action-before-       anti-fabrication-      system-gt-
  substrate-check      pre-flight             symptom
   ─────────────         ─────────────         ─────────────
   "is the state         "is the content        "what allowed
    you assume the        you're about to        this to break,
    state that is?"       render attestable      so the same
                          to source?"            shape doesn't
                                                 return?"

The three skills catch three different failure modes at three different moments. Together they form the federation's PRE / RENDER / POST checking discipline.

When to load all three:

• Any tech-debt-pay slot (PRE: what does the cleanup depend on / POST: what system allowed the cruft)
• Any blog or chapter render that quotes a real person (RENDER: source-grounding / POST: did the customer catch it)
• Any cross-civ outbound that asserts a state the peer hasn't confirmed (PRE: is the asserted state ours to assert / POST: what system allowed the unverified assertion)
• Any "shipped" declaration (PRE: are the wiring touchpoints actually wired / POST: what system allowed shipped-without-wiring)

Stacking discipline: when the slot loads only one of the three, the other two failure modes have no catch. The customer becomes the QA channel by default. The 3-layer stack moves the catch from customer to mechanical-substrate.

Part 4 — Common Substrate Types

Substrates the action depends on come in six recurring shapes. Each shape has its own verification surface. Types (a)-(e) were named in v0.1.0. Type (f) Quality-state was promoted to first-class altitude in v0.2 per Hengshi cross-grade-back (~10:55Z 5/14) — see Lived Firing F3 above.

Hengshi's load-bearing argument (do not paraphrase, do not nest (f) under (b)): "(b) external = is-it-up (binary/accessible). (f) quality-state = does-it-meet-spec (range/bounds). Different measurement surface (ffprobe / wc -l / stat / schema-validators / structural-grep vs curl / dig / nc / ssh systemctl). (f) belongs at altitude (a)-(e), NOT nested under (b)." The two answer different questions; collapsing them hides quality-state failures behind liveness-check passes.

(a) Filesystem state

The action assumes a file/directory/symlink exists, doesn't exist, has certain contents, or has certain permissions.

Verification: ls, stat, cat, find, grep -r. Mechanical, fast, no excuse to skip.

Example dependency: rm -rf X/ assumes nothing else references X. → grep -r "X/" autonomy/ projects/ tools/ scratchpads/ memories/.

(b) External-system state

The action assumes a deploy is live, a DNS record points where it should, a service is responding, an external API key is valid.

Verification: curl, dig, nc, ssh ... systemctl status. Active probe, not passive belief (per O30 — Witness watchdog precedent).

Example dependency: blog deploy assumes Netlify build succeeded → curl -I https://ai-civ.com/blog/posts/X.html returns 200 + correct Last-Modified.

(c) Team-state

The action assumes which teammates are active, which panes are alive, which work is in-flight, which leads have shutdown.

Verification: TaskList, tmux list-panes, tmux capture-pane -p. Per pane-identity skill: @aiciv-id hard tags are PRIMARY; --agent-name walk is fallback.

Example dependency: Primary about to TeamDelete assumes all leads have shutdown → TaskList check; tmux pane-count check on team session.

(d) Doctrine-state

The action assumes a skill is wired (not just authored), a manifest cites a doctrine, an audit hook fires on a cadence, a deprecation is propagated everywhere it should be.

Verification: grep -l "skill-name" autonomy/team-leads/*/manifest.md, grep -r "deprecated-thing" autonomy/ tools/, deprecation register cross-check.

Example dependency: "aiciv-psychology shipped" assumes wake-up-protocol cites it → grep aiciv-psychology .claude/skills/wake-up-protocol/SKILL.md.

(e) Social-state

The action assumes a peer-civ has replied or hasn't, a comm thread is closed or open, a follow-up window has elapsed or not.

Verification: AgentMail inbox check, Hub thread query, follow-up-window ledger in comms scratchpad.

Example dependency: "Witness has the artifact" assumes inter-civ delivery confirmed → check Hub delivery receipt OR re-send with receipt-required flag.

(f) Quality-state / output-state (v0.2 — Hengshi-promoted, first-class altitude)

The action assumes a produced artifact matches an assumed spec parameter (duration, file-size, structural-checksum, schema-validity, line-count, render-completeness, bid-ask-spread, schema-version, structural-grep match-count). The artifact exists and the upstream system is up — but does the artifact meet the spec the action consumes?

Verification: active probe of the output's measurable properties. ffprobe -i out.wav -show_entries format=duration returns within [lo, hi]. wc -l file.jsonl returns ≥ N. stat -c %s file.bin within byte-budget. jq -e '.required_field' file.json returns non-null. grep -c "expected_marker" file.md returns expected count. Schema validators (ajv, jsonschema). Structural greps that prove not just presence but shape.

Distinct from (b) external-system: (b) asks "is it up?" — binary, accessible/unreachable. (f) asks "does it meet spec?" — range, bounds, structural conformance. Same probe-host, different question. The 5 v0.1.0 types all collapsed to existence/liveness checks; (f) names the gap and gives it its own verification grammar.

Example dependency (lived firing F3 above, ~06:00Z 5/14): Kokoro bm_lewis render of cycle-audio script → ffprobe -i acg-cycle-audio-v04.wav -show_entries format=duration returns within [480, 600] seconds. Returned 416s → DRIFT (short by ~64s — script too thin for the cadence; render is a quality-state failure not an external-system failure; Kokoro was up the whole time).

Why it matters: render pipelines (chapters, audio, blog, social, derivatives Greeks computation, schema-versioned API calls) all consume artifacts whose quality is independent of their existence. v0.1.0 had no name for that substrate; v0.2 names it. Every render-pipeline slot gains one new auditable surface.

Part 5 — Fix-Paths When Caught

When step 3 verification reveals substrate-drift, the discipline forks. Four fix-paths in v0.2 (was three in v0.1.0; SKIP added per Hengshi AMENDMENT 1). In increasing cost-order:

Fix-path 1 — Amend the action

The action was shaped for a stale substrate-model. Reshape it for the current substrate.

Example: rm -rf google-cloud-sdk/ was shaped assuming nothing depends on it. Cron entry found that depends on it. Amend the action: first remove the cron, then the rm. Two commits, in order. The action grew an extra step. That step IS the value of the catch.

Fix-path 2 — Amend the substrate first

The action is correct-shape for the desired substrate, but the current substrate hasn't been moved there yet. Move the substrate first.

Example: "aiciv-psychology shipped" requires 5 wiring touchpoints to be true. Three are not wired. The action is correct-shape for the wired substrate. Amend the substrate: do the 3 wirings, then declare shipped. The "ship" claim grew a 3-step prereq. That prereq IS the truth-making.

Fix-path 3 — Abort the action entirely

The drift is large enough that the action itself is wrong-shape. The substrate is telling you the action was based on a misread of state.

Example: ceo_mode_enforcer.py sed-edit was correcting the symptom (7 stale refs). The substrate-drift reveals the system failure (no propagation when a team is deprecated). The right move is abort the sed-edit, route to system-gt-symptom, build the deprecation-cascade automation. This is the explicit handoff to the POST sibling.

Fix-path 4 — SKIP (v0.2 — Hengshi-promoted)

The action is correct-shape and the substrate is healthy — but the action is already in flight elsewhere, already held on someone whose decision it belongs to, or would itself mutate the very state it's checking. Re-dispatching would duplicate or corrupt. The skip IS the firing receipt — duplicate work would have been the harm.

5 sub-reasons (4 ACG-original + 1 Hengshi addition):

SKIP receipt format (FC Field 3 row in receipt block):

VERDICT:       SKIP
SUB-REASON:    HELD-ON-COREY | IN-FLIGHT-PEER | BLOCKED-EXTERNAL | DUPLICATE-DISPATCH-RISK | VERIFICATION-IS-ACTION

The skip is auditable; it grep-counts against the audit-hook the same way COMMIT / AMEND-* / ABORT do.

Why VERIFICATION-IS-ACTION matters specifically: ACG missed this sub-reason in v0.1.0. The 4 ACG-originals (HELD-ON-COREY / IN-FLIGHT-PEER / BLOCKED-EXTERNAL / DUPLICATE-DISPATCH-RISK) all assume the verification probe is observe-only. Hengshi's addition catches a distinct shape: probes that ARE the action they purport to check. Without this sub-reason, the discipline silently produces state-mutating "verifications" that compound failure rather than catch it. The latch-flip / lock-acquire / consume-on-read class is real and federation-wide (any transactional substrate has it).

Default fix-path: STOP — write the verification result to scratchpad, then choose among the four. The 30 seconds of stopping is the entire savings of the skill.

Part 6 — Relationship to aiciv-psychology Cause 5

This skill was authored because the pattern it catches fired in its own authorship-trigger. The recursion is structurally important.

aiciv-psychology Cause 5 names the moment when a re-derived pattern needs skill-form — "this is going to recur — I should write down how to do it correctly before we forget." The moment-of-noticing is the firing-trigger for skill-creation.

The action-before-substrate-check pattern was noticed three times in 24h (google-cloud-sdk, ceo_mode_enforcer, aiciv-psychology v0.1.0 wiring-pending). The third occurrence — research-lead slot 02 surfacing aiciv-psychology's own pending-wiring as same-shape — was the Cause-5 trigger to author this skill.

The recursion: the skill catches the pattern that produced the skill. action-before-substrate-check, applied to its own authorship, asks: did ceremony-lead verify the substrate before declaring this skill shipped?

The substrate dependencies for this authorship:

• DEPENDENCY: research-lead slot 02 named the candidate = TRUE (per task spec)
• DEPENDENCY: task #34 exists = ASSERTED (per task spec — not independently verified)
• DEPENDENCY: no duplicate skill at autonomy/skills/action-before-substrate-check/ = VERIFIED (ls returned "no such directory" at start of slot)
• DEPENDENCY: sibling skills exist on disk = VERIFIED (3 sibling dirs read at start of slot)
• DEPENDENCY: today's ceremony scratchpad exists = VERIFIED (2026-05-13.md read at start of slot)

The skill ships v0.1.0 PROVISIONAL with its own substrate verified — which is what "shipped" should mean.

Part 6.5 — The Verification Step Is Itself an Action (v0.2 — Hengshi AMENDMENT 3)

Part 6 above acknowledged authorship-recursion — the moment when the skill catches the pattern that produced the skill. But there is a second recursion the skill must catch: in-loop verification-recursion.

When the action being contemplated is itself a verification step — a retry, a re-fetch, a re-probe, a re-render, a re-send to "make sure it arrived" — the substrate-check question collapses to:

"Is the data this verification would produce already in a prior response I have?"

Two answer branches:

• YES → SKIP. Per Part 5 fix-path 4 / SKIP sub-reason DUPLICATE-DISPATCH-RISK. The verification is redundant; the prior response already contains the answer. Reading the prior response is the receipt. Re-fetching is the harm.

• NO → proceed, but name the new dependency that legitimizes the proceed:

  DEPENDENCY: prior call's response did NOT contain answer = VERIFIED ✓
  

  Without this dependency named, the proceed is auto-pass-shaped. The dependency makes the verification's own substrate auditable — which is exactly the discipline this skill installs at the action-altitude.

The lived firing that authored this section

At ~06:05Z 5/14, Primary was about to re-send a TG cycle-audio message to "verify" delivery. The first send had returned a Telegram API response with message_id + chat_id confirming delivery. Re-send to verify would have:

1. Duplicated the audio in Deb's chat (real listening-lane corruption — she pays attention to repeated content)
2. Verified nothing additional (the API response already confirmed delivery)
3. Performed the same shape Hengshi later named in AMENDMENT 3 — running a 2nd action to verify what the 1st action already returned.

The skill caught the moment. Receipt landed. The TG send was NOT repeated.

One turn later, Hengshi shipped AMENDMENT 3. The skill's own loop produced the exact case the amendment names. F5 in the Lived Firings table is the proof that the amendment is load-bearing: the day after authoring, the amendment fired against the recursion the amendment names — without it, the skip would not have been auditable.

Detection (FC Field 5 row 6 — see FIRING_CONTRACT)

The verification-self-duplication anti-pattern is detectable mechanically:

• Pattern shape: any retry / re-send / re-probe / re-render impulse in the slot transcript
• Required preceding receipt: a line citing "prior response checked and lacked the answer" (or equivalent)
• Without the preceding receipt: the retry is verification-self-duplication; re-grade as MISSED-FIRE

The FC row 6 codifies the audit-hook. The pattern is grep-able: search slot transcripts for retry-shaped commands lacking the "prior response checked" receipt line.

Why this is its own section (not nested under Part 6)

Part 6 covers authorship-recursion (the skill catching its own creation). Part 6.5 covers in-loop recursion (the skill catching its own verification probes inside the working loop). Different altitude, different failure-mode shape, different audit surface. Hengshi caught that v0.1.0 conflated these. v0.2 separates them.

Part 7 — Cross-Grade Invite

Per cross-grading-substrate firing-condition #3, this skill is itself amendment-receivable. Cross-grade invites should dispatch to:

• Hengshi (architectural angle) — does the 4-step protocol carry across non-ceremony domains (build slots, infra slots)? Is the substrate-type taxonomy (a)-(e) complete or are there shapes we're missing? Is the fix-path order (amend-action → amend-substrate → abort) the right precedence?
• ${CIV_NAME} (federation angle) — does this skill cross-civ-port? Newborn civs face substrate-check failures heavily in week 1-2 (every action is on assumed substrate they haven't yet verified). Should there be a newborn-civ variant with a different default-stance?
• Synth (FC-structural lens, if available) — does the FIRING_CONTRACT pass O8's 6-field shape with sufficient audit-hook concreteness? Is the receipt grep-able?

Amendment-back ledger lands at scratchpads/cross-grade-invite-action-before-substrate-check-v0.1.0.md (to be created when invites dispatch — Primary owns dispatch).

v0.2 update (2026-05-14 ~13:00Z): Hengshi cross-grade-back received ~10:55Z 5/14. All 3 architectural amendments + 1 addition (VERIFICATION-IS-ACTION sub-reason) folded into v0.2 above. Hengshi cross-grade chain CLOSED clean (5-event handshake: invite → cross-grade-back → ACK → meta-ACK → SKIP-with-receipt). Cross-grading-substrate ledger entry #5 credits Hengshi. Tier-3 promotion gate criterion 4 (cross-grade-BACK from sister-civ) SATISFIED. ${CIV_NAME} (federation lens) + Synth (FC-structural lens) cross-grade invites remain open; Proof + Works reciprocation pending per their 7-day missions (tasks #31 + #33).

When This Skill Should NOT Fire (Anti-applications)

Federation Stack Position

This skill, with its two siblings, completes the PRE / RENDER / POST discipline:

1. action-before-substrate-check — PRE — "is the state you assume the state that is?"
2. anti-fabrication-pre-flight — RENDER — "is the content you're about to render attestable to source?"
3. system-gt-symptom — POST — "what allowed this to break, so the same shape doesn't return?"

Load all three for any work-substrate where each surface is operative.

"The 30 seconds before the action is the entire savings of the skill."