Boundaries should be told before the attempt, not after the failure

What it is

Sending the sentence has already spent wording cost and expectation. A popup that then says “this system does not handle that request” may be accurate and still mistimed: the act has happened, and trust has already been settled on “it will take this.” Pre-attempt boundary disclosure wants the boundary visible before the attempt — while the input has not yet been treated as a submit.

A notice after failure is a repair, not a disclosure. Repair explains why it just failed. Disclosure is meant to stop that submit from existing.

Why it happens

Submit is the commitment point. Before send, people are still forming intent; a boundary can rewrite the intent (switch tools, rephrase, not ask). After send, the same sentence becomes material for blaming the miss, often read as a dodge. Expectation was encoded as “the system will handle this”; the miss is booked as disappointment, not as “I should not have asked.”

Just-in-time help is praised on deterministic flows because it arrives at the step that needs it. On a generate surface the need is before investment starts: once a long prompt is underway, sunk cost pushes toward submit even if a grey warning appears mid-way. So the boundary has to sit at the start of investment, or — last window, not first — at the moment a high-stakes intent is parsed and not yet executed.

Studying it

Three timings: boundary on open, in-input once a class is recognised, after a failed submit. The task is a clearly out-of-bound request (prescribe, send this complaint). Dependent variables: whether they still submit, edits before submit, who is blamed after failure, whether they finish the goal on another channel.

In-input prompts must measure “saw it and sent anyway.” Seeing is not in-time — sunk cost has already beaten the warning.

Where it stops holding

For fluent users and a stable boundary, reading a cannot block on every open becomes noise; intercept on recognised out-of-bound intent is enough. First use, high stakes, and a boundary that just changed still default to beforehand. The recogniser itself will false-alarm: too early hurts legal tasks, too late falls back to after-failure. This entry does not discuss what the negative list contains, only when that information appears.

Applying it

• Put the two or three boundaries this product is most often asked to violate near the empty state and the input, visible before a long prompt is written.
• When a high-stakes intent is parsed, stop before send: spread what would happen, offer rewrite or cancel, do not generate and then apologise.
• After-failure copy may remain as repair, but must not be the only boundary channel. If most boundary impressions in the stats happen after a refusal, timing has failed.
• Check: ask a new user to do a task you explicitly do not do, and see whether they had a chance to see the boundary before the first submit. Submit without seeing is a timing failure, however accurate the copy.

Related

• Same group: L1.02.1 What the system cannot do needs stating as much as what it can · L1.02.3 Boundaries change with versions; the statement must update with them
• Nearby: L2.09 Discoverability of what I can say · L4.07 Pre-action confirmation · L1.06 Graceful degradation of AI failure
• Search terms: pre-attempt boundary disclosure · just-in-time too late · sunk-cost submit