# ADR-0083: Eve typed generative-UI confirmation

- Status: accepted for Phase 8 Task 8.6
- Date: 2026-09-09
- Owners: Eve Product, Security, Accessibility, and Evaluation
- Scope: capability-negotiated customer and admin web confirmations

## Context

Eve already emits an authoritative `action_confirm` intent when a model tool
call asks to make a change. The BFF resolves the human summary, parks the write
behind a session- and user-bound one-shot lease, and requires the client to post
Confirm or Decline. The existing web surfaces render deterministic controls.

Task 8.6 permits one versioned, allowlisted generated intent only if it improves
the existing UI and remains at least as reliable. The interaction design brief
requires it to stay inside the existing confirmation, status, or evidence lane
with a plain fallback.

## Decision

Adopt `eve.generative-ui.v1` with one component: `confirmation`.

The candidate is nested inside the authoritative `action_confirm` event and is
emitted only when a client declares both action confirmation and
`generative_ui_v1`. It adds a fixed review heading, explicit product scope, and
an explicit consequence/recovery row. It does not add commands, handlers, URLs,
HTML, component loading, or execution authority.

Clients apply an exact-key decoder and bind the candidate to the parent action
id, summary, and expiry. Unknown components, extra props,
`dangerouslySetInnerHTML`-like data, unsafe schemes, executable markup,
cross-action reuse, and stale state are rejected. Rejection does not discard the
parent action: the existing deterministic confirmation renders instead.

The generated state uses the same action id as its render key. Duplicate replay
does not create another card, while repeated server decisions remain governed by
the existing one-shot confirmation bridge.

## Admission floors

Adoption requires all of the following:

1. The candidate scores higher than the deterministic UI on the checked-in
   seven-part visible-information rubric. The rubric is cross-surface: a
   baseline item passes only when both the customer and admin confirmation lanes
   expose it consistently.
2. Every valid, unknown-component, hostile-prop/URL, executable-markup,
   cross-action replay, stale-state, and exact-replay case has the expected
   accept/fallback result.
3. Strict decoder p95 is no more than 1 ms over 30,000 measured iterations.
4. Customer and admin browser flows render the semantic lane, retain usable
   decisions and deterministic fallback, and pass automated accessibility scans.

The measured decision record is
`docs/audits/eve-sota-generative-ui-decision/2026-09-09.json`.

## Consequences

- The v1 registry is intentionally small. A new component or prop requires a new
  reviewed contract and decision; payload novelty is not self-authorizing.
- The server confirmation bridge remains the only write authority.
- Clients that do not negotiate v1 receive the prior wire shape unchanged.
- Automated accessibility is in scope here; manual assistive-technology
  interoperability remains owned by Task 8.8.
- Phase 8 and G9 remain open.