Confirmed before it runs: how Kav handles a write

Asking a question and asking for something to happen are different problems. Get a question wrong and the resident asks again. Get a write wrong — a moved appointment, a submitted form, a cancelled service — and something real changed on a guess.

What the resident sees

A service firm's assistant gets asked to move a consultation. Instead of just doing it, it shows a card: the old time, the new time, and one line — awaiting your confirmation. Nothing happens until the resident presses confirm.

Why this isn't just a UX pattern

In Kav, a capability that changes something is declared write, and that declaration carries real consequences, not just a label. It requires an explicit confirmation turn before it runs. It carries an idempotency key with a dedupe window, so a doubled tap — or a doubled request from a flaky connection — doesn't double the action. And if the same request looks like it might already be in flight, the platform doesn't guess; it routes to a possibly-duplicated outcome that a person resolves, rather than silently re-running something that may have already happened.

What the model is and isn't allowed to do

The model can propose a write and describe it in the resident's own words. It cannot decide, on its own initiative, that the write should happen. The confirmation card is fed by the same typed capability output as any read — the appointment time, the fee, the reference number all come from the underlying system, never authored by the model — so what the resident is confirming is exactly what will run, not a paraphrase of it.

Why it matters

A support conversation that can only ever tell a resident something is safe by construction. One that can also do something is where a hallucination stops being an embarrassment and starts being an incident. Confirming before it runs, with an idempotency key behind the confirmation, is what lets Kav do both — answer, and act — without asking an organization to trust a guess.