AISA Next — the operator surface, wireframes

One administration section in serdica-ui (Platform PG-5). The chat is the workspace (D119): a case is one thread of cards; everything else finds, routes, decides, builds or controls. Eight workspaces behind role-dependent front doors, fourteen screens. Every screen is generated from one script (gen_wireframes.py) so the shell, the palette and the vocabulary are identical; the screens fix regions, vocabulary and data — not styling, which follows the host's administration look (PG-26). The sample data is generic: a premium that differs between the two systems, a vehicle model missing in pricing, a transfer that fails for an annex.

human decision · gaterunning · read-only · greenparked · link · target staterefused · failed · ddlENV · SYSTEM · OBJECT = where

01 Inbox
02 Cases
03 Case chat
04 Case at a gate
05 Where
06 Decisions
07 Plan gate
08 Studio
09 Studio version
10 Knowledge
11 Metrics
12 Control · Connectors
13 Control · Roles & policies
14 Control · Exceptions & kill switch

The shell is the same on every screen: top bar (product · breadcrumb · search / · estate · kill-switch state · the viewer's roles), left rail (WORK Inbox · Cases — DECIDE Decisions — BUILD Studio · Knowledge — OBSERVE Metrics — CONTROL Control — the client app), a footer naming the screen and the rows behind it. The backs: lines are design annotations, not rendered text.

Work

01 · Inbox — arrivals re-briefed from their source

Regions	filter chips by door (ticket system · mailbox · help desk · monitor · duplicates) · the arrivals list (title, source chip with external id and time, proposed classification) · the selected brief: source, what was said (normalised), identifiers → handles, duplicate verdict, proposed classification with the two clocks, precedents, initiator · one action row
Data	arrivals → intake briefs built by `platform.intake`: origin key (channel + external id, D98), resolved handles with where-chips, dedup verdict, classification (SG-11 — auto by design), precedents from closed cases and active knowledge
Workflow	W1 — classification H1 is recorded automatically; the Operator's correction is a new H1 revision: Open case Correct & route Merge into #… Dismiss. Cases and clocks start from authorised arrival; the click opens the existing case. A correction becomes an eval example for the classification prompt (W9).
Roles	Operator acts; Viewer reads. Policy-ignored senders stay visible and silent.

02 · Cases — every case, its state and where it is

Regions	state chips as filters · one row per case: id and title, module · stage, state chip, where (env · system · object), controller, waiting on, clock · who is waited on · clocks at risk · keyboard help
Data	`CASES` ⋈ `SESSIONS` (controller) ⋈ `GATES` (waiting on) ⋈ the classification's two clocks. State words: opened · running · parked (question · gate · sub-case · connector-down · provider-down · budget · capability-gap) · at gate · held · resolved · closed. Held batches are rows here (they are cases).
Workflow	W2, W3 — a row opens the case chat; bulk actions for the Operator: park · take control · hand over. The Approver sees the same list filtered to waiting on: Approver — one list, role-filtered, not a screen per role.
Formerly	the “Sessions” screen of the first draft.

03 · Case chat — the workspace

Regions	left: case header (id, state, type, contract class, customer, clock), the module's stage ladder with the gate each stage carries, sessions (live · stopped) with controller and viewer count · centre: the thread of cards, the status line, the composer with its permission line · right: Where — source, systems touched with mode, papers, linked cases and knowledge
Cards	brief agent tool question plan decision verdict write handover · consult status human — every card carries where-chips; a tool card shows mode, a one-line result summary and never rows.
Data	ledger events over SignalR (per case/session ticket); `TASKS` (tool calls with env · system · object · mode); `PAPERS` (Plan, Semantic contract, Write log, Build state, MISSING, Report); `GATES`
Workflow	W2 (follow), W3 (steer · answer · stop · hand over) — slash commands `/steer /answer /stop /resume /handover /consult /park /where /papers /try /help`; the status line reads state · stage → next · tool calls · elapsed · human minutes · budget left (minutes, D117).
Rules	many viewers, one controller; stated reasoning, not chain-of-thought; the composer's second line always states the typist's permission; viewers have no composer.
Formerly	the “Session view”.

04 · Case at a gate — the decision is a card in the same chat

Regions	the same chat; a verdict card (the H3 given at S4), an agent card (S5 requesting the write), and the amber decision card, kept focused: module › agent › case · step of the plan · to whom · controller, then one line each of what · where (write chip) · why, the options — approve · reply with a different approach · refuse — and a collapsed Details line (evidence, shape 2 / 3, blast radius, policy checks, grant). The Where rail gains This decision: the grant an approval would issue.
Data	`GATES`, `GATE_DECISIONS`, `GRANTS` (env × system × target × mode · artefact hash · expiry), `WRITE_SHAPES`, `HELD_BATCHES`. PROD is customer-facing, so the write carries H5 on top of HW-instance (D114).
Workflow	W4 — the holder of Approver for this target approves → a grant → the write executor runs the 5-step write → a write card → S6 verification; refuses with a reason → the case parks (gate); asks → the agent answers in the thread without approving anything. W5 — each clean, person-confirmed instance counts towards lifting the shape (D112); H5 remains human unless this exact risk/target has an accepted decision.
Rules	approval is a permission, not a second person — an Operator who holds the role decides their own case in one action, and this estate withholds Approver(PROD) from its operators as a role-set choice; the packet — not the chat — is what is approved; a changed artefact re-opens the gate.

05 · Where — everything the case touched

Regions	environments as columns (with customer-facing marked), systems as boxes, objects as handles with a mode chip (read · write · ddl · send · source) · papers · sessions and links (sub-cases, consults, precedents, held batches) · the mode legend
Data	`TASKS` (every tool call's env · system · object · mode), `PAPERS`, `SESSIONS`, `GATES`, `CONNECTOR_SCOPES`. Nothing here is typed by a person — it is the trace of what the agent actually touched.
Workflow	W2 — reached from any where-chip on any card and from the rail's Expand; read only for every role.

Decide

06 · Decisions — every waiting gate across all cases

Regions	tabs pending · mine · held batches · shapes · history · the queue: gate kind, case, proposed by (module › agent), what, where, age, waits on (person · role) · held batches with the person they wait on · shapes with state and clean-instance count · history of decisions with the person, the role and the reason. Sample people are illustrations, not role assignments.
Data	`GATES`, `HELD_BATCHES`, `WRITE_SHAPES` (draft · approved · suspended), `GATE_DECISIONS`. Gate kinds: H1–H7 · Hd · HW-approve · HW-instance · HW-shared · HW-irreversible · HW-ddl · H5-SIM · H5-send · CG-11 · publish. H1–H3 and H6 reach the controlling Operator in the chat and surface here only when unanswered past their clock.
Workflow	W4 — a row opens the case at its gate (04); W5 — the Approver for the target class confirms a shape proposal at HW-approve (D133), any Approver's refusal resets the count; W6 — a held batch is released, refused or split, each with a packet. This list is the SLA-visible queue of human work.
Formerly	the “Gate inbox”.

07 · Plan gate — the agent proposes, a person approves, replies with another approach, or refuses

Is this a gate?	Yes — H3 confirmation at S4 of the plan H2 presented at S3. The plan is what the person approves; each write or send step asks again when it runs (H5 · HW-instance · H5-send) and the grant is issued then. The pattern is the plan mode of the coding CLIs.
Regions	header module › agent › case — Support › solution-take agent › case #1040 — proposes plan v2 · to whom (person · role) · controller · customer · clocks · the plan: numbered steps done / now / next, each with where-chips and the gate it needs · why this plan · the alternatives the agent rejected · your decision: approve the plan · approve and pre-approve a step (disabled with the reason where policy forbids — here PROD is customer-facing, this PROD shape has no accepted risk decision) · reply with a different approach (free text; the agent re-plans and returns with v3) · refuse with a reason · Details collapsed: evidence, statement, reversibility, blast radius, policy checks, shape 2 / 3, grant at step 2, history
Data	`GATES` (H2 · H3), the Plan paper, `GATE_DECISIONS`, `WRITE_SHAPES`, `GRANTS` (issued when a write step runs), the Semantic-contract paper the plan cites
Workflow	W4 — approve · reply · refuse; a reply re-opens planning, not the gate. W5 — each clean, person-confirmed write instance counts towards lifting the shape (D112); these effect gates remain human until their exact risk/target is accepted.
Formerly	the “decision packet” page of the first draft — the packet's fields are now the collapsed Details.

Build

08 · Studio — what the agents are made of

Regions	artefact tree by module › stage (prompts, skills, eval sets) with state chips · the selected artefact's versions (state, author role, eval result, since) with new draft · run eval · publish · rollback · where the artefact is used · the eval set with its failures and how examples are added
Data	`SKILLS`, `EVAL_SETS`, the prompt governance tables (Agent Framework § 6): versions draft · eval · published · retired; the publish gate; the rollback point
Workflow	W9 — the prompt's owner drafts with a reason and may try the draft on one case (`/try v13` in that case's chat); the eval set runs; the Prompt publisher role for the stage publishes — a role, not a review; new sessions get the version, running ones stay pinned. Eval failures are cases: open, fix the key or the prompt, re-run. Answer keys are written by people.
Formerly	the “Skills” screen.

09 · Studio version — the diff, the evidence, the publish decision

Regions	the diff (removed red, added green) with the author's reason · cases the draft was tried on · publish checks (green eval set · publisher role for the stage · rollback point · pinned sessions) · the buttons · the eval run per case: expected · old got · new got · verdict (fixed · pass · fail) · roll-out and rollback rules
Data	prompt governance tables (versions), eval runs, `GATE_DECISIONS` (publish)
Workflow	W9 — publish · return to author with notes · retire draft. Publishing is a gate and is written to the decisions with the eval run it relied on; rollback is itself a publish. Metrics compares versions on real cases.

10 · Knowledge — what the agents remember between cases

Regions	the memory tree of Agents Memory § 1 — `memory/AGENTS.md` the protocol; `platform/` intake · experience · handovers; `connectors/` one node per system; `configuration/` normalization · abacus · ipal · offer · serdica; `source/` serdica-backend › microservices · serdica-ui · intentgpt · db-plsql; `support/` methodologies · experience — with active-entry counts · the proposals queue naming the source case and the target node · confirm → active · return · retire · open case · the state ribbon case-local → proposed → active → retired · one experience entry in the § 6 shape (symptom signature · systems/env · mechanism · fix shape · links · reusable artefacts · taught by · read by · last used) · search by symptom or node
Data	the memory tree (Agents Memory § 1 — one `AGENTS.md` per node, one writing profile per node), its entries (§ 6), consolidation-pass proposals, `AUDIT_LEDGER` memory events
Workflow	W10 — promotion is a confirmation (D56): a curator's review here, or two independent cases that used the article without contradiction. Case-local memory never leaves its case unless proposed; the consolidation (“dreaming”) pass only proposes. The curator is an Operator with the duty for a branch, not a seventh role.
Formerly	the “Memory” screen.

Observe and control

11 · Metrics — hours and gates, never money

Regions	tiles (human minutes per case · first person on a new arrival · gate wait · gates per case · writes without a person · thin shapes) each with its target and basis · cases by state and module with clock breaches · gate throughput (count · median wait · share of cases) · targets and their basis
Data	ledger parsers (Metrics): `CASES`, `GATES`, `GATE_DECISIONS`, `SESSIONS` (human minutes), prompt versions per case
Workflow	W13 — read only; a target is a claim with a basis (D111); breaches link to the case; nothing is expressed in currency (D117).

12 · Control · Connectors — the ceiling a grant can never exceed

Regions	the Control tabs · one row per connector: environment, system, kind, allowed modes, customer-facing, health, credential, last probe, probe · edit · effects of the table · what is down right now · probe all · add connector
Data	`CONNECTOR_SCOPES` (env × system × mode ceiling), health probes, credential expiry, `environments.<env>.customer_facing`
Workflow	W11, W8 — a tool call outside the allowed modes is refused before it runs and shows as a refused card; customer-facing = yes makes H5 mandatory on sends and writes (D114); a connector marked down parks its cases as connector-down and they resume when the probe is green; editing a scope is an Administrator decision with a reason.
Formerly	the “Connectors” screen.

13 · Control · Roles & policies — who may do what; retention; gate training; budgets

Regions	roles → capabilities matrix (Viewer · Operator · Approver · Prompt publisher · Administrator · Customer representative) · retention policy per artefact class: keep · then · manual action · gate · gate policy — trainable by people: threshold, window, confirmer · budgets in minutes
Data	the role map (Trust and Data § 3); whitelabel policy keys `retention.` (D109), `gates.` (D112), `budgets.*` (D117) — proposed
Workflow	W11 — roles are assigned, no holders are named yet (D107, D110); every manual retention action lands in Decisions with a packet (HW-irreversible for purges and exports); irreversible and DDL shapes remain human without explicit risk acceptance; customer-facing environments add H5 on top; nothing on the page is expressed in currency.

14 · Control · Exceptions & kill switch — grants in force, parked cases, the switch, the audit tail

Control exceptions and kill switch wireframe

Regions	the kill switch with its state and consequence · grants in force: case, gate, env, system, target, mode, artefact hash, issued by, expires, revoke · exceptions: parked cases by class, capability gaps, orphaned sessions, with resume · extend budget · stop & hand over · the audit tail
Data	kill-switch state, `GRANTS`, `HELD_BATCHES`, `CASES` (park classes), `AUDIT_LEDGER` (append-only: who · what · where · why)
Workflow	W8, W11 — turning the switch on refuses every write, send, ddl and push at once and parks running cases; reads never stop; turning it off is a second decision. A grant is single-use per batch and bound to the packet hash; revoking is logged.

Client surface: client_wireframes.html. Specification: the UI page of this wiki (§ 0 principles · § 2 the case-chat vocabulary · § 4 the thirteen workflows · § 5 the screen inventory). Generator: gen_wireframes.py in this folder — python gen_wireframes.py . regenerates all eighteen SVGs.