AISA Next — decision register

The decision register of AISA Next — D8–D151, each with what was decided, why, and the pages it is applied in. D1–D7 were taken on 01.09.2026 and are recorded in the remediation plan § 2; this register continues at D8. The document began on 01.09.2026 as the split of the open C challenges in aisa-next/ by who could close them — that snapshot is the table below.

How the 73 challenge statements split — snapshot of 01.09.2026

The live split is the generated Challenges Register (scripts/wiki_challenges.ps1): on 03.09.2026 it holds 145 rows — A 30 · B 32 · C 55 · D 21 (build items) · R 7 (resolved, kept for the record). The table below is the state this register started from (D118).

A "class C" item is not neglect — closing it now would mean inventing the answer. Each names the event that will settle it.

1. Taken 01.09.2026 — the three that blocked the five stage authors

D8 — Whitelabel representation ✅ TAKEN

Decided: Markdown plus JSON with a published schema; HTML presentations generated later.

As applied (Stage Normalization § WS-2): product.json is the authored source of truth and the machine contract S2–S5 read; product.md is generated from it for H1 review; the HTML presentation is generated later from the same source. product.schema.json is versioned with the field catalogue and validated at the S1→S2 boundary.

Why one authored form — the consequence worth stating: two hand-edited representations of one product drift, and the drift shows up as a stage reading one thing while the human approved another. Generating the Markdown makes that impossible. A reviewer who wants a change makes it in the source and regenerates; the Markdown is never edited in place. If you would rather the Markdown be hand-authored and the JSON extracted from it, say so — that is a different design and needs a round-trip check to stay safe.

Validator: it recomputes the reconciliation counts rather than reading the reconciliation block, because a schema can only check that a number is present and a present-but-wrong number is worse than an absent one. H1 is blocked by: schema invalid · a recomputed count disagreeing with its claim · a repeating tariff with no layer_model · a field with no source.

Still open C: whether the renderer is a skill, a platform service, or the existing analysis-HTML toolchain — it does not affect the contract.

D9 — Contradicting sources ✅ TAKEN

Decided: ask the user. No precedence rule.

As applied (Stage Normalization, Stage Normalization § WS-7): every contradiction — informal against formal, or two formal documents against each other — is put to the user with both quotes and the consequence of each reading. No source class silently outranks another, and the proposed "newest explicit customer statement wins" rule is removed.

The cost, mitigated: this makes H1 heavier, which was the argument against it. Contradictions are therefore batched into one question set rather than asked one at a time, so the weight lands once per specification instead of per finding.

D10 — Publishing ✅ TAKEN

Decided: not mandatory peer review — a role that publishes prompts.

As applied (Agent Framework § 6.3, Trust and Data § 3): a fifth role, prompt publisher, joins viewer / operator / approver / administrator. Anyone may draft and test; making a version live requires the role. Two controls remain, and peer review is not one of them: the eval set (mechanical) and the role (a person accountable for what goes live).

Ownership and publishing are now separate acts: the owner is the only one who may change a prompt; the publisher is the one who makes a version live. Whether a stage author also holds the publisher role is a staffing choice, and the eval-set gate applies either way.

Refined 01.09.2026: the role is held per stage, not once across all five. This keeps the authors genuinely parallel — no single publisher becomes the queue every stage waits on — and it puts accountability next to the expertise, since judging whether a stage prompt is ready means knowing that stage.

2. Taken 01.09.2026 — platform and placement

D27 — the one-AI-runtime rule ✅ TAKEN, then softened by verification

Decided 01.09.2026: keep Ablera.Serdica.AI.Support[.*]; resolve the conflict by renaming the health service to Ablera.Serdica.AI.HealthDocuments.Manager. (This reverses D1; SRD_OPS → SRD_SUPPORT per D18.)

Then the impact analysis changed the picture. Three things, all verified directly:

