Update

Exemplar page — proposal only, nothing shipped. No feature in Invoca’s product updates a record directly on a user’s behalf today. Everything below is design intent offered for review, not established policy. See Coverage, stated honestly.

What it is

Some changes to a call record are small, common, and clearly reversible: tagging a call’s disposition based on what the transcript shows, updating a Signal’s status, correcting a call that landed in the wrong category. Update is the system making that change directly — not proposing it, not drafting it for review — with the change taking effect immediately and a real, discoverable way to undo it. The distinguishing fact against Draft is timing: nothing about Update waits for a send or apply action. The record already reflects the new value by the time the user notices anything happened. That immediacy is the entire reason this tier needs to be earned, not assumed — it only belongs on changes cheap enough to get wrong and easy enough to reverse. This is proposal. No feature today changes a call record’s fields directly based on model output.

Choose this when / choose something else when

Situation	Do this instead	Why
The change is substantial free text or a new artifact — an email, a note	Draft	Update is for direct field changes, not compositions that need a review pass before they mean anything.
The change is high-stakes, hard to reverse, or affects other people, billing, or live traffic	Destructive confirmation	Update’s whole design depends on the change being genuinely undoable. Once it isn’t, this pattern doesn’t apply — that’s Acts, irreversible, and it needs a confirmation naming the consequence, not a toast.
The user wants to make the same kind of edit themselves, by hand	Inline editing	Update only earns its place when letting the system act first and correcting after is faster than composing the edit manually every time.

Agency tier

Acts, reversible. The system changes the record directly rather than proposing a change or drafting something for review — that’s what makes it Acts rather than Suggests or Drafts. It qualifies for the reversible tier and not the irreversible one only because undo is real, discoverable, and bounded in time, per the agency tier definitions. This is the same logic TITAN-DESTROY-01 uses for destructive actions: perform it and offer undo beats gating it behind a dialog, whenever undo is actually achievable.

Anatomy

┌───────────────────────────────────────────────────┐
│  Table / Card row for the call record              │
│   Disposition: [Tag: Sale — AI-updated]             │
│                                                     │
│  [Toast, bottom]                                    │
│   "Disposition updated to Sale.        [ Undo ]"    │
│   (visible for a bounded window)                    │
└───────────────────────────────────────────────────┘

Table or Card — the record itself, showing the new value immediately.
Tag — a persistent marker on the changed field distinguishing an AI-made change from a human edit, visible after the toast is gone.
Toast — confirms the change and carries the one-click Undo, for a bounded window.
Button — the Undo action inside the toast.

Outcome states

State	Treatment
Working	Brief — the change is computed and applied in one step. No intermediate state to render beyond the moment before the toast appears.
Streaming / partial	N/A. An update is a discrete field change, not generated text; there’s no partial value to show mid-run.
Confident and right	The field now holds the correct value, and the toast confirms it.
Confident and wrong	See below.
Uncertain	If the system isn’t confident enough to commit outright, it doesn’t act at this tier — it downgrades to a Draft-style suggestion instead, per TITAN-AIUPDATE-04.
Refused	The system declines to update (conflicting signals, insufficient basis). The record stays unchanged; the reason is stated, and manual inline editing remains available.
Empty	N/A. There is no empty-result concept for a single-record update — nothing to distinguish from a normal completed change.
Interrupted	The user navigates away right after the change triggers. Proposal: the update still commits — it isn’t gated on the user watching it happen — but the undo affordance must survive navigation (an activity log, not only the toast) or the recourse is lost along with the toast.
Degraded	Falls back to a simpler rule-based tag instead of a modeled judgment. Disclosed as part of the “AI-updated” marker, not folded silently into an identical-looking change.
Rate-limited / over budget	A bulk run of auto-updates is throttled with a limit stated before the batch runs, not discovered partway through it.
Stale	The value was right when set, but the call was re-transcribed or re-analyzed afterward and the earlier auto-update was never revisited. Undecided whether anything re-checks it; see Gaps.

Confident and wrong, in detail: because this tier acts immediately, a wrong value is live the moment it’s set — in the record, and in anything downstream that reads it, like a report or a dashboard — for as long as it takes someone to notice. The record itself gives no indication that this particular value might be wrong; it looks exactly like a value a person set correctly. This is the largest cost of misjudging this tier: unlike Draft, there is no review step standing between a wrong output and its consequences. The mitigations here are the ones that make the wrongness checkable after the toast is gone, not only during it — the persistent “AI-updated” marker on the field, and an audit trail that shows the prior value — because the person who notices the mistake is often not the person who was present when it happened.

Disclosure & recourse

Does the user know this is AI? Yes, and durably — the changed field carries a visible marker distinguishing an AI-made change from a human edit, not only a toast that disappears after the undo window closes.
What did it use? The specific call’s transcript or record data being changed. Not other calls’ data, unless a specific update explicitly states that it drew on a pattern across calls.
How sure is it? If the system isn’t sure enough to commit, it doesn’t act at this tier — see the Uncertain outcome state above. Confidence here changes tier, not just copy.
How does the user check it? The changed field shows its previous value, on hover or in an activity log, so the change stays auditable after the toast window closes — not only during it.
How does the user correct it? Undo, within the bounded window, reverts to the exact prior value in one action. After the window closes, the field remains manually editable exactly like any human-set value — recourse doesn’t expire, only its one-click form does.
How does the user get out? The auto-update behavior itself can be turned off, reverting to manual tagging going forward. A single instance can always be corrected manually via inline editing even outside the undo window.

