diff --git a/docs/requirements/hierarchy-schema.md b/docs/requirements/hierarchy-schema.md
index b7af38d0..e5525bbf 100644
--- a/docs/requirements/hierarchy-schema.md
+++ b/docs/requirements/hierarchy-schema.md
@@ -77,7 +77,9 @@ directory exists so one shared company can serve many users instead of
 each user creating a duplicate private company (Ruling 4b, webui-audit
 lane, ruled 2026-08-27). §2.1 gains a `visibility` column; §2.8 defines
 the two classes (`private`/`directory`), the directory's existence-only
-disclosure, and the see-and-ask-to-join invariants; §5.2's mutation
+disclosure, and the pre-binding invariants for the deferred
+see-and-ask-to-join flow (no join-request surface is authorized here —
+its flow is a follow-up contract); §5.2's mutation
 enumeration gains the visibility change; §5.5 defines who may change
 visibility (platform admins, plus a company-CRUD capability whose
 definition is a follow-up amendment to contract 2 — until it ratifies,
@@ -180,14 +182,17 @@ decision under A1; this contract pins only that they stay distinct tables.)
      Visibility is disclosure, not authority. Content and structure access
      to a directory-listed company still require explicit grants —
      contract 2 §3.1 deny-by-default is unchanged, and the ownership model
-     (§4.4, contract 2 §4.3) is unchanged. The directory supports a
-     see-and-ask-to-join flow (Ruling 4b decision 5): an authenticated
-     user may request to join a directory-listed company. Two invariants
-     bind any implementation of that flow now, ahead of its own contract:
+     (§4.4, contract 2 §4.3) is unchanged. Ruling 4b decision 5 wants a
+     see-and-ask-to-join flow for directory-listed companies. **This
+     contract authorizes no join-request runtime surface**: the flow in
+     its entirety — the ability to submit a request, its transport,
+     storage, and request lifecycle — is a follow-up contract, and until
+     that contract ratifies, the directory's only function is the
+     read-only listing above (A2 §9.1.2 admits nothing more). Two
+     invariants pre-bind that future contract now:
      a join request confers no authority of any kind, and approval is
      ordinary grant creation by an effective `owner` under contract 2 §4.1
-     — there is no other acceptance path. The flow's transport, storage,
-     and request lifecycle are a follow-up contract.
+     — there is no other acceptance path.
 
 ## 3. Grant attachment points
 
@@ -421,7 +426,12 @@ Binding on the implementing PRs (extends A1 §8.3):
    event's outbox record exists after the same commit — state row,
    audit event, and outbox record are witnessed as one transaction
    (REQ-AUD-001); a rolled-back
-   mutation leaves no event and no outbox record (rollback witness); a
+   mutation leaves no event, no outbox record, AND no state effect —
+   a rolled-back create leaves no row, a rolled-back rename, transfer,
+   or visibility change leaves the prior values in place, and a
+   rolled-back delete or grant revoke leaves the row present
+   (rollback witness on all three legs, per REQ-AUD-001's
+   commit-or-roll-back-together acceptance); a
    node delete's cascaded
    grant deletions are each covered by events; events survive deletion of
    their target (query the events of a deleted node).
@@ -462,8 +472,8 @@ Binding on the implementing PRs (extends A1 §8.3):
    each visibility change emits its §5.2 audit event carrying old and
    new values — the full audit pattern for the mutation class
    (same-transaction atomicity of state row, audit event, and outbox
-   record; rollback leaving no event and no outbox record;
-   actor/verb/target) is §6.4's, which enumerates
+   record; rollback leaving no state effect, no event, and no outbox
+   record; actor/verb/target) is §6.4's, which enumerates
    visibility change; this item adds only the old/new-value payload
    assertion.
 
diff --git a/docs/requirements/native-kanban-sot.md b/docs/requirements/native-kanban-sot.md
index 63738e4d..ea99a50b 100644
--- a/docs/requirements/native-kanban-sot.md
+++ b/docs/requirements/native-kanban-sot.md
@@ -497,13 +497,20 @@ itself permits, so that contract does not stretch A1 by interpretation.
 1. Content access stays grant-only under the RBAC grant model contract:
    directory listing discloses existence, never content, membership, or any
    authority (Ruling 3 unchanged; hierarchy schema §2.8).
-2. Visibility changes are hierarchy mutations on the existing §8.2.3 audited
+2. **No join-request surface is authorized.** Ruling 4b decision 5's
+   see-and-ask-to-join flow is a follow-up contract in its entirety —
+   including the ability to submit a request. A2 admits exactly the
+   read-only listing of §9.1.2 and nothing more; hierarchy schema §2.8
+   states the invariants that pre-bind the future flow contract, and that
+   contract must itself amend this enumeration before any join-request
+   runtime surface exists.
+3. Visibility changes are hierarchy mutations on the existing §8.2.3 audited
    mutation path — audited maintenance of the class's own structure in
    §8.1.3's sense, not a further runtime function. Authorization for them is
    defined in hierarchy schema §5.5 (platform admins plus the future
    company-CRUD capability; owner-as-such cannot publish).
-3. Company creation is unchanged and always yields `visibility = 'private'`
+4. Company creation is unchanged and always yields `visibility = 'private'`
    (onboarding wizard §5.2); this amendment adds no creation path and no
    default-open disclosure.
-4. Every other constraint of A1 — §8.1.2's remaining bullets, §8.2 in full,
+5. Every other constraint of A1 — §8.1.2's remaining bullets, §8.2 in full,
    and §8.3's other acceptance criteria — is untouched.