skip to content

A supplier can re-author one directive sentence into an invoice line, a portal comment or an address block - why is that cheap?

level: middleimportance: should knowfreq 52%

answer

  1. the sentence, not the field, is the work
  2. no new access is needed
  3. one relationship, several free-text surfaces
  4. one screen, one arrival path
  5. it stops where the field is never read

basics

~20 s

The work is the property that makes an assistant read the span as instruction, and that property is channel-independent. The supplier already writes every free-text field of the relationship, so a second carrier costs one more ordinary submission.

solid answer

~40 s

What makes the span work is that it supplies a plausible business reason for a settlement action, in text an assistant is reading as part of its task. Nothing about that property is tied to the field it sits in, so it survives being retyped elsewhere. And no access is gained by moving it: an invoice line, a supplier-portal comment thread and the address block on the next submission are all fields the supplier is entitled to write, because that is the business relationship. So the second carrier costs one submission. Each intake path, meanwhile, is a separate integration, and the inbound-document screen on the emailed and EDI intake never sees the portal write path or the supplier master-data path. That asymmetry is why the arrival half of a finding is the cheap half.

go deeper

for a junior

Recall that the same sentence can be typed into several fields a supplier is already allowed to write, and that the model sees whatever is rendered into its prompt regardless of which field that was.

for a middle

Explain the mechanics: what property makes the span read as instruction, why that property is channel-independent, and which arrival paths a screen wired to document intake never observes. Name at least one condition where re-authoring fails.

for a senior

Show the arithmetic you would put in a report: one authored sentence against several independent intake integrations, and what that implies about closing the finding from the arrival side.

for a principal

Own the framing when somebody proposes buying coverage carrier by carrier, and be able to say what that spend is bounded by and where the count of carriers stops growing.

## What actually costs the attacker something It is tempting to think of a working injection as a *string*: something quotable that can be blocked once it is known. That is the wrong model of the cost, and it is why intake-side fixes disappoint. The part that took effort is a **property**, not a wording. The span has to read, to a model that is midway through a document-processing task, as a legitimate part of that task - it supplies a reason the task changed, phrased in the register of the surrounding commercial document. Finding that framing is the work. Once found, it is a sentence, and a sentence carries no channel-specific structure. Retyping it into another field costs nothing, because the field never contributed anything to why it worked. ## Why a second carrier needs no new access In an unattended procurement and settlement workflow, the supplier is a party to the relationship, not an intruder. That relationship exposes several free-text surfaces: | Surface | Who may write it | Which intake path it enters on | |---|---|---| | Line-item description, remittance note, delivery-instruction line | the supplier, on their own submission | emailed or EDI document intake | | Supplier-portal comment thread | the supplier, on the portal | the portal write path | | Address block on the next submission | the supplier, as master-data change | the supplier master-data path | Every one of those is a routine, permitted write. Nothing is escalated, nothing is stolen, and no control is bypassed to use the second one. This is why a finding here is so easy to reproduce and so hard to close from the arrival side. ## The obstacle, and what it does and does not cover The screening that exists in this workflow is an inbound-document scanner wired to the emailed and EDI document intake. That is one arrival path. The portal write path and the master-data path reach the same assistant context without ever passing through it. Add the batch schedule - the run happens overnight and nothing is skimmed between the model reading the text and the finance write committing - and there is no second look anywhere in the sequence. Naming that obstacle matters for reasoning about the finding; where a screen *should* have gone is somebody else's decision and a different conversation. What is relevant here is the arithmetic: covering one carrier is one integration's worth of work per carrier, and re-authoring is one submission. ## Where re-authoring stops paying off The construction is not free of constraints, and a good candidate names them: - **The field has to reach the model's context.** Plenty of fields a supplier can write are stored by the finance system and never rendered into the assistant's prompt. Re-authoring into one of those buys nothing, and the supplier has no direct way to see which is which - working that out takes observation and time, and it is the part of the effort that is genuinely expensive. - **The field has to survive intact.** A field that is truncated hard, normalised, or parsed into structured values may drop the span or strip what made it read as directive. - **The span has to still land as instruction in its new surroundings.** Text that reads naturally inside a commercial document can read as obviously out of place inside a short address line, and an assistant summarising a master-data change may not be in a position to act on it at all. - **Nothing is guaranteed twice.** The model is probabilistic; a carrier that works in one run may not in the next, which matters enormously when somebody has to decide whether a report is a reliable finding. ## Reading two paths' behaviour correctly A span blocked on the document intake and obeyed through the portal does **not** mean the portal has a weaker screen. In this workflow it means one path was inspected and the other was not routed through anything at all. Silence is not a measurement. Equally, a block proves that path scored that span above its threshold - it says nothing about a re-authored variant, and nothing about whether the assistant would still act on the same idea phrased differently. ## Why this is the load-bearing fact for triage If the arrival is cheap for the supplier and expensive for the buying company to cover path by path, then a finding described purely by its arrival is describing the half that will keep coming back. The half that does not come back for free is the privileged operation the obeyed output reached - and that half has a different owner.

  • Where does re-authoring into another supplier field stop paying off?
    Where the field never reaches the assistant's context. Plenty of fields the finance system stores are never rendered into the prompt, and a span sitting there does nothing. The supplier cannot see which fields are read, so working that out takes observation across runs - that measurement, rather than the writing, is the genuinely costly part.
  • The span is blocked on the emailed-invoice path and obeyed via the portal. Does that mean the portal's screening is weaker?
    No. It means one path was inspected and the other was not routed through anything. A block proves that path scored the span above a threshold; silence on the second path is not a measurement of strength, it is the absence of a measurement. Reading it as a strength difference sends the follow-up work to the wrong place.
  • Does an assistant treat text from a supplier portal differently from text in an emailed invoice?
    Not by itself. Once both are rendered into the context they are just tokens in a prompt; provenance only exists if the surrounding application put it there and the model was given a reason to weigh it. That is exactly why the carrier is interchangeable from the supplier's side.

saying these in an interview costs you the question

  • Thinks a working injection is a quotable string rather than a property
  • Assumes the supplier needs extra access to use a second field
  • Reads silence on an uninspected path as a weak screen
  • Believes the model ranks text by which channel it arrived on
  • Cannot name any condition under which re-authoring fails

context