# Receipt-bound input provenance — core-only contract

**Current contract: §8, core-only.** Sections 0–7 retain the superseded
adapter-design discussion and measurements; they impose no adapter obligations.
The implementation uses the existing USER_INPUT reports and controller rc stream.
The two-node field acceptance remains separate from the doc/impl/unit lane.

## The operator decision this contract is bound to

**Provenance follows the SUBMITTER, not the AUTHOR.** The origin used is the computer of the person who
submits the input — never the computer of whoever typed the characters, when those differ.

**Reavo, verbatim as relayed by lia** (lia's message `5Y45PXOU`; relay chain Reavo → lia → doyle →
todlando — doyle did NOT receive it directly from Reavo):

> yes, it should use the sender's computer. if the provided filepath doesn't match a file there, then
> simply skip fileserving

**Two things are NOT inside that quotation and are attributed separately, so nobody cites the operator
for them:**

- **"No reliable sender, no automatic share"** — the ADOPTED SAFETY RULE (doyle, 2026-09-12). It is a
  gate policy adopted alongside the decision, not part of Reavo's words.
- **No prompt, and no fallback to another origin** — doyle's instruction on how the skip behaves
  (B7ZLOLBZ). The quotation says "simply skip fileserving"; that the skip is silent and never retries
  against a different machine is the gate's reading of it, stated as instruction.

**What this settles and what it does not** (doyle, B7ZLOLBZ): the submitter rule settles the
EXPERIENCE. Enqueue/dequeue ordering and human-versus-machine injection remain **mechanism questions to
resolve** — they are not reasons to reopen the settled experience, and an adapter answer that disputes
the experience rather than describing its mechanism is answering the wrong question.

**Historic audience: adapter owners.** The introduction and §§0–7 below retain the superseded
adapter-design discussion. Their proposed obligations and refusal rules are historical, not the
current contract; §8 replaces them and asks nothing new of adapters.

## 0. The problem in one paragraph

