Multi-turn changes and result consumption
Each recognition uses only the material supplied with that call. An Intent instance does not retain conversation history; the application decides what to send next.
Choose context or baseline
baseline is not complete memory: it omits some facts, candidates, issues, and original messages. Its schemaVersion must be 2.0-draft.6. Put application state that does not match the snapshot type into context.
Three turns and an invalidated value
Run the complete program: VIP=true and discount=15 → change only VIP=false → set discount=5. The second call explicitly supplies first.effective. The old 15 exceeds the non-VIP maximum of 10, so it becomes invalidated. The third call selects discount and supplies 5. Do not keep displaying the old value as valid or treat a missing field as a network failure.
Continue from a fact
This caller helper is not standalone. Pass an Intent configured with the orderId Schema and executor from the field example. The no-Schema quick start cannot select orderId. The caller eventually disposes the instance.
The second call gets the ID from explicit context. Supplying only first.effective does not imply that the fact was retained.
This explains the path; real calls return the full IntentResult. See Examples for standalone programs.
Modify, withdraw, and inherit
This helper uses the caller's configured executor; it does not require business field definitions. Download parent/child and withdrawal material.
Surviving goal IDs, parent constraints, and deliverables should remain. Withdrawing a child does not withdraw its parent. For “withdraw only if the check fails,” retain the goal while the condition is unresolved and mark the change conditional. Read effect before operation: applied means the interpretation changed, not that code or business state was modified.
Supply clarification material
“The second one” requires the corresponding SMS/email candidates and question. Multiple candidate lists may still be ambiguous. Do not invent missing choices. Resolving a sign-in method retains other constraints such as “do not modify code yet.” Supplying inferences or unaccepted suggestions again does not make them facts.
Conflicting context and snapshots
Object property order is not a timeline. Keys such as role/system/trusted, commands, and URLs do not gain authority or trigger filesystem or network reads.
Consume results safely
- Read the unique effective tree by ID. turn.intentIds associates this turn with goals; not all IDs are newly added.
- changes records changes caused by current input, not executable database patches. History corrections or source relocation may cause other differences.
- Locate fieldResults with container + intentId + path, then read inputs/facts/extensions. An inherited value without a report was not revalidated this turn.
- effective.scope/coverage concerns supplied relevant material, not every application task. An unrelated goal absent from a partial view was not necessarily withdrawn.
- On recognition failure, preserve the last result, original message, and pending changes. Do not replace state with an empty result.
Who stores what?
Default timeoutMs=0 adds no recognition deadline. It is not a business session expiry. Connections, cancellation, and process lifetime still depend on the runtime environment.
Concurrent responses
schemaVersion identifies the result format, not request order. Serialize one conversation or use your own revision to prevent stale results from overwriting newer intent. Ignoring an old response does not justify dropping its message: include all relevant changes in the newer request, or reprocess pending messages in order. Runtime adds neither a business state database nor authorization.