[EPIC] Conversational transactions — provisional intent, correction, validation, and commit #344

Open
opened 2026-09-08 02:03:35 +00:00 by nsaspy · 0 comments
Owner

Parent architecture: #624
Builds on: #150 semantic intents/dialogue/capability routing, #151 programmable commands, canonical runtime cancellation. Optional current Prolog-RLM/direct-mode model assistance may propose rewrites or candidates, but it is not commit authority.

Goal

Treat an ongoing spoken/text instruction as a transaction over intent state, not a sequence of immediately executable turns.

Users naturally self-correct:

Move the appointment to Tuesday — actually Thursday — tell John — wait, don't message him yet.

Zara must be able to accumulate provisional mutations, retract/replace them, validate the final intent graph, and cross an explicit policy-defined commit boundary before irreversible side effects occur.

Required model

Research and freeze a typed principal/conversation-scoped IntentTransaction or equivalent with:

  • stable transaction ID and runtime generation;
  • one or more related IntentFrames from #150;
  • provisional slot/action mutations with provenance and ordering;
  • correction/retraction/cancellation operations;
  • validity/conflict state;
  • authorization/capability requirements;
  • commit policy and commit reason;
  • terminal committed / aborted / expired state.

Conceptually:

BEGIN INTENT
  stage(move_event, thursday)
  stage(notify, john)
  retract(notify, john)
VALIDATE
COMMIT

No side-effecting provider invocation may happen merely because an intermediate utterance became syntactically complete when the transaction policy still considers the discourse open.

Commit boundaries

Research deterministic commit signals including:

  • explicit user confirmation when policy requires it;
  • stable end-of-turn/end-of-discourse boundary;
  • capability risk class;
  • elapsed silence only where voice UX evidence justifies it;
  • an unambiguous new unrelated task;
  • provider-specific irreversible-action policy.

Do not use an LLM/RLM confidence or rewrite result alone as authorization to commit.

Integration

  • #150 remains semantic intent/slot authority;
  • #151 authored commands compile into the same transactional path;
  • current Prolog-RLM/direct-mode support may assist bounded interpretation only behind the same validated semantic boundary;
  • cancellation/barge-in aborts or fences provisional work according to policy;
  • runtime/tool/device execution happens only after validated commit;
  • eventual causal-effect/undo work consumes committed transaction identity rather than inventing another correlation model.

Required tests

Cover complete/correct/cancel/reopen discourse, multiple slot corrections, action add/remove, two unrelated transactions, cross-principal isolation, reconnect/stale events, duplicate finals, timeout/expiry, explicit confirmation, model/RLM malformed or conflicting proposals, and an irreversible fake capability proving it is never called before commit.

Realistic corpus must include the appointment/message example plus timer, calendar, communications, SmartThings and multi-action authored-command fixtures.

Non-goals

  • no arbitrary natural-language transaction language;
  • no database transaction claim across third-party systems that cannot actually provide atomicity;
  • no weakening of typed capability authorization;
  • no unbounded model/RLM execution or direct model-to-side-effect path.

Acceptance

A user can naturally revise a multi-step instruction before commitment; Zara exposes one deterministic final intent transaction, executes only the committed effects, and proves that abandoned/superseded intermediate intentions caused no side effects.

Parent architecture: #624 Builds on: #150 semantic intents/dialogue/capability routing, #151 programmable commands, canonical runtime cancellation. Optional current Prolog-RLM/direct-mode model assistance may propose rewrites or candidates, but it is not commit authority. ## Goal Treat an ongoing spoken/text instruction as a **transaction over intent state**, not a sequence of immediately executable turns. Users naturally self-correct: ```text Move the appointment to Tuesday — actually Thursday — tell John — wait, don't message him yet. ``` Zara must be able to accumulate provisional mutations, retract/replace them, validate the final intent graph, and cross an explicit policy-defined commit boundary before irreversible side effects occur. ## Required model Research and freeze a typed principal/conversation-scoped `IntentTransaction` or equivalent with: - stable transaction ID and runtime generation; - one or more related `IntentFrame`s from #150; - provisional slot/action mutations with provenance and ordering; - correction/retraction/cancellation operations; - validity/conflict state; - authorization/capability requirements; - commit policy and commit reason; - terminal committed / aborted / expired state. Conceptually: ```text BEGIN INTENT stage(move_event, thursday) stage(notify, john) retract(notify, john) VALIDATE COMMIT ``` No side-effecting provider invocation may happen merely because an intermediate utterance became syntactically complete when the transaction policy still considers the discourse open. ## Commit boundaries Research deterministic commit signals including: - explicit user confirmation when policy requires it; - stable end-of-turn/end-of-discourse boundary; - capability risk class; - elapsed silence only where voice UX evidence justifies it; - an unambiguous new unrelated task; - provider-specific irreversible-action policy. Do not use an LLM/RLM confidence or rewrite result alone as authorization to commit. ## Integration - #150 remains semantic intent/slot authority; - #151 authored commands compile into the same transactional path; - current Prolog-RLM/direct-mode support may assist bounded interpretation only behind the same validated semantic boundary; - cancellation/barge-in aborts or fences provisional work according to policy; - runtime/tool/device execution happens only after validated commit; - eventual causal-effect/undo work consumes committed transaction identity rather than inventing another correlation model. ## Required tests Cover complete/correct/cancel/reopen discourse, multiple slot corrections, action add/remove, two unrelated transactions, cross-principal isolation, reconnect/stale events, duplicate finals, timeout/expiry, explicit confirmation, model/RLM malformed or conflicting proposals, and an irreversible fake capability proving it is never called before commit. Realistic corpus must include the appointment/message example plus timer, calendar, communications, SmartThings and multi-action authored-command fixtures. ## Non-goals - no arbitrary natural-language transaction language; - no database transaction claim across third-party systems that cannot actually provide atomicity; - no weakening of typed capability authorization; - no unbounded model/RLM execution or direct model-to-side-effect path. ## Acceptance A user can naturally revise a multi-step instruction before commitment; Zara exposes one deterministic final intent transaction, executes only the committed effects, and proves that abandoned/superseded intermediate intentions caused no side effects.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nsaspy/zara#344
No description provided.