AISA Next — the client surface, wireframes

The customer is not a second class of operator; they see a different application built from the same case (D91). Four screens, one vocabulary — theirs. No transcript, no system names, no handles, no gate an operator owns; the client's one decision is acceptance (CG-11). Start a request is the target state (D81): the wireframe exists so that the intake contract is designed for rather than discovered, and it is not the first build. The top bar and the footer legend of the operator surface are absent here on purpose — no estate, no kill switch, no where-chips.

we need something from you · the customer's decisionready · donebeing worked · link · target state

15 · My requests — the customer's list, in customer words

Regions	filters (open · we need something from you · ready for your acceptance · done) · one row per request: title, kind, where it stands in their words, last update, their ticket or help-desk number with a link, whose turn it is · the vocabulary and the two rules under the table
Data	`CASES` ⋈ `GATES` ⋈ the contract's clocks, filtered to this customer; state words mapped from case states: received · we are looking into it · we need something from you · being fixed · checking the fix · ready for your acceptance · done. The contract promise and whose action is pending remain visible in customer words.
Three fields a channel cannot carry (D97)	origin — mail, ticket system, help desk, or started in place; modules involved — a support request that grew a configuration sub-case says so; initiator — who started it and when.
Workflow	W12 — see whether anything waits on them; a row opens the request.

16 · One request — a plain-words timeline and the one open question

Regions	title and chips (kind · where it stands · when and how it was asked · the promise) · the timeline received → understood → your confirmation → being done → checking → ready · the amber we need something from you card with an answer box · what happened so far in plain words · where it stands · attachments · a message box to the same people · Case view: Open the case view when the person's role set includes Viewer — the operator thread, read-only, handles instead of identifiers, no composer
Data	the case's statement — drafted and gated — never its papers; a `question` park addressed to the customer renders as the amber card; the promise is the contract's offer or resolution clock in words
Workflow	W12 — answer what only they can answer; the answer resumes the parked task and shows as a human card in the operator's chat, attributed to the Customer representative.
Absent by rule	the transcript embedded in a client screen · table names, environments, agent names, handles · any gate an operator owns · anything that widens a role · cost, budget, model, provider, kill switch, estate. The case view is a door behind the role check, not a client screen.

17 · Acceptance — what changed, how we checked it, the customer's decision

Regions	what changed in their words with their original request quoted · how we checked — what a person verified, and what they can check themselves · the green your decision card: Accept — it works as requested Ask for changes… · where it stands with the accept-by date · attachments · “not happy?” · See how it was done → the case view when the role allows
Data	`GATES` for the assigned business confirmation (H1/H3) or CG-11 preview/delivery, the artefact hash, the report paper in customer words, the review reminder date; no automatic acceptance is assumed
Workflow	W12 — confirming scope, a stage result or preview continues work; accepting a delivered result closes the request when its obligations are complete; accepting a preview does not close a pending release and is recorded with the person's name and the artefact hash like any other gate; asking for changes re-opens it with their note and the same people continue; a later change re-opens the acceptance rather than reusing it.

18 · Start a request — three kinds, plain fields, references we resolve (target state)

Regions	what is it about — something is wrong · I need a configuration change · I have a question · tell us in your words · references we resolve for them (a policy number shows found ✓ or a request to check it) · attachments · how urgent is it for your business as their proposal for severity · what happens next · what is not started here
Data	an arrival → identity/entitlement check → automatically opened Support case → classification; Inbox supports inspection/correction; kind maps to case type (incident · request · question); the intake contract is the same one a connector fills; `intake.initiation` per customer × role × module
The three outcomes (D97)	granted opens the case · may request opens an authorisation request that parks visibly · not granted refuses with the clause and keeps the description for the commercial counterpart. The kind list offers only what this role may start or request; a refusal is shown with its reason, never hidden or silently re-routed. The Customer representative may start support, may request configuration, may not start the Development module (id `source`).
Status	Target state (D81, formerly non-goal N-9): the first client slice follows the minimal case and gate protocol in the first Configuration wave. Until then the same arrival comes by mail, ticket or help desk and lands in the same Inbox.

Operator surface: admin_wireframes.html. Specification: the UI page of this wiki (§ 5b the client surface · § 4 W12 the customer's journey). Generator: gen_wireframes.py in this folder.