1. Nothing is deployed. src/Serdica/Ablera.Serdica.AI has zero files on master, bulstrad-qa, bulstrad-staging and bulstrad-prod. It exists only on the unmerged health branch (344 files), with no Dockerfile and no CI deploy job.
2. The constraint is prose, not enforcement. The one code-level guard asserts a single deployable inside src/Serdica/Ablera.Serdica.AI/**/App/. A sibling module elsewhere in src/Serdica/ trips nothing — renamed or not.
3. "HealthDocuments" is probably the wrong name. The service also hosts AI.EMBED, AI.OCR_READ, AI.OCR_LAYOUT, AI.REFERENCE_INDEX_ACTIVATE, AI.REFERENCE_INDEX_BATCH and PROMPT.TEST_EXECUTE. Embedding, reference indexing and prompt testing are not health documents.

What this means: Ablera.Serdica.AI.Support was never blocked. I presented D-P2 as a gate to pass; it is a documentation conflict to settle, and the platform layout stands either way.

Revised recommendation: do not rename. Reword the 16 scope sentences instead — 1–2 hours against 1–2 days for the CLR rename and 1–2 weeks for the runtime identity strings — and only if and when the health-AI owner wants it. ⚠ If a rename is ever attempted, AI_MANAGER is frozen wire vocabulary: a schema enum at contracts/v1/schemas/serdica.workflow.evidence-delegation.v1.schema.json:42 inside a byte-hashed fixture. A blanket search-and-replace silently corrupts a canonical hash. The one argument for doing it now is that nothing is deployed, so it will never be cheaper.

C remaining: whether the health-AI owner wants the rewording, the rename, or neither. It no longer blocks anything here.

D12 — Budget enforcement ✅ TAKEN

Soft warning to the root agent at 80 %, hard refusal at 100 % — so an agent winds down and writes its papers instead of being cut off mid-apply.

D13 — Grants ✅ TAKEN

Decided: expire at case close or a fixed wall-clock, whichever comes first. And: the case's grants are part of the per-case prompt.

The second half is the better idea and is now in Trust and Data § 2: the agent is told what it may do rather than discovering it by being refused, so planning happens inside the boundary instead of against it. The connector check stays the enforcement — the prompt is how the agent knows, not how it is held.

D14 — What an agent boots with ✅ TAKEN

The agent starts from its own directory's AGENTS.md plus the task prompt — not the whole root→leaf chain — but is required to be aware of the rest of the knowledge and reads any node it judges relevant. memory_read is the whole tree and a profile may not narrow it. Boot is light; awareness is total.

D15 — Missing domain nodes ✅ TAKEN — auto-learn

When an agent needs a domain that does not exist, the platform launches a summarizer sub-agent that reads the subject and creates or updates the node before work continues. A missing node is never a prerequisite. Existing-but-stale nodes are updated, not replaced.

D16 — Case papers ✅ TAKEN — a dedicated file service

Not FileServer.V2 — verification confirmed it is write-once (409 on a keyed re-save), closed scope and tag vocabularies, no listing by owner, markdown rejected. Instead a dedicated token-gated file service owned by the module: few users, so no horizontal scaling; the design goals are security and simplicity. Every read and write carries a token scoped to the case and the role; papers are mutable with revision history; listing is by case; every access is audited.

D18 — Schema name ✅ TAKEN

SRD_SUPPORT, not SRD_OPS. Applied throughout.

3. Taken 01.09.2026 — process and simulation

D17 — Simulation ✅ TAKEN — and it is now the default

Everything is simulated before promotion except changes that are both very small and carry no blast radius. The venue is whatever fits — dev, staging, QA, a purpose-made new entity, or another form of simulation. Promotion is bound to confirmations and roles: simulation evidence is part of the promotion packet, not a note in a transcript.

This is a significant strengthening of what the wiki had, which treated simulation as an option for non-production and an exception in production.

The exemption test ✅ TAKEN — a change skips simulation only when all five hold: single row · single environment · reversible by an already-written teardown · no downstream consumer · no customer-visible effect. Failing any one means it is simulated. The test is applied and recorded in the plan, so an exemption is an auditable claim rather than a silent judgement.

D19 — Core-change propositions ✅ TAKEN

