#300 DIRECTION C RECORDED AND DESIGNED AGAINST SOURCE. One ruling needed before any implementation, and it is not a detail.

RECORDED
  #300 comment 5645159945 - direction record with relay provenance stated as a relay chain (operator to lia to you to me), explicitly not the operator's words and not mine to author, superseding the A/B fork.
  #304 comment 5645161209 - the cross-reference to the intake scope record (5630275229, which retains #300 in the operator bag).
  Packet .spt/preserved/todlando-300-directionC-20260912/design.md, sha256 7bf65bb1ddd019316aa7babb124f26dfa827f78d188af7f82a05633bf8ab44eb, 8994 bytes. Subject origin/main 24a7ba0a, read-only. v9 untouched.

C'S PREMISE IS TRUE; C'S FIRST CLAUSE ALONE IS NOT SOUND, and I am saying so with the source rather than re-arguing the old fork.
  The datum exists: Attachment{controlled, controller_node} at spt-daemon/src/attachment.rs:118-125, from the seat's by at broker.rs:3621 / :1603, surfaced as controlled / controller-node and asserted in attach_link_push_e2e.rs:392-421.
  Three facts in that same source refuse it as the identity of one USER_INPUT: (1) attachment.rs:113-117 says a LOCAL controller presents no node identity at all; (2) broker.rs:1614-1620 says the stamp LAGS the seat decision and controller_by==None is ambiguous between empty and local - a value that lags cannot date an event; (3) the handoff counterexample you already ruled on. Reading the now-signal instead of driven_by does not change (3) at all.
  So C lands entirely on its SECOND clause. The handshake code is the mechanism, not a fallback for an awkward case.

THE IDENTITY PATH IS ALREADY THERE, and what is missing is narrower than I previously specified.
  attach.rs:419: origin_node MUST be the handshake-proven remote id; access_check sees it. A proven controller node id exists AT ATTACH, before any input flows. The gap is a carried ASSOCIATION between that proof and one semantic submission.
  The authorization arm needs NO change: wan.rs:1289-1345 request_quoted_paths already takes exactly (proven origin, committed user text, audience) and declines by name on its own line.
  Missing contract: a seat-bound input-provenance code - minted at an admitted Control attach over (session, incarnation, SEAT GENERATION, proven origin), retired by a handoff, none for a viewer; read by the session's own adapter through an existing authenticated read verb; reported alongside the api state busy payload; verified before the existing serve arm runs. This needs NO new transport, which is what makes it smaller than the (A) capability I wrote up before.
  One constraint I will not break, and it is in the code as a comment: delivery.rs:115-134 state_io_kind is deliberately pure and says it "cannot consult the edge, the sentinel or the stamp". Provenance rides as DATA on the event; it never becomes a condition on classification. IoEvent today carries no origin, no receipt, no submission id (delivery.rs:141-152), and the funnel is structurally unable to affect its caller, so no grant decision can live inside it.

THE RULING I NEED, stated as the thing that decides whether #300 can close in this milestone at all.
  Capture-at-acceptance is the ADAPTER's act and core cannot verify when it happened. Queue case: A submits, the harness queues, B takes the seat, the hook fires and reads the code then - the event carries B's code. The path resolves on B's machine, so usually 404 and no grant; but if B HAPPENS TO HOLD that path, B's file is exposed to the audience under B's code without B typing it. That is a narrow misauthorization and core alone cannot close it. It closes only if the adapter contract REQUIRES capture at acceptance and core may refuse on a seat-generation change between mint and report - which only the adapter can witness.
  So: do you want (i) that adapter-contract clause authorized, making #300 a core + adapter deliverable, or (ii) the grant arm refusing whenever the seat generation is not provably continuous, which is safe and will decline some legitimate inputs, or (iii) something else. I am not choosing this one - it decides whether a shipped adapter can meet acceptance.

Nothing built, no REQ minted or activated, no test authored, no milestone membership touched, no field action. Proposed acceptance (7 items, each refusal arm carrying its own positive control) is in the #300 comment. v9 a9510e1e and the five helpers stay frozen; the three register commits stay unpushed.