Keep prohibitions, missing obligations and conditional requests from becoming the opposite business action. Build a source-linked interpretation record and test what the workflow is actually allowed to do.
“Cancel the visit” and “Do not cancel the visit” contain almost the same words. An extractor that returns only action: cancel can turn both into identical work. The problem is not missing vocabulary. It is losing what the sentence says about the action.
LLM negation handling is the interpretation of which proposition is negated, what the negation applies to and how that changes the proposed next step. In business automation, it must also distinguish a prohibition from a statement about the past, a question or a condition that has not been met.
The following is a recommended design for ordinary operational requests, with constructed examples—not a tested customer implementation, a model performance claim or a promise that a workflow platform supplies these controls automatically.
Identify the statement before proposing an action
A keyword label such as “cancellation” is useful for finding the right queue. It is not an instruction to cancel. Preserve the original statement and make the interpretation explicit before creating a proposed state change.
Research provides a reason to evaluate this separately. The EMNLP 2023 negation benchmark found weaknesses in negative-sentence understanding in the models it evaluated. More recent Thunder-NUBench research examines sentence-level distinctions beyond simply detecting a negative word. Neither study tells you the failure rate of your current operational workflow.
Define these dimensions independently:
- Proposition: the actor, action and affected object—such as the service coordinator cancelling visit V-204.
- Polarity and scope: which proposition or part of it is denied. “Do not cancel the visit” negates cancellation, not the existence of the visit.
- Speech act: a request, prohibition, question, reported fact or uncertain interpretation.
- Modality: whether an action is required, permitted, optional or conditional. “You do not have to reschedule” removes an obligation; it does not prohibit rescheduling.
- Condition: the event or evidence that must exist before a candidate may advance.
Do not collapse these dimensions into one approved boolean. A positive request can lack authority. A correctly understood prohibition can require attention without creating a replacement action.
Give each candidate a source-linked interpretation record
Use the broader AI data contract as a foundation, then add the meaning-specific fields needed for review. The following packet is a design asset, not a provider-defined schema.
| Field group | What to preserve | Release question |
|---|---|---|
| Source and attribution | Case ID, source revision, author identity, exact passage and source offsets or another resolvable locator. | Can the reviewer see the original statement and who made it? |
| Proposition | Actor, proposed action, target record and original object wording. | Are we interpreting the right action on the right object? |
| Negation evidence | Cue span, affected proposition span, polarity and unresolved scope alternatives. | What precisely is denied or prohibited? |
| Modality and conditions | Speech act, obligation or permission status, condition expression and required evidence reference. | Is this an instruction now, a report, or a contingent proposal? |
| Disposition | Candidate ID, interpretation version, reviewer, reason and allowed next state. | Was meaning accepted, held for clarification or rejected? |
| Execution boundary | Separate permission result, current target version, approved payload and operation receipt. | Was an authorized change applied once and read back? |
For “Do not cancel V-204; reschedule only if the supervisor confirms,” retain two candidates. The first records a prohibition on cancellation. The second records a conditional rescheduling request. Do not convert the pair into “reschedule V-204 now.”
If the source is an email, establish authorship and quotation boundaries first. The email-thread extraction workflow addresses that upstream problem. Accurate attribution still does not establish the polarity of the attributed sentence.
Separate interpretation from the release gate
AI proposes meaning; rules check the packet
Give the model the authorized source passage, relevant surrounding context and a bounded action vocabulary. Ask for separate candidates with source evidence and explicit unresolved interpretations. Keep tools that change production records outside this extraction step.
Deterministic checks can confirm that required fields exist, quoted spans occur in the retained source, candidate actions belong to the allowlist and target IDs are in scope. They can also verify a condition against an authoritative record. Those checks cannot, by themselves, prove that a model understood the sentence.
A keyword rule that blocks every sentence containing “not” is not a semantic validator. It would mishandle “Not only should we inspect the site, we should photograph it.” Research on different negation cues also supports evaluating a broader range of linguistic forms rather than treating one token as the whole problem.
People resolve uncertain meaning; systems authorize changes
Initially require a qualified operations reviewer before interpreted free text changes a customer commitment. Show the original passage, each candidate, the affected scope, competing interpretations and current case state. A second model can suggest discrepancies, but agreement between two model outputs is not proof of meaning.
When scope is unclear, ask a targeted question: “Should V-204 remain scheduled, or should it be cancelled?” For “I don’t think we shouldn’t reschedule,” do not silently remove the negatives and choose an action. Hold the candidate until an authorized person supplies an unambiguous instruction.
Accepting the interpretation means only that its meaning is agreed. The application must separately check the requester’s authority, applicable approval, current state and permitted transition. A prohibition may block the proposed cancellation route, but it does not authorize an unrelated booking change.
Use an acceptance matrix that changes with meaning
These are illustrative expected outcomes for a conservative pilot, not measured model results. Test both the interpretation and the absence of an unauthorized side effect. Define the business object and requester permissions in each fixture.
| Source statement | Expected interpretation | Permitted workflow outcome |
|---|---|---|
| “Cancel V-204.” | Affirmative cancellation request. | Create a cancellation proposal; require the separate authorization gate. |
| “Do not cancel V-204.” | Prohibition on cancellation. | No cancellation write from this statement; preserve and route the constraint. |
| “I did not cancel V-204.” | Report that cancellation did not occur. | Do not infer a command to cancel, reopen or reschedule. Check actual system state if relevant. |
| “You do not have to reschedule V-204.” | Absence of an obligation to reschedule. | No automatic reschedule or prohibition. Seek clarification if a decision is needed. |
| “Reschedule V-204 only if the supervisor confirms.” | Conditional rescheduling request. | Hold until specified confirmation exists; confirmation alone still does not bypass other approvals. |
| “Did you not cancel V-204?” | Question about cancellation. | Route for state checking or a response, not a cancellation command. |
| “Do not cancel V-204; cancel V-205.” | Different polarity for two targets. | Keep V-204 out of the cancellation proposal; review V-205 separately. |
| “Not only inspect V-204, but also photograph it.” | Additive construction, not a prohibition on inspection. | Create two proposals, each subject to applicable permissions and review. |
Add paraphrases, punctuation changes, indirect requests and examples with no negative cue. Keep unchanged-meaning pairs alongside meaning-reversing pairs. Otherwise a test that rewards every output changing after a textual edit can reward the wrong behavior.
Walk a prohibited cancellation and conditional change to closure
In a constructed service scenario, a customer submits: “Do not cancel V-204. Reschedule it only if the supervisor confirms access.” The supervisor has not yet confirmed.
- Capture: the intake system stores the source revision, verified sender context and target visit. It preserves the full passage rather than a cancellation keyword summary.
- Interpret: AI returns the cancellation prohibition and conditional reschedule as separate candidates, each with its supporting span.
- Review: the operations owner confirms the intended meaning. The reschedule candidate remains in Waiting for condition; interpretation acceptance is not execution approval.
- Check evidence: the system looks for the designated supervisor’s confirmation on the correct visit. A model saying “access is probably confirmed” does not satisfy this gate.
- Authorize: after confirmation arrives, the reviewer selects the proposed new slot, checks authority and approves that exact payload against the current visit revision.
- Apply and verify: the application uses a stable operation identity, records the result and reads back the visit. Closure requires the intended new slot to be observed—or an owned exception—not merely an extraction success.
If the customer revises the request while review is pending, mark affected candidates Superseded. Reinterpret the new source revision; do not carry an old approval onto changed wording or a different slot.
Recover without interpreting a failure as permission
- Invalid output: allow a bounded extraction retry against the same source and configuration; preserve earlier candidates and errors. Exhaustion routes to manual review.
- Missing context or uncertain scope: use Needs clarification with an owner and follow-up deadline. Repeated generation does not supply the missing intent.
- Unavailable confirmation source: keep the condition unresolved. Retry the failed read when policy permits; never convert a timeout into “confirmed.”
- Human rejection: retain the reason and close or replace the candidate explicitly. Do not automatically resubmit until someone approves.
- Uncertain write outcome: enter Reconciliation required and inspect the original operation receipt and destination state before any retry. Do not issue another change because the first acknowledgment is missing.
Persist source and interpretation versions, candidate dispositions, condition evidence, approvals, operation identity and observed result under the organization’s access and retention policies. A closed case should show either a verified authorized outcome or a documented non-action disposition.
Measure meaning errors and unauthorized effects separately
Use a reviewed, representative evaluation set for the particular workflow. Report polarity/scope agreement and speech-act agreement separately: an extractor can identify a negative statement while mistaking a report for a prohibition.
Track action-inversion cases, conditional actions released before evidence, unauthorized writes, clarification volume, reviewer disagreement and time spent waiting for conditions. Define each denominator. For example, premature-condition release rate is releases without the required condition evidence divided by all releases that required that condition—not all incoming messages.
Inspect failures by cue type, action and channel. Include ordinary positive requests to detect overblocking. Set release criteria according to consequence and observed evidence; there is no universal confidence score in this design. Run the suite again when the model, prompt, source parser or business policy changes.
Where Workhint fits
Workhint’s Workflow Engine describes role-based request approvals and required information before work progresses. Those capabilities are relevant when an ambiguous interpretation needs an accountable reviewer rather than an immediate state change.
Its workflow automation software page describes structured forms, conditional routing, review stages and assigned approvers. These are useful requirements to evaluate around a separate interpretation service. The cited pages do not establish a built-in negation detector or the exact semantic packet, validation logic or execution controls proposed here.
Bring the source examples, expected dispositions and reviewer responsibilities to workflow design. First decide what must remain blocked, what evidence resolves it and who can authorize the final change.
Frequently asked questions
Can a prompt saying “pay attention to not” solve this?
It can guide extraction, but it does not establish correct scope, requester authority or action permission. Evaluate representative examples and keep consequential writes behind separate gates.
Does a prohibition authorize the opposite action?
No. “Do not cancel” is not automatically an instruction to reopen a cancelled visit, select a new date or notify a customer. Those require their own interpretation and authorization.
Should every conditional request be rejected?
No. Preserve it as a contingent candidate with a named condition, evidence source and owner. Advance only when the condition and remaining release requirements are satisfied.
What if two reviewers disagree about the sentence?
Keep the candidate unresolved and obtain clarification from an authorized source. Record the competing readings and the final disposition rather than treating reviewer majority as the original requester’s intent.
Leave a Reply