Routed to development. The proposition leaves the Source module and enters the estate's development process; the Source case records the handover and closes against it rather than waiting.

Erratum 07.09.2026 (D118). Superseded by D108 (04.09.2026): the proposition is addressed to a role — the estate development lead — as a GitLab issue on master carrying the brief, and the Development case closes against the issue id.

D20 — PL/SQL and git ✅ ANSWERED by research

Git stays, but only as a mirror the agent owns alone — the developer never touches it, which is what makes it workable. Applied in Stage Planning § 3b.

• Detection is a content hash, not LAST_DDL_TIME. The timestamp has a proven false-positive mode: one Toad compile invalid mass-action bumped ~30 SRD_INTEGR packages in six seconds on 15.05.2026. The signature is the release audit's existing Layer-5 block-hash recipe.
• Capture is append-only snapshots in SRD_SUPPORT, on signature change while a case is open, at case open, either side of every apply, and nightly. The counter-example is in the workspace: bst_health/db/plsql/ is a single never-refreshed snapshot whose files are readable but not re-appliable.
• Concurrency is refusal, not locking. The extract signature becomes a precondition of the write grant — if the developer saved in between, the apply is refused before a session opens, and the agent proposes a three-way merge that re-enters the gate. A lock the developer never takes guards nothing.
• Attribution is not solved, and the design says so. ALL_SOURCE has no author column, and unified_audit_trail gave a full identity for one actor and zero rows for another on the same schema the same day. Artefacts say "actor not recorded" rather than guessing. A unified-audit policy on CREATE/ALTER PACKAGE is worth raising with Ablera dev — IPAL's AUD$ is ~2 MB against INSIS's 6,213 MB, so it can afford it.
• Six standing prohibitions with guards, each backed by a recorded incident — including promoting a spec without its body (PROD POLQRY stood VALID with a stub raising ORA-06503 on every call) and changing a spec with cross-database dependents without the remote recompile (15.05.2026: every ABACUS-priced product failed 09:49–10:12 — 23 minutes — and the IPAL-side cleanup ran until 10:20; verified 03.09.2026).

C remaining: the polling cadence is uncalibrated — nobody has measured how often the developer saves, and that parameter drives the whole design. Needs one live measurement.

D28 — SALE_STAGE ✅ TAKEN — scoped to IPAL configuration

It is one type of pricing-factor configuration, and it belongs to S3 IPAL, not to a product-wide policy. S2's only interest is the invariant that a rating axis must exist as a POL row, because nothing else syncs. Which stages a factor carries is decided where pricing factors are configured, with the verified mechanics (no fallback in either direction; the four hardcoded force-included codes) recorded there.

The depth research is done and lives in Stage IPAL: all 25 + 15 + 17 columns, the ten configuration axes, dependency and value-source traced end to end, and a failure atlas of 28 misconfigurations ordered silent-first.

Three findings worth naming, because they correct sources the wiki was trusting: - The extraction dispatch key is VALUE_SOURCE, not POLICY_TABLE — the PC extract has this wrong, and predicts correctly only because both usually say POV. - QT_REQUIRED is the rating-set gate, not an asterisk. 'N' drops a factor from the premium call and the completeness check, and on a quotation the engine zeroes the affected groups — so the quote comes out silently cheaper than the policy. - UI_REQUIRED does not exist on the deployed model (emitting it raises ORA-00904), STATUS has no filter anywhere, and PRICING_TYPE has no behavioural consumer at all.

Erratum 04.09.2026 (D118). Both statements about UI_REQUIRED in this register were right for one environment each: the column is absent on PROD (PR_PRICING_FACTORS has 25 columns; bulstrad-prod/bulstrad-staging code does not map it — ORA-00904 there) and present, NOT NULL, on TEST/STAGING, QA and DEV (26 columns; mapped on master/bulstrad-qa). STATUS is populated only on the values table (M/MO/O/U, plus A on QA/DEV); on the factors table it is NULL everywhere except two DEV rows. Verified 03.09.2026 on all four environments; § 8 below described the DEV database.

