diff --git a/aips/AIP-22.md b/aips/AIP-22.md
index ed7d790..75a399a 100644
--- a/aips/AIP-22.md
+++ b/aips/AIP-22.md
@@ -233,6 +233,7 @@ Every activation height here is a coordinated fork: the same binary and the same
 - **Note added 2026-10-07 (how the tail is counted).** The bullet above counts the blocks above an anchor: "up to 127 blocks" for the 128-block interval in force when it was written, "31 blocks" for the 32-block interval; Motivation (1) ("up to 127 blocks") and the negative control of section 4 rule 4 ("a classical-only fork of up to 31 blocks") count the same way. `SPEC.md` 3.1 and the threat-model page ("at most 32 blocks") count the anchor block too: 32 and 128 for the same sets of blocks; the derivation below counts the anchor block because it is replaceable (its certificate is about its parent). With the exception of the Errata entry of 2026-10-01 (honest validators sealed an undecided sibling of the latest anchor's parent, at least as many of them as the node's effective threshold `K_eff`, since this adversary holds no post-quantum key), one block more can be replaced: 33 since block 20,746,736 and 129 in the dated 128-interval window (blocks 17,225,968 to 20,746,736, 2026-09-05 to 2026-09-29); the latest anchor's grandparent and everything below it are kept in every case. The derivation and its machine-checked model are `aere-research/research/rewrite-bound-round-free-seal-2026-10-07.md` and `aere-research/formal-consensus/anchor_rewrite_bound_roundfree_smt.py` (13 proofs with 8 negative controls; `--plant-bounds`, which lowers every claimed bound by one, fails exactly the ten bound proofs). The bound is stated for a node that holds the honest chain to its head, or a reference anchor (a recent anchor's height and hash): in both cases only the tail above the latest anchor's parent (grandparent, with the exception) is rewritable, and with a reference everything through it is kept whatever the length of the alternative; without one, a node syncing from genesis can be served a history that stops before an anchor, at any height, and cannot tell that the honest chain is longer (rule 5 of section 4 and the "Weak subjectivity" bullet below, read with this limit).
 - **Correction added 2026-10-09 (to "After `H_id`" in the bullet "What this AIP achieves against that adversary, per height").** On chain 2800, where `H_id` is active from block 20,836,228, "cannot ... vote, or propose in any set" holds at the nine validators that run the primary client, which refuse all four message types without a valid seal. At the second client it holds only for commits until stage 4 (`H_fin`, whose height is not yet set on chain 2800): until then this adversary can present proposal, prepare and round-change messages in another validator's name to the second client. Alone, that misleads one validator of ten, below `f` = 3, whose own commits stay sealed with its own key; combined with `f` Byzantine validators, the misled second client would count as one more faulty node, and that case is not analyzed. "Today: cannot finalize a block online" stands: every validator refuses a commit without a valid seal. See the Errata entry of that date.
 - **What it does not achieve.** Node-to-node transport (RLPx) is authenticated by secp256k1; an adversary with node keys can impersonate a peer, not a validator. A post-quantum handshake (ML-KEM) is a separate AIP. Nothing here is audited by a third party; AIP-15's external-audit gate applies before `H_fin` on chain 2800. The set is ten validators operated by one party; this AIP changes what a key can do, not who holds the keys.
+- **Correction added 2026-10-11 (to "AIP-15's external-audit gate applies before `H_fin` on chain 2800" in the bullet above, to the external-audit condition in the Ratification row, and to "external audit of stages 1 to 4 before the mainnet height" in item 4 of the planned artifacts).** Since 2026-09-30 the external audit is not a precondition of the chain 2800 heights of this AIP: it is scheduled after the remaining stages, and stages 4 (`H_fin`) and 5 (`H_hdr`) are activated on chain 2800 after testnet 28001 with both clients validating and an internal adversarial review of each consensus change, which is not a third-party audit. The sentence "Nothing here is audited by a third party" remains true until an audit report is published, and a reader should weigh the stages activated before it accordingly. The rows and items named above are kept as they were written.
 - **Hybrid conjunction.** A certificate is valid only with the quorum of every required scheme; forging it needs both a lattice break (Falcon-512) and a hash-function break (SLH-DSA-SHA2-128s) at dual-assumption anchors, and a lattice break alone at the intermediate Falcon anchors. The single-assumption window is at most 32 blocks by design, and the founder can shorten it at the cost in the table.
 - **Liveness tax at K = Q.** With f validators down, an anchor needs every remaining seal to reach its proposer in time; a proposer without them skips by round change. The measured pre-AIP rate is 12 of 12 anchors at round 0; the post-AIP rate is a testnet gate. The threshold guard's warning text is the operator's acknowledgment of this trade.
 - **Rollback of a provisional tail.** New behaviour for a QBFT client, bounded at 32 blocks, exercised on the testnet with a negative control before any mainnet height. A bug here is a liveness bug on readers, never a safety bug: nothing becomes final without a certificate.
@@ -250,6 +251,7 @@ Nothing described here exists at the Created date. Planned artifacts, each landi
 2. Stage 2, `H_I`: `aere.pq.schemeIntervalSchedule` in `PqAnchorConfig` and the producer, `AERE_PQ_SCHEME_INTERVAL_SCHEDULE` in the Nethermind engine and header validator, `SCHEME_INTERVAL_SCHEDULE` in the public verifier, the disk gate reading per-scheme intervals, the z3 model of the interval schedule extended to per-scheme grids; negative control: a hybrid-required anchor carrying only Falcon is refused, a Falcon-only anchor missing at a 32-grid height is refused.
 3. Stage 3, `H_id`: registry v3 (`PqRegistryHash` v3 pre-image and Merkle root, loader, `PqRegistryBinding` rotation and per-scheme possession proofs), `id` derivation, set translation at `H_id`, authorship by row, forwarding predicate, the `formal-consensus` registry models extended (`registry_rotation_coverage_smt.py`, `registry_index_binding_smt.py`) with the rotation chain; the v3 manifest tooling under `chei-falcon/` producing the epoch from the keys already on the validators (no new key material); the public manifests index gains the v3 epoch in the same hour.
 4. Stage 4, `H_fin`: the canonical rule, the provisional tail and its rollback in both clients, the checkpoint option, the reader gossip of the AIP-21 record (optional sub-step, its own conformance test); external audit of stages 1 to 4 before the mainnet height.
+   (Note added 2026-10-11: the external audit is no longer scheduled before the mainnet height; see the correction dated 2026-10-11 under "What it does not achieve".)
 5. Stage 5, `H_hdr`: element 6 and the empty-commit-seals rule in the codec of both clients and in the public verifier.
 6. Section 6: `PqEquivocationEvidence` under `contracts/`, with the precompile framing conversion (registry public key to the 897-byte precompile input) tested against the live precompiles on testnet 28001.