diff --git a/kernel/K13 Task Runtime and Execution Control/10 Batch Admission Transitions and Serial Integration.md b/kernel/K13 Task Runtime and Execution Control/10 Batch Admission Transitions and Serial Integration.md
index 42a4d16..d4bdfce 100644
--- a/kernel/K13 Task Runtime and Execution Control/10 Batch Admission Transitions and Serial Integration.md	
+++ b/kernel/K13 Task Runtime and Execution Control/10 Batch Admission Transitions and Serial Integration.md	
@@ -14,7 +14,7 @@ Batches may execute concurrently by default; the cap is controlled by the contra
 
 The machine-decidable members of condition 2's page set come from metadata that already exists: a page whose frontmatter carries `type: overview`, `runtime-card`, or `card-index`; a page carrying `type: term` with `scope: shared`; and any page the selected profile's `Expression Layer Entry` registers as a canonical dependency map. "Other profile-registered hub roles" remains in force, but no profile slot registers one today, so that clause currently contributes no page and is a future extension point. Editing and creating differ: an existing hub page in the frozen manifest blocks concurrent activation and takes the exclusive or `serial-integrator` route below, while a hub page this batch creates does not block it and is reported as a candidate for that batch's hub synchronization step.
 
-Condition 2 is time-invariant, and its reporting reflects that. Whether a queued batch's manifest edits an existing hub page does not depend on which batch is being admitted, how many batches are active, or what has closed since — the answer is the same at every moment until a structural Amendment changes the batch's `execution_mode`. Reported only through readiness, such a batch looks merely "not yet turn" and the defect stays invisible until it reaches the head of the Queue, so a whole mis-specified family is rediscovered one batch at a time. The consistency mode therefore reports every queued batch that fails condition 2 as a candidate over the whole Queue, naming the batch, the hub pages, and the current mode. It stays a candidate rather than an error because the repair is an Amendment and the Amendment tools refuse to run against a runtime carrying errors: a hard failure would wedge the instance out of its own repair path. The other admission conditions stay readiness-only, because each of them is a statement about *now* — a dependency not yet closed, a cap currently reached, a manifest currently overlapping active work — and becomes true or false as the run proceeds.
+Condition 2 is time-invariant, and its reporting reflects that. Whether a queued batch's manifest edits an existing hub page does not depend on which batch is being admitted, how many batches are active, or what has closed since — the answer is the same at every moment until a structural Amendment changes the batch's `execution_mode`. Reported only through readiness, such a batch looks merely "not yet its turn" and the defect stays invisible until it reaches the head of the Queue, so a whole mis-specified family is rediscovered one batch at a time. The consistency mode therefore reports every queued batch that fails condition 2 as a candidate over the whole Queue, naming the batch, the hub pages, and the current mode. It stays a candidate rather than an error because the repair is an Amendment and the Amendment tools refuse to run against a runtime carrying errors: a hard failure would wedge the instance out of its own repair path. The other admission conditions stay readiness-only, because each of them is a statement about *now* — a dependency not yet closed, a cap currently reached, a manifest currently overlapping active work — and becomes true or false as the run proceeds.
 
 For a complex batch, readiness additionally requires a current Work Spec
 path/hash whose batch ID and ordered manifest equal B. The worker reads that