Also established: only one foreign key exists across the three tables — every other cross-reference is a free string the database will not check, which is why nearly every misconfiguration fails silently.

4. Operational policy — before the first real cases

D21 — v1 and v2 memory ✅ TAKEN

Decided: the two are used independently; v2 supersedes v1 over time; one-time migration.

As applied (Agents Memory § 7.1, Delivery § 3): no shared tree, no snapshot reads, no synchronisation. v1 keeps its memory/, v2 has its own, neither writes into the other. This is stronger than my recommendation of a shared tree with one writer per domain, and it removes the failure mode outright rather than policing it — two systems writing one domain would produce contradictions neither notices.

One-time does not mean one push: the crossing is executed in waves so each domain is measured (§ 2 acceptance test) before the next starts. What is one-time is that a domain crosses once, and afterwards v1's copy is not consulted for it.

D22 — Auto-classification ✅ TAKEN

Decided: always auto-classify; recommendation accepted.

As applied (Stage Classification § 2): no confidence threshold below which the platform declines. It classifies, shows the evidence, the operator corrects in one action, and the correction rate is the metric.

D23 — Precipitation ✅ TAKEN — and it became a ladder

Decided: threshold 3, not 2 — plus refinement passes at the 7th and 20th occurrence.

As applied (Stage Precipitation § 2):

This is a better design than the threshold I proposed, and worth saying why: a created skill is not a finished skill. The v1 corpus is full of entries written once and never revisited, which is a large part of why it does not fire. Scheduling refinement at a known occurrence count means it happens because the thing is used, not because someone remembered it.

D24 — Cross-kind ordering ✅ TAKEN

Decided: first occurrence → apply the one-time correction unless the operator suggests otherwise. If it repeats → also propose the configuration and/or development path, on the same counter as D23.

As applied (Stage Solution Take § 1): the instance is always corrected; what changes with recurrence is that the platform additionally proposes the structural path at H2. It is a recommendation, never an automatic escalation — which keeps the customer-facing fix fast while making the pattern visible.

This also resolves the risk I raised against instance-first: the gap is not merely tracked in a queue that can go quiet, it is re-proposed on every recurrence.

D25 — Who writes the experience entry ✅ TAKEN — my recommendation rejected

Decided: the experiencing agent writes it. Curation moves to the dreaming protocol.

As applied (Stage Precipitation § 1 and § 6): the agent that worked the case writes the entry while it still holds the context; the scheduled dreaming pass is where curation happens — re-reading entries against a would this help a stranger test and rewriting the ones that only make sense to someone who was there.

I had recommended the curator on the grounds that the closer knows too much. This is better: it keeps the entry cheap to produce (no context hand-off, no second agent reading papers) and puts the fix where it belongs — in a pass that sees many entries at once and can spot the pattern of unreadability, rather than in a per-case cost paid every time.

D11 — Investigator domain boundaries ✅ TAKEN

Decided: symptom-shaped — transfers and sync, pricing, printing, access, health, master data.