When a user drives a remote endpoint (`spt rc` from their machine to an agent on another machine) and
their typed words quote an absolute path on THEIR machine, spt is supposed to serve that file to the
receiving agent automatically, as a scoped live reference (#17, ADR-0058 Am.1). It does not, because
the two halves never meet: the bytes arrive with a proven origin, and the harness reports the
SEMANTIC submission later, with no carried association between them. The fix is not to guess the
association. It is for the harness to capture provenance at the moment it accepts a submission, and
carry it with that submission.

The question this contract answers is **"whose computer does this path refer to?"**, and the answer is
the submitter's. It is deliberately NOT "who wrote these characters?" — that question is settled and
out of scope (see the decision above). An adapter's whole job here is to capture the submitting
attachment's token at acceptance and carry it, unaltered, to the report.

## 1. Why the obvious shortcut is forbidden

**Never sample the current controller at report time.** Reading "who is attached right now" when a
submission is REPORTED is not an answer to "who submitted this", for three independent reasons:

- A submission can be **accepted, queued, and reported later**. Between those moments the controller
  seat can change hands. The sample then names someone who did not submit it.
- **Continuity does not rescue the sample.** A token minted for B *after* A's submission was queued,
  still current when that submission is reported, is both unretired and continuously held — and still
  names the wrong origin. (This refutes an earlier draft of mine; doyle's, 2026-09-12.)
- "Somebody is driving" and "which node is driving" are **different facts with different
  availability** — one can be known while the other is not.

**What the submitter rule does and does not relax.** It removes the question of who typed the
characters: if A types into a buffer and B submits, the origin is **B's computer, deliberately**, and
that is the settled experience rather than a defect to engineer around. It does NOT license sampling,
because the sample is taken at the wrong MOMENT, not merely against the wrong PERSON. Acceptance is
when a submitter submits; report time is some time afterwards, and the gap is exactly what this
contract exists to bridge.

Consequently: **an adapter that cannot capture at acceptance must produce a named refusal, not a
fallback.** There is no degraded mode that samples. A refusal is a correct outcome; a guess is not.

## 2. Terms

- **Submission** — one semantic unit of user input that the harness has ACCEPTED from the user: the
  thing a user means when they say "I sent that". Not a keystroke, not a byte chunk, not a turn.
- **Submitter** — the controlling attachment that SUBMITS a submission at the acceptance surface. Its
  node is the origin this contract binds to. Deliberately **not** "whoever typed the characters": when
  those differ, the submitter wins, by operator decision. An adapter never needs to determine who
  typed anything.
- **Acceptance surface** — the point in the harness where a submission becomes committed by the user
  and can no longer be edited: where "the user pressed send". The contract lives here. If a harness
  has no such point, it cannot satisfy this contract, and that is the concrete limitation to report.
- **Provenance token** — an opaque string, issued by spt to a controlling attachment, which carries
  the authenticated identity of the controller's node. Adapters never parse it, never construct one,
  and never infer one; they read it, hold it, and hand it back.
- **Submission id** — an adapter-chosen identifier, unique within the session, naming one submission.
  It exists so a report can be matched to an acceptance and so a replay is recognisable.

## 3. What the adapter must do

1. **Capture at acceptance, before any queue.** At its acceptance surface, the adapter reads the
   provenance token then current and stores it WITH that submission, together with a submission id
   it chooses. The capture must happen before the submission can be queued, deferred, or reordered.
   Capturing later — at turn start, at tool time, at report time — does not satisfy this contract,
   because those points are after the boundary the defect lives on.

   **RESOLVED BY THE SUBMITTER RULE — this was the draft's biggest open question and it is now
   closed.** Earlier revisions treated buffered input across a handoff as an unresolved gap: A types,
   the bytes sit in a terminal or client buffer, B takes the seat, and the harness accepts a submission
   whose characters A wrote while the current token is B's. Under Reavo's decision that is **not a
   defect**: the origin is the SENDER'S computer — B's — and the token current at acceptance is the
   correct answer, not an approximation of a better one. Adapters must NOT add machinery to attribute
   text back to whoever typed it.

   What remains is a MECHANISM question, and it is the one to answer: **exactly where your acceptance
   point sits relative to your queue** — enqueue-versus-dequeue ordering, and whether machine-injected
   input (hooks, replays, automation writing into the same path) is distinguishable from a human
   pressing send. Those are unsettled and are what §5 asks about. They are not grounds to reopen the
   submitter rule.
2. **Carry it through whatever the harness does next. Authorization binds to the bytes that were
   accepted.** If the harness queues or delays the submission, the captured token travels with it
   unchanged.

   **The record is of the ORIGINAL ACCEPTED BYTES, and later rewriting does not invalidate it.** What
   was accepted was accepted; a harness that edits the text afterwards does not retroactively make the
   capture false. What rewriting must never do is EXTEND that authorization: a rewritten path, or a
   path newly introduced after acceptance, gains nothing from the original record. Authorization
   covers the paths quoted in the bytes whose acceptance was captured, and no others.

   **An adapter that cannot observe later edits MUST NOT PROMISE TO DETECT THEM.** Saying "I will
   treat each edit as a new submission" is a capability claim, and on a harness with no
   post-acceptance observation it is one the adapter cannot keep. The honest position is to bind the
   captured bytes, report that later edits are unobservable, and let the contract — not the adapter's
   optimism — decide what that costs. Reporting the limitation satisfies this clause; silently
   implying detection does not.
3. **Report it with the payload.** When the adapter reports the submission to spt, it reports, in one
   call: the submission id, the captured token, and the **exact final payload text** of that
   submission. The payload reported must be the text as committed, not a normalised, truncated or
   re-rendered version.
4. **Never substitute.** If no token was captured — a local user, a viewer, a harness surface that
   cannot reach the acceptance point — the adapter reports the submission with **no token**. It must
   not report the current token instead, and must not synthesise one from terminal bytes, window
   state or timing.
5. **Report once per submission.** One acceptance, one report. A retry after a transport failure
   repeats the same submission id and the same payload.

## 4. What spt guarantees in return

1. **Token issuance.** A controlling attachment over an authenticated remote origin is issued a
   provenance token bound to that origin, to the session, and to the attachment's own occupancy of
   the controller seat. A read-only viewer is issued none.
2. **Binding, and an honest split of who establishes it.** Authorization is computed from the reported
   token plus the reported payload: the audience is the receiving endpoint, and the only paths
   considered are absolute paths quoted inside THAT payload. No other text and no terminal stream is
   read. But receiving a token and a text in one call does NOT by itself establish that the text is
   what that token's holder submitted, and this contract does not pretend otherwise (doyle,
   2026-09-12):

   - **The adapter is trusted for, and solely responsible for, the association**: that this payload is
     the text of the submission whose acceptance it captured, and that the token it reports is the one
     read at that capture. Core cannot observe the acceptance and cannot reconstruct it afterwards.
   - **Core can independently verify** only: that the token is authentic and was issued by this node;
     which authenticated origin node, session and incarnation it was issued to; whether its issuing
     seat occupancy has ended, and when; that the submission id has not been used before within the
     session and incarnation; that the payload hashes to the value bound to that submission id on any
     repeat report; and that the paths it acts on are quoted inside the reported payload.
   - Therefore a dishonest or defective adapter can misattribute text within the trust it already
     holds over the session. This contract narrows that to the adapter's own acceptance path; it does
     not remove it, and no wording in it should be read as core-side proof of authorship.
3. **Serving semantics, unchanged from #17 / ADR-0058 Am.1.** A live reference on the submitter's own
   machine, 24h TTL, audience scoped to the receiving agent, and a FILE_ACCESS_HELPER notice emitted
   once per submission and path.

   **A path that names no file on the submitter's machine is SILENTLY SKIPPED.** Reavo: "if the
   provided filepath doesn't match a file there, then simply skip fileserving". The skip is silent —
   **no prompt, no notice, no named refusal on that path** (doyle's reading, B7ZLOLBZ) — and there is
   **no fallback to another origin**: spt does not look for the file on the receiving machine, on a
   previous controller's machine, or anywhere else. A quoted path that does not resolve on the
   submitter's computer simply does not become a reference, and the submission is processed exactly as
   if it had quoted nothing. This is the one non-grant in this contract that is NOT announced, and it
   is deliberate: a user quoting a path that happens not to exist on their machine is an ordinary
   event, not an error to report.
4. **No reliable sender, no automatic share — the adopted safety rule** (doyle, 2026-09-12; a gate
   policy adopted alongside Reavo's decision, NOT part of it). Where the submitting origin is not
   established to the standard §4.1 requires, nothing is served automatically. This is a refusal to act
   on an unestablished origin, and it is distinct from the silent skip above: the skip is a path that
   resolved to nothing on a KNOWN sender's machine; this is not knowing the sender. **What makes a
   sender "unreliable" is NOT DEFINED in this contract and is not the adapter's to decide** — it is a
   core-side and gate-side question, deliberately left open rather than invented here.
5. **Handoff.** A token stops being issued the moment its holder stops holding the seat. A new holder's
   token can never redeem a previous holder's submission.

   **UNRESOLVED — NOT AN AUTHORIZED GUARANTEE (doyle, 2026-09-12).** The proposal is that a submission
   whose token was captured while its holder still held the seat stays authorizable for a BOUNDED
   grace period after the seat changes, on the reasoning that capture and not report is when the
   SUBMISSION happened. That is a proposal only. It no longer depends on the buffered-authorship
   question — that is settled (§3.1) — but it does depend on the still-open ordering question (§5.2):
   if acceptance is at dequeue rather than enqueue, "captured while its holder held the seat" is not
   established by capture alone. It may not be relied upon.
   The bound also has no value yet and must be justified rather than picked. Until both are ruled, the
   safe reading is that a token whose issuing occupancy has ended is refused by name.
6. **Replay.** A submission id is single-use **within the session and incarnation, across every token
   issued in it** — not merely per token. Rotating or re-issuing a token must not let the same
   submission register a second time (doyle, 2026-09-12). Re-reporting the same id and payload
   re-registers nothing, emits no second helper notice, and **does not extend an existing TTL**. The
   same id with a different payload, or under a different token, is refused by name rather than treated
   as an update.
7. **Refusal is named — with exactly one silent exception.** Every AUTHORIZATION non-grant says which
   condition failed, on the existing declined line: no token; token not valid for this session or
   incarnation; token past its grace bound; viewer; submission id reused with different payload;
   payload quoted no absolute path; sender not established (§4.4).

   **The exception is §4.3's missing file, and it is silent by decision, not by omission.** A quoted
   path that resolves to nothing on the submitter's machine produces no declined line, no notice and
   no name. The distinction is: a REFUSAL means the authorization failed; a SKIP means authorization
   was fine and there was simply no file there. Do not collapse the two, and do not add a named refusal
   for the skip on the grounds that every other outcome has one.
8. **Separation of concerns, structurally.** Input processing and serving authorization are
   independent: a refused authorization never alters, delays or fails the submission itself, and a
   submission is delivered and processed identically whether or not a token rode with it.

## 5. The question for adapter owners

Using only this document:

1. Does your harness have an **acceptance surface** as defined in §2 — a point where a submission is
   committed by the user and is not yet queued?
2. **The ordering question — this replaces the old buffered-authorship question, which is now
   settled.** Do NOT answer about who typed the characters: under the submitter rule the token current
   at acceptance is correct by definition, even if someone else typed the text. Answer instead about
   your QUEUE: does your acceptance point sit at **enqueue** (the submission is captured as it enters
   the queue) or at **dequeue** (captured as the harness takes it off for processing)? If it is
   dequeue, what can change the seat between the two, and can your adapter reach the enqueue point at
   all?
2b. **Machine-injected input.** Can input reach that same acceptance surface WITHOUT a human pressing
   send — hooks, replayed or scripted input, automation writing into the same path, a resumed session
   re-submitting? Can your adapter tell that case apart from a human submission, and what does it
   currently capture for it? A machine injection that captures the seat-holder's token would attribute
   a machine's submission to a person, which is a mechanism question this contract has NOT resolved.
3. At that point, can the adapter **read and store** a value, and keep it associated with that exact
   submission through any queueing the harness performs? Can the harness EDIT or SPLIT the text after
   acceptance, and if so can your adapter OBSERVE that it did (§3.2)? Answer what you can observe, not
   what you would like to guarantee: if there is no post-acceptance observation, say so — an adapter
   that cannot see later edits must not promise to detect them, and reporting the limitation is the
   answer this contract wants.
4. When the submission is reported, can the adapter include the stored value, its own submission id,
   and the **exact committed payload text** in the same report?
5. If any of those is impossible, **what precisely is missing** — a hook that does not exist, a hook
   that fires too late, a buffer the adapter cannot see behind, an association the harness drops, a
   payload the harness rewrites?

Answer (5) concretely if it applies. A named limitation is the useful answer and the one that gets a
decision; "probably fine" is not, and neither is a workaround that samples the current controller.
**An answer here is feasibility input, not approval**: doyle holds the approval, and the clauses marked
unresolved below are not guarantees an adapter may build against yet.

## 6. Known open items, so nobody assumes they are settled

- **CLOSED, recorded so nobody reopens it:** "which controller's text is this, if one typed and
  another sent" is SETTLED by Reavo's decision — the sender's computer, full stop. Earlier revisions of
  this document carried it as the biggest open question; it is not one. Re-raising it is out of scope,
  and an adapter must not build attribution machinery to answer it.
- **Enqueue-versus-dequeue ordering is a MECHANISM question, still open** (doyle, B7ZLOLBZ). Where the
  acceptance point sits relative to the queue decides whether "the token current at acceptance" is the
  submitter's token in practice. Adapter answers to §5.2 are the input to that ruling. It does not
  reopen the experience.
- **ORIGIN SIGNALING IS AN UNRESOLVED REQUIREMENT, not an adapter chore** (doyle). Machine-injected
  submissions were MEASURED indistinguishable from human ones at the harness level (§7), and the only
  separator in the field today is an adapter recognising its own transport's payload shapes — a
  heuristic that establishes "this looks like something spt sent", never "a person submitted this".
  Recognizing payload shapes is not authenticated human provenance. What is missing is a trustworthy
  origin signal; until one exists such submissions report with no token, which is a floor and not a
  solution. Adapter answers to §5.2b describe the gap; they do not close it.
- **A resumed session re-submitting and externally scripted input are SEPARATE, both uncharacterised**,
  and external automation is **not** equivalent to a resumed session — neither answer follows from the
  other.
- **What makes a sender "unreliable" (§4.4) is UNDEFINED here** and is deliberately not the adapter's
  to decide. The adopted safety rule says no automatic share in that case; the threshold is core-side
  and gate-side.
- **The post-handoff grace period (§4.5) is a PROPOSAL, not an authorized guarantee.** The submitter
  rule reduces its urgency — the submitter is by definition whoever held the seat at acceptance — but
  it is still unruled, and its bound still has **no value**; it must be justified, not picked.
- **§4.2's split of responsibility is deliberate**: the association is the adapter's to establish and
  core cannot verify it independently. Nothing in this contract is core-side proof of authorship.
- Whether the token is readable through an existing authenticated read verb, or needs a new surface,
  is **not decided** and is deliberately absent from this contract — it is an implementation question
  and adapter owners should not need it to answer §5.
- Acceptance criteria for #300 live on the issue (comment 5645159945) and are proposed, not granted.
- If no shipped adapter can satisfy §3.1, that is a concrete limitation for an operator decision via
  lia, not a licence to reduce the behaviour.
- The **silent skip** (§4.3) is the one non-grant that emits nothing. It is easy to misread as a bug
  report waiting to happen — "the file didn't get shared and nothing said why" — and it is deliberate.
  If experience shows users need a signal, that is a new operator decision, not a contract correction.

## 7. Adapter answers on record

### claude-spt (perri, 2026-09-12) — answered against this frame, with measurements

**§5.1 acceptance surface: YES.** `UserPromptSubmit` fires when a submission is committed, before the
model sees it, carrying the exact committed text and session id, and can block.

**Two holes, and they are TWO SEPARATE POPULATIONS** — perri's precision fix, kept apart here because
they need different contract language and merging them states something false about both:

- **All submissions: 302 audited, 227 hook-covered.** The 75 misses are harness-synthesised transcript
  entries OR built-in local slash commands (`/compact`, `/reload-plugins` mid-session are the clean
  cases). This is a **surface gap the adapter cannot close**.
- **PTY-typed submissions only: 133 audited, 103 covered.** All 30 misses are safe-mode sessions, where
  hooks are off BY DESIGN. That is **configuration, not a defect** — a session that legitimately has no
  adapter at all.

Both land on "no token", by different routes. **Consequence for this contract: "no token" is a
FIRST-CLASS outcome, not an edge case** (§3.4), and any design that treats a missing token as anomalous
is wrong on this harness.

**Instrument limit, carried with the numbers:** the audit observes hook OUTPUT in the transcript, not
hook INVOCATION, so a hook that fired and emitted nothing is invisible to the count. The positive
controls are the coverage figures themselves — 227/302 and 103/133 — so it is an instrument that counts
rather than a detector that can never fire.

**§5.2 ordering: ENQUEUE, measured, n=3.** With a turn demonstrably still executing, submissions typed
into the input box fired the hook at **+0.5s, +0.9s and +1.0s** after Enter — exactly one fire each,
with **no second fire** when the harness later folded the text into the running turn. Capture therefore
sits at enqueue, ahead of what the harness does next, and §3.1 is satisfiable **for the cases
exercised**.

**Three observations are evidence about those three cases, not universal coverage** — a distinction the
measurer drew first and this document keeps in its own voice. They establish that enqueue capture
happens on this path; they do not establish that every submission on this harness takes it.

**The three caveats are recorded WITH the result, not summarised past it** (perri's own framing, and
they are the reason to trust the number): the submissions were PTY-typed by spt rather than by a human,
on the same keystroke path into the same input box; the endpoint was forced idle to take that route,
which changes spt's routing decision and not the harness's queueing; and **one narrower window remains
unmeasured** — a submission typed into the Stop-to-next-turn boundary, which an in-tree comment claims
is folded into the running turn with no hook at all. That claim is neither confirmed nor refuted and is
asserted in neither direction here.

**§5.2b machine injection: INDISTINGUISHABLE AT THE HARNESS LEVEL — and the probe above was itself a
machine submission.** Core PTY-typed the text and pressed Enter with no human involved, and the hook
fired identically to a human submission. This is spt's own normal delivery path to a busy agent, not a
hypothetical. The adapter can separate them **only by recognising its own transport's payload shapes**,
a discriminator that already exists for an adjacent reason: reporting a delivered peer message back as
user input would launder a peer's shortform tags into an ingest edge. For such a submission the adapter
captures **nothing** and reports with no token, per §3.4.

**What this actually exposes is an UNRESOLVED ORIGIN-SIGNALING REQUIREMENT, not an adapter chore**
(doyle's correction to an earlier draft of mine, which framed it as a maintenance obligation on core to
announce every injection shape). **Recognizing payload shapes is not authenticated human provenance.**
A pattern list is a heuristic over today's formats: it can be wrong, it can go stale, and even when it
is right it establishes only "this looks like something spt sent", never "a person submitted this".

So the gap is not that adapters must track core's injection formats — it is that **nothing in this
system currently signals origin in a way an adapter could trust.** That mechanism does not exist yet,
and this contract does not pretend an adapter's shape-matching substitutes for it. Until it does,
machine-injected submissions report with no token (§3.4), which is correct but is a floor rather than
a solution.

Two further injection sources — a resumed session re-submitting, and scripted input originating outside
spt — are **uncharacterised** and reach the same surface. They are deliberately not guessed at, and
**external automation is not equivalent to a resumed session**: they are separate origins whose answers
do not follow from one another.

**§5.3 carry: satisfied, and for a better reason than diligence.** Capture and report happen inside the
SAME hook invocation, so nothing has to survive a queue at all. **Edit/split detection: CANNOT BE DONE.**
The adapter sees a submission exactly once and never again — no post-acceptance event, no rewrite
signal, nothing to diff against. It binds only the bytes it saw, which is exactly what §3.2 requires —
authorization is of the ORIGINAL ACCEPTED BYTES — but it **cannot NOTICE a rewrite**. Under the
corrected §3.2 that is not a failure to satisfy the clause: the adapter reports the limitation instead
of promising detection it cannot deliver, and the capture of the accepted bytes stands. What it does
mean is that a path introduced by a later rewrite could not be refused BY THE ADAPTER; it is refused by
the contract, since authorization never extended to it.

**§5.4 report: yes** — adapter-minted submission id, token, and exact committed bytes in one call at
acceptance. Two operational facts: the hook runs against a ~5s deadline (measured p99 4835ms on that
node) so **a report can be lost to a kill** — which is an argument FOR §3.5's same-id-same-payload
retry, not merely a tolerance of it; and 99.4% of the hook's wall time is serial `spt` process spawns,
so **the token read must fold into a call the hook already makes** rather than adding a spawn on the
deadline-critical path. Noted for the implementation question this contract deliberately leaves open:
reading the token from inside `UserPromptSubmit` IS the acceptance-time read, and is a forbidden sample
only when taken at report time.

**Named limitations (§5.5):** no queued-vs-immediate flag and no sat-time on the hook input; no
post-acceptance observation, so rewrites are undetectable; the surface is neither universal nor
guaranteed enabled; the hook is deadline-killed under load, so reports must be idempotent and
loss-tolerant; and machine-injected submissions are separable only by the adapter's recognition of
shapes it has been told about.

### omp-spt (emphasys, 2026-09-13, message 4II3N2NA) — answered from public upstream declarations, not a runtime measurement

**No submission-bound carrier.** `InputEvent` carries `type`, `text`, optional `images`, and
`source: "interactive" | "rpc" | "extension"` — no submission id, no attachment identity, no
core-issued value. `BeforeAgentStartEvent` carries `prompt`/`images`/`systemPrompt`, nothing more.
**`InputEventResult` may replace text/images**, so observed text is not guaranteed to be the committed
payload after later extensions run. `sendUserMessage` permits programmatic prompts and queued streaming.

**§5.2 ordering: UNVERIFIED.** The declarations do not establish a pre-enqueue acceptance boundary;
emphasys inspected upstream `main` declarations only and will not promise ordering or byte preservation.

**§5.2b origin: `source` names a ROUTE, not a person.** `source === "interactive"` distinguishes input
routes from one another, not an authenticated controller from automation using the same route; no
replay/resume discriminator exists.

Scope carried with the answer: no experiment, no installed-runtime measurement, no core-source inspection.

## 8. RULING (doyle, 2026-09-13; RE-CUT the same day on the operator's direction) — core-only; no token, nothing asked of adapters

<!-- [doc->REQ-INPUT-PROVENANCE-ACCEPTANCE-REPORT] -->

**Operator, 2026-09-13, direct:** "#300 needs to be developed entirely independently of harness adapters.
spt-core does not concern itself with harness adapter integration. omp-spt and/or claude-spt should not
have anything to do with #300. they already submit USER_INPUT kind event hooks, and that's all spt-core
should be asking of them."

That strikes the whole adapter half of this contract — §3's obligations, the token, and the first cut of
this ruling (a manifest declaration plus a submission id, retracted within the hour). What remains is
what core can do with what it ALREADY receives: a session-authenticated USER_INPUT report carrying the
exact payload, at whatever moment the harness reports it.

1. **Core binds origin at RECEIPT of a path-bearing USER_INPUT report** — the session's current
   authenticated REMOTE controller seat (the broker-owned `driven_by`). No quoted paths means no broker
   IPC and no line. An absent hosted session, local seat, viewer-only seat, or no controller binds
   nothing silently. No adapter declares anything; no adapter is asked when it reports.
2. **Own-injection exclusion.** Core delivers peer messages by writing into the session's PTY itself. A
   USER_INPUT whose payload matches a delivery core physically wrote into that session binds no origin.
   Comparison is exact bytes, ASCII-edge-trimmed bytes, or both sides decoded once for
   XML entities and then ASCII-edge-trimmed. This compares known physical evidence;
   it does not infer provenance from payload shape. Resumed-session re-submission and
   external automation stay uncharacterised and bind the seat as the submitter rule says.
3. **Dedup is core-side, per endpoint, session and filepath** (releases#317/#319):
   changing surrounding prose, including an original and edge-ASCII-trimmed report,
   re-registers nothing, emits no second helper notice, and extends no live TTL.
   A new endpoint or session may surface the existing URL. No adapter-minted id exists.
4. **Serving semantics from #17 / ADR-0058 Am.1, corrected by Am.2:** submitter's
   machine, 24h TTL, one live entry per path. A later authorized endpoint joins that
   entry's visible audience without changing its URL or original deadline.
   Helper delivery is once per receiving endpoint, session and filepath. A path that names no
   file on the submitter's machine is SILENTLY SKIPPED, with no fallback origin. The ordinary silent
   cases in (1) are not authorization failures. CLI broker-connect and unanswered-receipt failures are
   silent unless `SPT_PUMP_TRACE` enables diagnostics. Named declines apply only to failures with a
   remote controller; the broker's 10-second owner-reply timeout remains named. §4.7's historical
   all-but-one refusal rule is superseded.
5. **The stated ceiling, instead of an adapter promise.** The report lags acceptance by whatever the
   harness's own path costs (claude-spt: 0.5–1.0 s measured, n=3; omp-spt: unmeasured). A cross-operator
   Take inside that lag attributes the submission to the NEW holder, whose own file is then served to the
   agent that holder now controls. Core states this; it does not ask adapters to shrink it. §1's
   prohibition on sampling stands for anything core might build LATER than receipt — receipt is the
   earliest moment core has the payload, and it is the moment used.
6. **§4.1 token issuance and §4.5 grace period: STRUCK.** §7's adapter answers stay on record as
   measurements of the ceiling in (5), not as obligations.

**Build:** `REQ-INPUT-PROVENANCE-ACCEPTANCE-REPORT` activates doc/impl/unit in
the product lane. Adapter side: NONE. The integration stage awaits the separately
admitted two-node field leg.

### Implemented boundaries

- Both `api state` USER_INPUT and `api now-signal --user-input` check for quoted paths
  before broker IPC; a pathless payload produces no receipt request or line. Path-bearing
  reports precede event fanout, shortform processing, or roster gathering. Without a
  hosted session or remote controller, the broker silently binds nothing. Otherwise it
  snapshots the live remote controller connection before validating the harness session
  and checking physical delivery-byte evidence. A later Take never changes that origin.
  `api state` carries the caller's resolved session proof. A capability token
  can still authorize the state event, but cannot borrow a session ID from disk
  to mint input provenance.
- File requests and replies ride that same authenticated rc stream. The owner
  derives the audience from its own rc target, never from request-supplied
  audience text. The existing MSG_OUT-backed WEB ServeFor guard is unchanged.
- The receipt helper has one 500ms internal budget for acknowledgement **and**
  owner-result waiting, including a stalled connect/hello/write. It does not start
  a second budget after acknowledgement. Expiry does not cancel owner work; a
  late helper remains eligible for the next poll. CLI transport failures stay
  silent unless `SPT_PUMP_TRACE` is enabled. A same-node report deadline prevents
  a worker outliving the wait from binding a later seat. This is not an entire-hook
  bound or numeric adapter promise; other hook work has separate costs.
  The broker allows 10 seconds for the controller reply, then names the unanswered outcome.
  Owner work runs off the rc display/input pump. An unanswered request or uncertain
  owner RPC result retains its dedup fence for the possible reference lifetime:
  a lost reply is not proof that the owner exposed nothing.
- Dedup is per receiving endpoint, harness session and filepath in the broker-held
  PTY session; it preserves the first receipt's controller custody and deadline
  and survives brain replacement. Live records are not evicted to make room;
  capacity exhaustion refuses new grants by name. Lost or uncertain replies
  remain fenced rather than being treated as proof of no exposure.
  The owner reuses a live user-input reference and visibly admits later
  receipt-authorized endpoints to that same entry. It never extends the original
  deadline or rescopes unrelated registrations. The first timestamp is the
  earlier of receipt time and owner time, so clock skew cannot lengthen either
  side's 24-hour bound.
<!-- [doc->REQ-INPUT-PEER-ENTITY-EXCLUSION] -->
- Physical delivery writes retain fixed-size streaming hashes for exact bytes,
  ASCII-edge-trimmed bytes, and single-pass XML-decoded/ASCII-edge-trimmed bytes.
  The third comparison handles the five predefined XML entities and valid decimal/hex
  XML character references identically on both sides. Unknown or malformed references
  and bare ampersands remain literal; no line-ending or other interior normalization
  is applied. Decoding is not recursive: `&amp;amp;amp;` becomes `&amp;amp;`,
  not `&amp;`. A double-encoded report need not match; that limit is deliberate.
  Evidence is published in physical-write order, not when delivery is merely queued.
  Source-tagged controller/typeahead and choreography keys are not delivery text.
  In-progress or partially failed physical delivery writes make provenance unavailable
  by name when a remote controller is seated rather than guessing; no receipt blocks
  on a PTY writer. Session-lifetime evidence is never silently evicted (65536 distinct
  delivery candidates is the named capacity limit; all three variants share
  one candidate quota). A later human payload equal to a delivered body's decoded form
  is indistinguishable and is excluded too: this false positive is an accepted cost,
  not evidence that the human text came from a peer.
  The new broker computes the third hash at every successful physical text write.
  There is no retroactive reconstruction from old hashes because bodies are not retained.
  An old broker retains the old exclusion until it is replaced; a brain-only update
  does not close that upgrade window. External automation and native harness
  re-submission remain subject to the receipt-seat ceiling above.
- Missing files produce neither helper notices nor declined diagnostics. No quoted paths,
  absent hosted sessions, and local/viewer-only/no-controller seats are also silent.
  With a remote controller seated, wrong session, unknown delivery evidence, queue
  pressure, owner refusal, the broker's owner-reply timeout, and persistence failure
  each name their condition. CLI transport diagnostics remain gated by `SPT_PUMP_TRACE`.

### Pending field acceptance — not executed in the doc/impl/unit lane

The separately admitted two-node field leg must exercise a remote controller's quoted
path being served only to the receiving agent, and local input not being served.
Its hazard arm must keep a **remote controller seated while core physically delivers
a path-bearing peer message into the receiving session**: the ensuing USER_INPUT
report must cause **no serve**. A viewer-only or empty-seat run cannot prove that arm.
The same field leg must measure the added hook cost; the shared 500ms helper budget
is not an observed whole-hook cost. The measured basis and its LAN/tailnet limits
are recorded in ADR-0058 Amendment 2. These acceptance obligations remain pending and do
not activate `int` or impose adapter integration work. The historical measurements
in §7 are not execution evidence for this implementation.