Operations · Guide
Do not let AI choose the next step from an error’s wording
Use stable problem categories and reviewed rules to route errors, with AI explanations and a human path for unknown cases.
Do not let AI choose the next step from an error’s wording
Original AAHouse explanatory video. AI-assisted conceptual visuals and neural narration; original music.
English transcript · Simplified Chinese Mandarin transcript · Taiwan Mandarin transcript · Macao Cantonese transcript
One error, two different readers
Imagine an AI assistant at a U.S. event-services company receiving an error after submitting a work order. A person needs an explanation; automation needs to decide whether to request information, contact an owner, or wait. This is a fictional triage exercise, not a reported incident. A fluent explanation can hide a wrong action when the system lets a model infer the next step from wording alone.
- Person: understand the problem
- Code: choose reviewed route
- AI: explain, not authorize
Unchanged original source explanatory diagram.
Stable identifiers for machines, explanations for people
RFC 9457 defines a problem-details format for HTTP APIs. Its type identifies the problem category, while detail explains this occurrence. The specification discourages extracting decision information by parsing detail.[1] Our recommendation is to route recognized categories through reviewed rules and let AI explain the result, rather than using changeable prose as a control switch.
- type → problem category
- detail → occurrence explanation
- Changing prose ≠ control switch
Unchanged original source explanatory diagram.
Adapt to the provider’s actual format
Microsoft Graph uses its own error object. Its code supports programmatic handling, while message is developer-facing text that can change and should not be used as a code dependency or shown directly to users.[2] Not every service shares this structure. Build adapters from each interface’s documentation, then route understood categories into the business workflow. Send unknown categories for review.
- Read provider documentation
- Recognize stable codes
- Unknown category → review
Unchanged original source explanatory diagram.
“Unable to complete” does not choose an action
In the exercise, a missing work-order date could go back for completion, while insufficient permission goes to the authorization owner. These are proposed business mappings, not rights granted by a status code. An AI assistant must not expand permissions simply because an error mentions access, or turn every failure into a retry. Preserve necessary response evidence and distinguish known facts from uncertainty.
- Missing date → complete input
- Missing access → contact owner
- Failure ≠ automatic retry
Unchanged original source explanatory diagram.
Help the customer without exposing internals
Our suggested customer message is practical: “Please add the event date, then submit again.” Do not casually paste exception stacks, tokens, or private content into it. RFC 9457 cautions about error messages exposing implementation details.[1] A useful explanation helps someone recover their work; it does not deliver every debugging detail.
- Explain the recovery step
- Exclude secrets and private data
- Protect internal diagnostics
Unchanged original source explanatory diagram.
Change the wording on purpose
Prepare fictional samples with the same stable code but different English wording or Chinese text. The handling route should remain unchanged. Add an unknown code and verify that it does not trigger a dangerous action. Record the matching rule, explanation, and human-review route. These are proposed acceptance tests, not customer-system results. The goal is explainable triage, not more confident-sounding errors.
- Same code, different wording
- Same handling route
- Unknown code, no dangerous action
Unchanged original source explanatory diagram.