A customer reports a symptom and never a system; shaping the agents the other way would make every case start with a routing argument. System knowledge is not duplicated across investigators — it lives in the connectors/* and configuration/* domains, which every investigator reads and none owns.

C remaining: most real cases span systems, so which investigator leads a cross-system symptom still needs a rule. It is set from the first ten cases rather than from a table drawn now.

D26 — Health products (8000) in Configuration ✅ CLOSED — no exclusion

Closed 01.09.2026. The premise was wrong.

What I had claimed: exclude 8000 until the no-personal-data rule (CG-9) is shown to hold for its configuration material, on the grounds that provider catalogues and АО report structures might embed identifiable data.

Why that was wrong: it conflates the data a product processes at runtime with the material used to configure it. Configuring a product means reading tariff tables, package and cover structure, general terms, settlement rules and print templates. The workspace's own 8000 corpus separates the two cleanly — product_8000.md (packages, covers, ОУ, package×cover matrix), pricing_and_tariffs.md (2026 tariff bands by group size), the schema models and the templates carry no personal data; enrolment/census, claims and АО reports do, and those are runtime data belonging to Support under SG-9.

Resolution: no product family is excluded on data-protection grounds, 8000 included. CG-9 is restated as what it actually is — a description of what configuration material is, not a restriction hopefully imposed on it — and its anomaly rule (an ЕГН in intake stops the stage) remains the safeguard against a genuine mistake, such as a real census file pasted into a specification thread. The exclusion was redundant on top of a rule that already covered the case.

Erratum 04.09.2026 (D118). The stop-the-stage anomaly rule was replaced on 02.09.2026 by D57: stray identifiers in configuration intake are handle-substituted at the connector before storage; only material that is personal data (a real census) is rejected as wrong input.

5. Class C — deferred by design (40)

Each names the event that settles it; none is closable today.

6. What still needs you

Nothing is blocked. D18-a, D20-a, D27-a and D28-b were all closed on 01.09.2026 — see § 8.

The only open items are the ones deliberately deferred to a first case or a first measurement (class C, § 5), plus one that fell out of the live-data pass; the live list of open items is Open Decisions:

7. D18-a — what dedicated credentials do and do not solve

Dedicated credentials for SRD_SUPPORT are the right call, and they settle access isolation: the platform authenticates as itself, its grants are its own, and nothing else in the estate can write its tables. That is a different problem from backup and restore. Five issues remain:

1. Being a schema with its own user does not put it in a backup set. Someone has to add it to the RMAN or export scope. The classic failure is exactly this — a schema stood up outside the DBA's provisioning path, never attached to a backup job, and nobody finds out until a restore is needed. Dedicated credentials can make it more likely, because the platform can stand everything up without ever entering that path.
2. Restore granularity. Oracle backup is whole-database. Restoring only SRD_SUPPORT to a point in time means a clone or a logical export/import — so that procedure has to exist and be tested, not assumed.
3. Which database it lives on decides the coupling. On the IPAL production database it inherits a good schedule, but its restore is coupled to production IPAL — the platform cannot be rolled back without touching the PAS. On its own database it is independent and needs its own job.
4. The ledger is append-only and it is the audit record. A restore that rolls SRD_SUPPORT back silently discards audit entries for work that really happened. Whatever the RPO is, that number is also the audit gap.
5. Cross-schema consistency. Case papers reference objects in other schemas at points in time. Restoring SRD_SUPPORT alone leaves papers pointing at a state that no longer matches — recoverable, but the procedure has to say what happens to cases that were open.

Recommendation: the estate's DBA process owns it. The one thing worth confirming explicitly rather than assuming is that SRD_SUPPORT is in the backup inventory, and the one number worth stating is the ledger's RPO — because that is also how much audit history a restore can lose.

8. Closed 01.09.2026 by running the queries

D28-b — done. SQLcl was never the blocker: the workspace ships its own client at tools/sqlcl/, and it connects to db.serdica.ablera.dev:1521:orcl1 (SID form; the service-name form is not registered). I should have used it several turns earlier instead of reporting the MCP server as a wall.

What the data settled, and it corrected the research rather than confirming it:

D18-a — decided. SRD_SUPPORT lives on db.serdica.ablera.dev, alongside SRD_INTEGR. Credentials for provisioning exist. No schema was created — there is no DDL to put in it yet, and standing up an empty schema now would be a change with no purpose.

D20-a — decided, and it costs something. SRD_SUPPORT shares a database with SRD_INTEGR, so the PL/SQL snapshot store shares a failure domain with the packages it protects. That is exactly why the design mirrors snapshots into a git repository the agent owns: the mirror is the copy that survives losing that database. Recorded in Stage Planning § 3b.

D27-a — closed. The health-AI program owner is Vladimir Moushkov, so there is nobody else to raise it with. The 16 scope sentences are yours to reword or leave; nothing depends on it.

The PL/SQL cadence — now measured on the QA environment the developer uses (db.serdicaqa.bulstrad.bg): active on 13 of 90 days, 1–7 objects on a normal day, tightest cluster 7 objects in 15 seconds, and the one 105-object day spread over 5.4 hours rather than being a mass recompile. The developer is sparse, not continuous, so the polling frequency matters less than the capture gates — at case open and immediately before every apply. Recorded in Stage Planning § 3b. Staging, described as the most-changed environment, was deliberately not queried.

What the Ablera dev database could not answer: the same question. SRD_INTEGR on this host saw package DDL on exactly one day in 90 (21.07.2026, 3 objects) — the developer does not work here. Calibrating the polling interval needs the environment they actually use. Also of note on this host: 106 package specs against 19 bodies, which on a customer environment would be the spec-without-body hazard the sync design guards against, and on a dev box may simply be normal.

9. Taken 02.09.2026 — the review before the presentation phase

Vladimir's answers to the full-wiki review of 02.09.2026 (see memory/project/aisa_next_review_2026_09_02.md). Each is applied in aisa-next/.

Arithmetic corrected: 219→509 analyses between 02.07 and 31.08.2026 is ~7 per working day (~5 per calendar day).

10. Open on 02.09.2026 — see aisa-next/90 Reference/Open Decisions.md

Eight decisions (A-1…A-8), four requests to send (B-1…B-4), the P proposals applied on 02.09.2026 to confirm or overturn (section C), and three numbers only Vladimir can supply (D-1…D-3). A taken decision moves from that page into this register as D39 onward.

11. Taken 02.09.2026 (evening) — Vladimir's answers to Open Decisions A/B

| D50 | Whole profiles, no runtime inheritance; a module default is an authoring template copied into a self-contained draft; revisit past 40 published profiles or a change touching more than 10. | Agents § 0 Challenges |

A-6 answered from the data: Georgi Stoyanov leads 33 of 35 tagged shapes (Skills Catalogue § 2b). B-3 acknowledged.

| D51 | Whitelabel. Section C of Open Decisions confirmed; every contract-, customer- and estate-specific value (SLA times, calendar, severities, identifier patterns, channels, hosts, thresholds, schedules, role mappings) is configuration with a default in SRD_SUPPORT policy rows or the customer plug-in — never a constant, never an architecture rule. | Architecture CR-10, Platform PG-23, Whitelabel Catalogue (new), markers on Platform Details, Support, Stage Classification, Stage Investigation, Stage Precipitation, Stage Application, Agents § 0, Agent Runtime, Trust and Data, Agent Runtime § 11, Delivery, Glossary |

| D52 | Hours only. Human effort is measured in hours and never monetised; no hourly rate appears in the wiki; the model bill is the one currency line. Superseded 03.09.2026 by D79 and restated 04.09.2026 by D117: no currency figure anywhere, the provider bill included. | Value and ROI § 1, § 5, § 6; Agent Skills § 2 | | D53 | Switch cost = 20 % of the ticket's handling time (configuration default); the larger cost is the fogginess after the switch — risk of bugs and slower/worse execution on non-support work — tracked as a count of defects and reworks after interruptions. | Value and ROI § 1, Whitelabel Catalogue § 5 | | D54 | Archive figures adjusted: agent time −25 %, person's true time +25 %, each figure carrying the note that a colleague's experience puts the agent lower and the person higher; times vary by domain and by person; replaced by the ten-ticket stopwatch measurement. | Value and ROI § 2b, § 6; Agent Skills calibration; Whitelabel Catalogue § 5 |

| D55 | The proposals applied on 02.09.2026 are confirmed as written on their pages (goals PG-9…22, CG-10…13, SG-10…14, DG-7…9, N-9…11; the Configuration, Support and Source rules from the case studies; the platform rules from the evidence rounds). Values among them are configuration defaults under D51, not decisions. Resolved challenges leave the register; only items still needing information remain. | Open Decisions § C, Challenges Register |

12. Taken 02.09.2026 (night) — the review follow-up

Vladimir's directives on the 17-point review of the goals/architecture. Each is applied in aisa-next/.

13. Taken 03.09.2026 — write gating, the write auditor, the configuration write path and the phase order

Vladimir's directives after reading the three product-configurator documents. Each is applied in aisa-next/.

Still open after these four (Product Configurator § C): C-2 (whether a projection, not the agent, authors every statement — D74 narrows it to the statement fallback path), C-4 (the request map for products never priced from the incumbent side), C-5 (rate 0 versus an open version for an unpriced cover), C-6 (working versus target environment wording), C-7 (the three provenance classes in the schema), C-8 (whether the rating engine becomes the product and the policy administration system the option), C-9 (commercial residency for tariff documents). C-1 and C-3 are settled — C-1 by D72, C-3 by D74 and D75 making the tariff phase the first writer.

14. Taken 03.09.2026 (evening) — the target state, and what the platform is for

15. Taken 03.09.2026 (night) — the unit of value, and the shape of the build

16. Taken 03.09.2026 (late) — the non-goals page, and the order of the build

17. Taken 03.09.2026 (late) — the two module flows, made to agree

18. Taken 03.09.2026 (night) — the incumbent side, the process, and one page per stage

19. Taken 03.09.2026 (late night) — the section home, the gate architecture, the second surface

20. Taken 03.09.2026 (late night) — how the modules reach each other, and where the agent pages live

21. Taken 03.09.2026 (late night) — the client as initiator, and the pictures

22. Taken 04.09.2026 — the consistency review of the presentation set

Vladimir's answers to the 03.09.2026 review of the product page and the 51 technical pages (87 findings; four verification agents ran read-only against PROD/TEST/QA/DEV IPAL, PROD INSIS, both submodules, the ticket archive and the contract — reports in the review folder). Each is applied in aisa-next/, the register and the product page.

| D119 | The chat is the workspace — the UI is redesigned around one case thread, role front doors and a brief before every case. The operator surface is eight workspaces behind role-dependent front doors, not seven screens: Inbox (every arrival re-briefed from its source by platform.intake — source chip with the external id, what was said, identifiers resolved to where-chips, duplicate verdict, proposed classification with the two clocks, precedents; one operator action opens, corrects & routes, merges or dismisses = H1, SG-11), Cases (one list, role-filtered; former Sessions) with the case chat (former Session view: one thread of eleven card kinds — brief · agent · tool · question · plan · decision · verdict · write · handover/consult · status · human — a stage ladder with the gate each stage carries, a status line in minutes, a composer with slash commands whose second line states the typist's permission, and a Where rail), Decisions (former Gate inbox: every waiting gate with its packet, held batches, shape training, history), Studio (former Skills: prompts, skills and eval sets — draft → try on one case → eval → publish by the prompt-publisher role → rollback), Knowledge (former Memory: tree, proposals queue, articles with taught-by; promotion is the D56 confirmation), Metrics, and Control (former Connectors, plus Roles & policies — the roles → capabilities matrix, retention per artefact class with gated manual actions (D109), the trainable gate policy (D112), budgets in minutes (D117) — and Exceptions & kill switch — grants in force, parked cases by class, the switch, the audit tail). Every card says where: a locator chip ENV · SYSTEM · OBJECT plus mode (read · write · ddl · send) on every tool call, write, decision and brief; the Where rail is derived from the cards, never typed; objects are handles. Thirteen workflows are defined (intake and brief · follow · steer/answer/stop · decide a gate · train a shape · apply/verify/reply · hand over/consult/sub-case · park/recover/kill · author and publish · curate knowledge · administer · the customer's journey · observe) and every human action in them is a verdict or human card in a thread or a row of AUDIT_LEDGER. The client surface keeps its four screens and its five absences (D91), in customer words, without where-chips, estate or kill switch. The eighteen wireframes are generated from one script (ui/gen_wireframes.py) with one shell, palette and vocabulary; the sample case is generic (a premium that differs between the two systems, a vehicle model missing in pricing, a transfer failing for an annex) and is not what the screens are built around. The curator is an Operator duty per branch of the tree, not a seventh role; Control's policy tables are proposed whitelabel keys (retention.*, gates.*, budgets.*) until the T1 skeleton fixes their storage. Supersedes D91's "seven administration screens" and PG-5's "session list and live view" wording. Refined the same afternoon: the decision card and screen 07 follow the plan mode of the coding CLIs — header module › agent › case · to whom, the plan as steps with the gate each needs, the alternatives rejected, and four options (approve · approve and pre-approve a step where policy permits, shown disabled with the reason where it does not · reply with a different approach, on which the agent re-plans · refuse); the packet's fields become collapsed Details. Decisions names the proposing agent and the person it waits on. Knowledge renders the AGENTS.md tree of Agents Memory § 1 and the § 6 experience-entry shape. One request and Acceptance offer Open the case view (the operator thread, read-only) when the representative's role set includes Viewer — a door behind the role check, not a client screen. Sample people are named as illustrations, not role assignments. | UI (rewritten: § 0 principles, § 1 workspaces, § 2 chat vocabulary, § 3 intake, § 4 workflows, § 5 inventory, § 6 gallery, § 7 rules); ui/admin_wireframes.html; ui/client_wireframes.html; ui/wf-*.svg (18) + ui/gen_wireframes.py; Platform PG-5 + Details; Architecture § 2 and the UI row; Software Architecture; Delivery track 3 and P-11; Agents § 5c; Agent Runtime § 11; Agents Memory § 2; Whitelabel Catalogue intake.*; Glossary; Value and ROI; product page UI tile, panel and links; D91 erratum |

24. Taken 04.09.2026 — the Open Decisions page answered (A-1…A-7, B-1…B-5)

Vladimir's answers to Open Decisions § A and § B, given 04.09.2026 with the second wireframe round. A-8 (the tunnel via host) stays open. Each row names the page it is applied to; the Product Configurator § C rows C-2, C-4–C-9 point here.

25. Taken 04.09.2026 (afternoon) — the developer-readiness answers (A-8…A-10 and the contradictions)

Vladimir's answers to the developer-readiness assessment of the same day (memory): A-8, A-9 and A-10 decided, the budget dimension fixed, and the six contradictions the assessment found closed after reading the estate's source (serdica-backend master/bulstrad-qa), the IPAL schema and the memory. The artefacts the assessment called missing now exist: the SRD_SUPPORT DDL and the contract set (Data Model, Contracts).

PLSQL-SIG-1 — the content-signature recipe the branch set and PLSQL_SNAPSHOTS.SIGNATURE rely on — is defined in Stage Planning § 3c as a definition, not a decision: strip CR and trailing whitespace per line, keep everything else, join with LF, SHA-256; SOURCE_HASH beside it hashes the raw text so whitespace-only drift stays visible.

26. Taken 04.09.2026 (evening) — the root Support module, and where the trees live

Vladimir's directives on the presentation set of 04.09.2026: the head page's picture, the module structure, and the layering of the agent pages against the module pages.

27. Taken 04.09.2026 (night) — the route, the diagram states, the desk's goal

The head page's reworked spine (D143–D146) stated three things the wiki carried only implicitly: where the desk's route is decided and what waiting is, how a stage diagram tells a gate from a signed result and from a step the workflow does not wait for, and what the desk itself promises. Recorded here; applied on the pages named.

28. Taken 05.09.2026 — one Goals page

Vladimir's directive on the goals chapter: the split into a Platform, a Support, a Configuration and a Development goals page scattered the reader's attention, and the sample diagrams on those pages said nothing the architecture does not say better.

23. Appendix — page names used in "Applied in" cells before D88/D94/D96 → current page

Kept last, as an appendix: it is a lookup table for reading the "Applied in" cells above, not a decision.

29. Developer implementation and owner presentation — 07.09.2026

These implementation clarifications follow the owner's instruction to apply necessary review corrections, deepen the technical specification and keep the presentation focused on the operating philosophy. They do not record organisational acceptance of any live write risk. Existing customer/estate permissions are unchanged.

30. Case-driven architecture hardening — 07.09.2026

The owner requested all uncommitted typical cases be traced through wireframes, endpoint requests, saved data, agent initialization/prompts/knowledge, messages, gates, execution, reversal and subsequent learning. These are design clarifications, not live grants or proof of implementation.