Reference

No model, prompt, tool schema, latency budget, or cost has been defined for this pattern. Nothing in Invoca’s product performs this job today, so there is no source to generate this section from.

Evaluation

Not evaluated. No eval set, score, or failure-class list exists for this pattern anywhere accessible.

Content

Moment	✅	❌
Toast confirmation	”Disposition updated to Sale. [Undo]"	"Updated. [Undo]” (doesn’t name the value)
Persistent marker	”AI-updated”	No marker once the toast is gone
Refusal	”Couldn’t update — the call doesn’t have enough transcript to determine a disposition.”	Leaving the field unchanged with no message
Degraded fallback	”Set by keyword match, not a full review of the call.”	An identical marker for a modeled and a keyword-matched change

Accessibility

The update and its Undo availability are announced to a live region once, when the change completes — matching Toast’s existing announcement behavior.
Undo remains reachable by keyboard for the full bounded window, not only by pointer.
The “AI-updated” marker pairs an icon or text with any color treatment — never color alone, per TITAN-COLOR-03.
Focus stays on the updated record row after the change, rather than jumping to the toast — the toast is a secondary confirmation, not the primary content.

Constraints

ID	Constraint	Rationale
TITAN-AIUPDATE-01	A reversible field-level update commits immediately and offers Undo; it never blocks on a confirmation dialog.	Matches TITAN-DESTROY-01 — confirming a genuinely reversible action trains users to dismiss confirmations generally.
TITAN-AIUPDATE-02	The Undo window is real and bounded, never shorter than the equivalent Toast affordance elsewhere in the system.	A window too short to notice is undo in name only.
TITAN-AIUPDATE-03	The changed field carries a persistent marker distinguishing an AI-made change from a human edit, visible after the toast is gone.	The toast disappears; the record doesn’t. Recourse that only exists during the toast window fails anyone who notices later.
TITAN-AIUPDATE-04	A candidate change the system isn’t confident in downgrades to a Draft-tier suggestion rather than committing.	Acts, reversible earns its immediacy by only acting when the system is actually sure; uncertainty belongs to a lower tier.
TITAN-AIUPDATE-05	A refused update leaves the record unchanged and states why.	An unexplained non-change is indistinguishable from a silent failure.
TITAN-AIUPDATE-06	Undo reverts to the exact prior value, never a recomputed default.	A recomputed “undo” isn’t undo — it’s a second guess replacing the first one.
TITAN-AIUPDATE-07	Bulk or repeated auto-updates are throttled with a limit stated before it is reached.	An unstated limit discovered mid-batch is a worse failure than a stated one hit on schedule.

Divergences

Not applicable. Nothing is shipped, so there is no code behavior to diverge from.

Gaps

The length of the Undo window is undecided.
Whether the “AI-updated” marker persists indefinitely or clears after some period is undecided.
Whether a value is ever re-checked after the call it’s attached to is reprocessed or re-transcribed is undecided.
Who defines the confidence threshold below which a change downgrades to Draft rather than committing is undecided — related to the overview’s escalation gap.

Volatility

This page depends on an auto-update feature that does not exist. It should be reverified the moment any such feature is scoped for Invoca’s product, since the undo window, the marker behavior, and the confidence-downgrade threshold above are proposals, not observations of a built feature. Written 2026-09-02.

AI Experience overview

The agency tiers this page’s classification depends on.

Draft

The lower-authority tier for changes substantial enough to need review first.

Search

Finding the record before deciding whether it needs updating.

Destructive confirmation

What to use instead once a change stops being genuinely reversible.

Inline editing

The manual, deterministic version of the same field-level change.

Governors: Stream of thought

Where an audit trail of what the system changed and why would belong.

Why it works this way

Undo is doing real work here, not standing in as a lighter version of a confirmation dialog. Because the change is already live by the time anyone sees it, the design has to assume the person who notices a mistake is often not the person who was there when it happened — which is why the marker on the record has to outlast the toast, and why undo has to restore the exact prior value rather than a fresh guess. A tier that acts immediately only stays safe if its evidence of what happened outlives the moment it happened in.

Overview

Wayfinders

Inputs

Tuners

Governors

Trust builders

Identifiers

Actions

What it is

Choose this when / choose something else when

Agency tier

Anatomy

Outcome states

Disclosure & recourse

Reference

Evaluation

Content

Accessibility

Constraints

Divergences

Gaps

Volatility

AI Experience overview

Draft

Search

Destructive confirmation

Inline editing

Governors: Stream of thought

Why it works this way

​What it is

​Choose this when / choose something else when

​Agency tier

​Anatomy

​Outcome states

​Disclosure & recourse

​Reference

​Evaluation

​Content

​Accessibility

​Constraints

​Divergences

​Gaps

​Volatility

​Related

AI Experience overview

Draft

Search

Destructive confirmation

Inline editing

Governors: Stream of thought

​Why it works this way

What it is

Choose this when / choose something else when

Agency tier

Anatomy

Outcome states

Disclosure & recourse

Reference

Evaluation

Content

Accessibility

Constraints

Divergences

Gaps

Volatility

Related

Why it works this way