CLARIFICATIONS BEFORE YOU ANSWER - doyle's, and they change the question I asked you. My earlier message stands except where this corrects it. Re-read the doc: same path, NEW sha256 d142aa740cf0cca35a553e35d76fcd64f88b1dae0659f55764b9b497e655d0a7 (was e70c63d0...). And read this first, because your answer is FEASIBILITY INPUT, NOT APPROVAL - doyle holds approval, and the clauses below marked unresolved are not things you may build against yet.

1. MY QUESTION 2 WAS TOO WEAK, and this is now the most important thing you can tell me. Capturing "at acceptance, before the queue" is NOT sufficient. Input can be BUFFERED across a handoff: A types, the bytes sit in a terminal or client buffer, B takes the controller seat, and your harness then accepts a submission whose text A wrote while the token current at acceptance is B's. So: BETWEEN THE USER'S KEYSTROKES AND YOUR CAPTURE POINT, WHAT CAN THE INPUT HAVE CROSSED? Name that window, or name why there isn't one. If a handoff can fall inside it, say so plainly - it is the gap the contract cannot close by wording, and doyle wants it identified explicitly rather than assumed away.

2. EDIT AND SPLIT AFTER ACCEPTANCE ARE NOW RULED, because my draft contradicted itself (it allowed post-acceptance editing while demanding the exact committed text). If your harness edits or splits a submission after acceptance, each resulting text is a NEW submission needing its own capture, its own submission id and its own report, or it is reported with NO token. The original authorization never follows rewritten text. Question for you: can your adapter TELL that an edit or split happened? If it cannot distinguish the rewrite from the original, that is a limitation worth naming.

3. WHAT CORE CAN AND CANNOT VERIFY IS NOW WRITTEN DOWN, and it is not flattering to my first draft. Receiving a token and a text in one call does not establish that the text is what the token's holder submitted. YOU are trusted for - and solely responsible for - the association between the payload and the acceptance you captured. Core can verify only: the token's authenticity and issuing origin/session/incarnation; whether its issuing seat occupancy has ended and when; that the submission id is unused in this session/incarnation; that a repeat report hashes to the same payload; and that the paths acted on are quoted inside the reported payload. A defective adapter can still misattribute text within the trust it already holds. Nothing in the contract is core-side proof of authorship, and I am not going to imply otherwise to you.

4. THE POST-HANDOFF GRACE PERIOD IS A PROPOSAL, NOT A GUARANTEE. Do not design against it. It is unresolved together with item 1 (how capture-before-handoff is established at all), and its bound has no value yet and must be justified rather than picked. Until both are ruled, read it as: a token whose issuing occupancy has ended is refused by name.

5. REPLAY IDENTITY IS WIDER THAN I SAID. A submission id is single-use across EVERY token issued in the session and incarnation, not per token. Rotating or re-issuing a token must not let the same submission register again.

The four questions are now five in the doc, with the boundary question as number 2. Everything else holds: a named limitation is the useful answer, "probably fine" is not, and a workaround that samples the current controller is refused outright - missing support must produce a named refusal.

perri: items 1 and 2 are where claude-spt's answer matters most, since #300 was reproduced on it.
emphasys: if omp-spt has no acceptance surface at all, item 1 is answered by saying so.