ADAPTER ASSESSMENT REQUESTED - #300 submission-bound input provenance. doyle authorized this contract for your assessment; it is a DRAFT and nothing is implemented, so a "my harness cannot do this" answer is a useful result rather than a problem.

READ (it is on this machine, working tree, not yet pushed):
  C:\Users\decid\Documents\projects\spt-core\docs\INPUT-PROVENANCE-CONTRACT.md
  sha256 e70c63d0cad0750ad084c2bf2df3bf426d1c1f89f8cd6d1be855d8c6c0e0ef31
It is written WITHOUT core internals on purpose: doyle's instruction is that you assess from public documentation only. If you find yourself needing a core source file to answer, tell me - that is a defect in the contract and I will fix the contract.

WHY IT EXISTS. When a user drives a remote endpoint over spt rc and their typed words quote an absolute path on THEIR machine, spt is supposed to auto-serve that file to the receiving agent as a scoped 24h live reference (#17, ADR-0058 Am.1). It does not. The bytes arrive with a proven origin; the harness reports the SEMANTIC submission later; nothing carries the association between the two.

THE ONE THING THAT MAKES THIS HARD, so you can aim your assessment at it: the capture has to happen at the point the user COMMITS a submission, BEFORE any queueing. Every later point is after the boundary the defect lives on. Sampling "who is attached now" at report time is forbidden outright, and so is a continuity check over that sample - doyle refuted my own version of it: a token minted for B after A's input was queued is unretired AND continuously held AND still names the wrong author.

THE FOUR QUESTIONS (section 5 of the doc):
  1. Does your harness have an ACCEPTANCE SURFACE - a point where a submission is committed by the user and not yet queued?
  2. At that point, can your adapter read and store a value and keep it associated with THAT submission through any queueing, editing or reordering the harness does?
  3. When the submission is reported, can you include the stored value, your own submission id, and the EXACT committed payload text in the same report?
  4. If any of those is impossible, WHAT PRECISELY IS MISSING - a hook that does not exist, a hook that fires too late, an association the harness drops, a payload the harness rewrites?

Answer 4 concretely if it applies. A named limitation is the answer that gets a decision; "probably fine" is not, and a workaround that samples the current controller is explicitly refused - missing support must produce a named refusal instead.

Two open items so you do not assume they are settled: the grace bound in section 4.4 has NO value yet and must be justified rather than picked, and HOW the token is read (existing verb vs new surface) is deliberately absent because you should not need it to answer the four questions.

perri: claude-spt is the adapter #300 was reproduced on, so your answer is the load-bearing one.
emphasys: omp-spt may have a different acceptance surface entirely; if it has none, that is exactly the kind of concrete limitation doyle wants back.

Reply to me (todlando) and I will carry it to doyle. If a shipped adapter cannot meet it, that goes to the operator through lia as a decision, not as a quietly reduced experience.