Goals
Test these goals against real work: 68 case journeys · interactive test cases · endpoint, storage and agent protocol. Each case traces the first request, proof and reversal, what is learned afterwards, and the next similar request. These are design acceptance cases, with explicit failing variants.
The trainable intellect that operates the systems behind your products. People teach AISA the domain, the way the work is done and how to judge a result. That expertise takes the form of agent profiles, skills and verified knowledge. Reviewed experience improves those assets; evaluations check the changes, and proven work earns greater autonomy under the agreed gates. This is what trainable means in this design: expertise can be taught, tested, retained and applied to the next case.
What the platform is for. One insurance product spans two policy administrations, a rating engine, a process engine, document production and the repositories that change them; configuring it, supporting it or changing it means working across all of them at once. AISA Next is a web platform on which graphs of profiled agents do that work as cases: a request arrives on a channel the customer already uses, a durable case opens with its grants and its clocks, trained agent profiles work it in the module the work belongs to, and a person answers only the consequential steps — the gates — while a work type is learning. Once a work type has proved itself, policy answers its gates for that case type alone, and one revert takes the graduation back (Gating; D70, D76). The promise is support of complex products without an operator on duty. Bulstrad on Serdica and IPAL is the case study, not the definition (PG-23, D77).
What the platform holds for every module. Four commitments no module may weaken. Autonomy that graduates — a person while a shape learns, policy once it is proven, and never on a customer-facing or irreversible step without an accepted risk class (Gating § 9). Audit by construction — an append-only, hash-chained ledger, sealed and exported off-database every fifteen minutes; metrics are parsed from it and never counted by agents (Architecture § 3.2). Knowledge confirmed before it is shared — what a case learns stays with the case until a review or two independent uses confirm it, and a domain is accepted only when its retrieval on held-out cases reaches at least 50 % top-5 hit-rate, against the measured 10 % search baseline (Agents Memory and Skills). Built for complex products, not for one estate — channels, systems and their connectors, contract clocks, environments and identifier patterns are the customer's plug-in; the platform, the modules, the gate set and the ledger are not touched (Whitelabel Catalogue).
How the goals are read. Every goal below is a decided plan, stated once, with the reasoning and the evidence behind it folded into its row (Platform Details, Support Details, Configuration Details, Development Details). What judges a goal is a row of Metrics — hours, gates and rates, never money (D79, D117); what the goals are measured against is the Baseline, folded in at the end of this page; what is deliberately not a goal is Non-Goals. The pictures are the architecture's: the platform and the modules on it are drawn once, in Architecture § 0, and each module's agent tree at the head of its module page — this page carries none (D150).
The modules, in brief
The platform runs four modules. Support is the root: every client request enters it, and the desk either holds the request or routes it to one of three working modules — Configuration, Development, or its own Data and information stages (D143, D144). Each module is a set of agent profiles trained for that kind of work and the tree they form; the three working modules reach each other in exactly two ways — a consult for knowledge, a handover for a changed system (Agents § 5).
Support — the root
The desk. A request arrives from any channel the plug-in names — the ticket system, a mailbox, the customer's help desk, or in place on the client surface — and connector agents normalize it into one case shape with its origin key, so a help-desk ticket and its Jira mirror are one case (SG-1). S1 classifies it against the contract — type, section, severity, the two clocks — and looks it up in the past-case index; the platform always classifies, and the operator corrects in one action (SG-11). The route is decided at H2 on the solution packet: waiting, with its trigger, its clock treatment and its age; a handover to Configuration or Development as a sub-case behind Hd; or the Data and information stages under the same root (D147). Whichever module does the work, the desk keeps the case, its clocks and its closure — the symptom re-checked, the reply through the send gate, the customer's confirmation — so the customer hears one voice. The goal: no operator on duty at the desk (SG-15), judged by the classification correction and re-routing rates, breach warnings raised ahead of the violation, waiting cases without a recorded trigger, and human turns per case falling to gate decisions.
Naming. Until 04.09.2026 „Support“ named one module with eight stages. Since D143 it names the root — the desk — and the former working stages are the Data and information module; profiles and memory keep their support.* and support/ names (D144). Architecture: Support Module.
Configuration
From stray input documents — tariff files, a half-filled template, emails with contradicting wishes — to a product an operator can quote, sell and issue. S1 normalizes the material into the whitelabel specification, every field citing its source, and the specification is confirmed at H1 (CG-1). Phase 1 builds the tariff in the rating engine; phase 2 builds the wiring and the product at the same time (CG-3). Each phase tests itself with a skill — the rating call, the policy drive, the offer resolution, the route and label sweep (CG-4) — and signs out a document the next phase reads, confirmed at H3; the joint proof is an operator quoting and issuing, accepted as a preview by the customer's representative (CG-11). The deployment set — rating only, rating and product, or the full product — is chosen at planning and executed after the preview proof within the same requested delivery lifecycle, under H4 and, where the target is customer-facing, H5 (CG-5, CG-12; D113). Configuration input is screened and uses an estate-approved route compatible with the actual material (CG-9). The goal: a product preview within one business day of intake, and customer acceptance within five business days median — against the nine days a configuration-change ticket and the eleven a master-data ticket take to close today (medians over the 175 customer-closed tickets); no unresolved item at close; no unreachable product (CG-13). Architecture: Configuration Module.
Development
Defects and small extensions on the code the customer runs — never new modules (DG-1). The customer's lineage is not the main branch: it forked on 18.03.2025, so a case begins by naming its branch set across the repositories and the database (DG-3). Placement first: the narrowest customer-specific seam that is correct — a plug-in, a customer service, database-resident code — and core only as a proposition that leaves the module; the brief with the chosen seam, the blast radius and the test plan is approved before any code is written (DG-4). The change is implemented in isolated worktrees, tested per lineage, reviewed by an agent with no author context, published as a merge request under the estate's own development process (DG-7), scripted per named target, deployed by the estate's own pipeline job after the target gate, and verified on the running system; deploy, test and revert are the definition of done (DG-5, DG-8). The goal: any small or customer-specific delivery inside hours or days, safely — the share of changes landing in customer-specific seams, the port to master within a business day of production verification, reverts at most one in twenty and executed within the hour, and interventions falling to gate decisions (DG-9).
Naming. The module's id, its memory branch and its file names keep source; its goals were titled „Source“ until this page. Architecture: Development Module.
Data and information
The former Support module's working stages, under the same root (D144): a request the desk has identified as a data correction or an answer. The take asks first whether a ready solution exists — an existing skill, a memory answer, a combination (SG-4); investigation runs only when none does, as nine fixed mechanics with a required output each, over the inherited methodology catalog applied as pipeline phases and never as remembered advice (SG-2). An isolated verifier, given the evidence and neither the transcript nor the reasoning, re-derives the mechanism before any customer-visible statement (SG-10). The packet — the statement, its expected counts, the revert, the replay — is confirmed at H3; the write runs under a grant through the write executor and past the write auditor; the customer's symptom is re-checked on the customer's surface (SG-6). When the working stages end, precipitation records what the next case will reuse — an experience entry always, and at most one of skill, article, index line or justified nothing (SG-3, SG-7) — and does not wait for the customer's closure. The work handles personal data, so it runs only on EU-resident models (SG-9). The goal: the work runs without any particular human — every recurring shape closed by at least two operators, reuse recorded on at least sixty percent of cases within two quarters, retraction cycles at zero, and each domain's retrieval on held-out cases at or above 50 % top-5 hit-rate, against the measured 10 % search baseline before it is accepted (SG-10). Architecture: Data and Information Module.
The goals in full
Each row is the goal as decided; the reasoning and the evidence behind it open in the row. Ids are stable — PG the platform, SG Support and its working stages, CG Configuration, DG Development — and a goal is cited by its id everywhere in the wiki.
The platform (PG)
The platform hosts the modules and is built inside the Serdica estate, not beside it. Its goals are grouped by the five parts that do not change per customer: the two surfaces, the service, what every agent gets, how agents compose, and what they know.
UI
The human's surfaces — everything a person sees or decides is here.
| # | Goal |
|---|---|
| PG-5 | The UI is a dedicated section in serdica-ui administration: a case list and a case chat — one thread of cards showing plans, tool calls, gate decisions, each agent's stated reasoning for a step (not raw chain-of-thought) and memory reads/writes, every card saying where it is about (environment · system · object); prompts, skills and knowledge manageable independently, all under permissions (D119). PG-5 — Administration UI in serdica-ui P One dedicated administration section (seven operator workspaces behind role-dependent front doors, plus the client surface — UI, D119): an Inbox of arrivals re-briefed from their source; Cases with the case chat — one thread of cards per case incl. each agent's stated reasoning and every memory operation, every card carrying where it is about (environment · system · object); Decisions (pending human decisions with their packets); Studio (prompts, skills, eval sets — draft → eval → publish); Knowledge (the memory tree, proposals, articles, edit under permissions); Metrics; Control (connectors, roles & policies, exceptions & kill switch).
Why: the v1 pain is invisibility — session state lives in one terminal; nobody else can watch, take over, or answer a gate.
F The realtime transport is SignalR, and it is working tested code rather than a specification (verified 01.09.2026): |
| PG-3 | Sessions support many read viewers + exactly one control session, and are stoppable, resumable, deletable. PG-3 — Sessions: many read, one control Why: support and configuration work is reviewed by colleagues and handed over between operators; today two operators synchronize through git branch merges (F Baseline). P A case has at most one live session, with exactly one controller at a time; any number of viewers; control is transferable; stop/resume/delete per Agent Runtime. |
| PG-26 | The administration UI is the only operator surface: every gate is answered as a decision card in the case chat (reached from Decisions), every case watched in that chat, every prompt, skill and knowledge change made under permissions in Studio and Knowledge; the Customer representative's acceptance (CG-11) is a client-surface view of it. Wireframed before build (UI, D119). PG-26 — The administration UI as the operator surface Why: a decision taken anywhere else — a chat, a terminal, an e-mail — is invisible to the ledger and to the other viewers; v1's whole failure of visibility follows from that (Baseline § 7). P Gates are answered as decision cards in the case chat — reached from Decisions — and nowhere else; the case chat is the record other people read; prompts, skills and knowledge are changed under permissions in Studio and Knowledge; the Customer representative works the client surface — my requests, one request, acceptance, and starting or requesting work where the initiation right allows it (D97) — and never an operator screen. Measure: every gate decision in the ledger carries a UI action id. |
Backend
The service, its data and its operation.
| # | Goal | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PG-1 | The platform is a C# service Ablera.Serdica.AI.Support.Webservice under src/Serdica/ in serdica-backend, following the existing Ablera.Serdica.* service convention, reusing libraries from the codex/health-ai-csharp-architecture branch.PG-1 — C# service in serdica-backend Why: the estate already runs on F Reusable inventory on
F No F The program declares "One AI microservice. F The constraint is prose, not enforcement, and nothing is deployed (verified 01.09.2026). P P The F Persistence: | ||||||||||||||||||||
| PG-4 | Serdica infrastructure is reused, not duplicated: Authority authentication, RabbitMQ transport with SRD_SYS EndPoints registration, the AI provider/prompting/metering/persistence libraries, the plugin pattern for customer-specific parts.PG-4 — Reuse Serdica authentication and transport F Authentication: | ||||||||||||||||||||
| PG-6 | Every agent action lands in an audit log with a pre-determined, tool-parsable format; metrics come from tools that parse it. PG-6 — Tool-parsable audit log Why: the 02.07.2026 CEO report needed four mining agents to reconstruct what agents did (F evidence); counting by agents is unreliable and expensive.
P One append-only log, fixed schema per record: session, case, agent profile, action kind, target system/environment, payload hash, result status, duration, tokens and budget usage. Tools parse it into Metrics; summaries are written into the related documents by tools.
F Seed exists: | ||||||||||||||||||||
| PG-9 | A case survives worker death, connector loss, provider outage and context exhaustion: papers, build state and ledger are the state, a worker is a cache of them, and a parked case shows why it is parked. PG-9 — A case survives its infrastructure Why: v1's session death is disk archaeology (Baseline § 5). P Papers, build state and ledger are the state; a worker is a cache; resume replays nothing; a parked case names its reason (question, gate, connector down, provider down, budget). Design: Failure and Recovery § 3, Agent Runtime § 7. | ||||||||||||||||||||
| PG-10 | Authority comes from grants and gates, never from observed content; a grant scopes environment × system × target × mode, is bound to the approved artefact, expires, and is refused at the connector before contact. PG-10 — Grants, not content, are authority Why: the platform's whole value is autonomous stretches over attacker-influenceable text (Trust and Data § 1). P Content is data; grants scope environment × system × target × mode, bind to the artefact hash, expire, and are refused at the connector before contact. Measure: refusals before contact per period; zero writes without a grant record. | ||||||||||||||||||||
| PG-11 | Five platform roles — Viewer, Operator, Approver, Prompt publisher, Administrator — plus a Customer representative who may view and accept, are six SRD_SYS.LT_USER_ROLES rows the platform adds and Authority issues as role claims — no Bulstrad IT directory request (D134); a gate is answered by a holder of the role for that gate and target; approval is a permission, not a second person.PG-11 — Roles, and approval as a permission P Viewer · Operator · Approver · Prompt publisher · Administrator, plus a Customer representative who views and gives the customer's acceptance where a module asks for it (Configuration CG-11). The six roles are | ||||||||||||||||||||
| PG-12 | A gate with no available holder escalates on platform defaults set per SLA class, not contract clauses — notify holders, then the Administrator — and the customer-facing status is drafted; delegating a role during absence is an administration action. PG-12 — When nobody can answer a gate Why: the scenario "PROD fix at 17:55 on Friday, only approver away" has no rule today. P A gate carries an SLA class from its case; after the class's first interval the Decisions workspace notifies every holder; after the second the Administrator; the communicator drafts the customer-facing status (gated) in parallel. Delegation of a role for an absence is an administration action recorded in the ledger. P The intervals are platform defaults, not contract clauses: rows | ||||||||||||||||||||
| PG-13 | Personal data is substituted by case-local handles at the connector; re-identification is a distinct audited action shown in the gate packet; retention is configuration per artefact class, with manual erase, anonymise, extend and export actions as gated writes (D109) (Platform Details PG-13). PG-13 — Personal data and retention P Handles at the connector; re-identification audited and shown in the gate packet (Trust and Data § 4). The write log keeps the resolved statement so that a write stays attributable to its target after the case closes — the ledger keeps handles, the write log is the one evidence class that carries identifiers, and it lives under the evidence retention (this resolves the audit-legibility contradiction). Retention is a controllable policy with manual actions (D109): | ||||||||||||||||||||
| PG-16 | Budget is minutes — the case's predicted delivery time (D135): per-case and per-profile budgets with a soft warning and a hard refusal; provider usage, turns and sessions are caps beside it, and provider usage is a control and never a metric (D117). PG-16 — Budget is a case field P Metrics § Spend envelope and Agents § 0.1: the budget is time — the case's predicted delivery minutes (D135); tokens, turns and sessions are caps and ledger facts, and provider usage is a control, never a metric (D117); two thresholds, escalation on breach, route by profile. Measure: budget breaches per period, and predicted against actual minutes per case type. | ||||||||||||||||||||
| PG-17 | The platform runs as one deployment on the Bulstrad QA environment and reaches every other environment through connectors under per-environment credentials; code deploys run through the estate's pipeline job, resolved and triggered by the deployment agent under the gate (D130), and the write executor applies DDL under HW-ddl (D104). The control plane's placement and each case's start environment are plug-in configuration (platform.host, source.start_flows — D63), never code.PG-17 — Where it runs P Software Architecture. The platform is not deployed to STAGING or PROD; its connectors reach them. P Network reach and egress are Bulstrad IT decisions and the Support default environment (PROD) depends on them. P They follow policy, and policy follows requirements (D128): every reach is a specific, defendable request — never wildcard access — whose answer changes | ||||||||||||||||||||
| PG-18 | Operational controls are goals: a kill switch with a soft mode (finish at the next gate) and a hard mode (fence every lease, park everything, keep the inbox and papers readable), canary activation of published prompts, connector health as a case field, attachment scanning before any file is opened; flipping the switch is a role. PG-18 — Operational controls P Kill switch: soft = no new cases, running cases finish at their next gate; hard = every connector lease fenced and rolled back, every task parked at its last checkpoint, no model call, inbox and papers readable. Flipping either is the Administrator role and a ledger event; DevOps can also flip through a | ||||||||||||||||||||
| PG-19 | An operator's departure is an administration action: controlled sessions are handed over, owned prompts and domains reassigned, held batches they approved re-confirmed or expired, and their grants revoked by removing their USER_ROLES assignment (D134).PG-19 — Offboarding P Removing a person's | ||||||||||||||||||||
| PG-20 | Two cases whose intended writes share an impact key raise a coordination decision; intake dedups by origin key, reporter, referenced object and symptom signature and attaches a duplicate to the open case, naming the controller. PG-20 — Collision and duplicates P Agent Runtime § 11.5 impact keys and Stage Classification § 4 dedup, with the origin key (channel + external id) as the first dedup key so a HelpDesk ticket and its Jira mirror are one case; the controller of the merged case is the operator who opened it first, visible in Cases. | ||||||||||||||||||||
| PG-21 | Every write is simulated before promotion unless it passes the recorded exemption test; production simulation is an authorized exception. PG-21 — Simulation first P Failure and Recovery § 5, promoted from the negative Non-Goal N-2 to a positive goal. | ||||||||||||||||||||
| PG-22 | The platform degrades, it does not stop: with a provider or connector down, cases park, the Decisions queue and the papers stay readable, and operators continue by hand — v1 is retired tooling, not the fallback (D64); a hard stop is a defined state, not an incident. PG-22 — Degraded operation P A provider or connector outage parks the tasks that need it and nothing else; the inbox, the papers and the ledger need no model; operators continue by hand while the platform is down — v1 is retired tooling, not the fallback (Delivery § 3, D64); SLA clocks keep running and the parked cases are the first item in Cases and in Control › Exceptions. Measure: parked-hours per outage. | ||||||||||||||||||||
| PG-23 | Whitelabel, and not to one estate: the platform serves the configuration, support and repair of complex products — products that span many services, systems and procedures — whatever administers them (D77). Bulstrad on Serdica and IPAL is the case study, not the definition. ABACUS is addressed as a system of its own (D125): the rating engine alone behind a foreign policy-administration system, with a contract export instead of an IPAL catalogue, is a product shape to build for — even where one owner runs ABACUS and IPAL as one. A second customer replaces bricks, not the building: its channels, its systems and their connectors, its contract clauses and clocks, its environments and branch flows, its identifier patterns and its field catalogue are the plug-in; the platform, the modules, the gate set, the write protocol and the ledger are not touched (Whitelabel Catalogue). PG-23 — Whitelabel Why: the platform is built for complex products — products that span many services, systems and procedures — whatever administers them, and ABACUS alone behind a foreign policy administration is a product shape of its own (D77, D125); Bulstrad on Serdica and IPAL is the case study. A second customer changes a plug-in and no page (D51). P Contract sections and clocks, the business-hours calendar, severity scales, escalation intervals, identifier patterns, staff rosters, channels and their closure behaviour, register rules, environments and hosts, role → group mappings, impact-key shared rows, deployment-set presets — all configuration with the Bulstrad defaults the pages state; catalogued with their scope in the Whitelabel Catalogue. Measure: the whitelabel lint — a CI step that fails the build on a catalogued value outside the plug-in (Delivery § 5 work streams, D71). |
Agent framework
What every agent gets, independent of which agent.
| # | Goal |
|---|---|
| PG-2 | It runs a native agent loop with first-class skills, tools, memory, sub-agents, and model adapters, adopting the patterns the surveyed harnesses have proven (Agent Runtime). PG-2 — Native agent loop Why: the loop's required properties (sub-agent spawning, plan confirmation, interruption, event stream) are what the modules need; the specific runtime is secondary. F The health-AI program's stated direction is to replace MCP Proxy, the MCP protocol, IntentGPT, and long-lived AI sessions with native C# services ( |
| PG-7 | Models are selected per agent profile through adapters; changing a model never rewrites session history. PG-7 — Model adapters per profile, and the data boundary P Agent profiles declare a model route; adapters resolve it; session records store profile + adapter version. P The data boundary is drawn per module (decision 01.09.2026):
F Both AzureOpenAI and OpenAI adapters exist on the branch (verified 01.09.2026), so the boundary is a routing policy over existing adapters, not new provider work. The direct OpenAI adapter is disabled by default and refuses production unless explicitly approved ( |
| PG-8 | External systems are reached only through connector agents (one per system) that wrap tools with environment scoping and logging. PG-8 — Connector agents P One connector agent per external system (Oracle per env, gateway, Jira, mail, HelpDesk, GitLab, Kibana, RabbitMQ, browser, BI Publisher), wrapping that system's tools with environment scoping, logging, and per-operation effect knowledge. Detail: Agents § 1. F The v1 CLIs (aisa-jira, aisa-mail, aisa-hdesk, aisa-blob) and the PC agent's scoped Oracle MCP/gateway gates are the working seeds (artifact). |
| PG-14 | Prompts, skills, profiles and memory articles are owned, versioned, tested before publication and revertible; publishing is a per-stage role. PG-14 · PG-15 — Governance and evaluation P As Agent Framework, Agents § 0.4 and Agents Memory § 7.4b specify; promoted to goals because the Metrics and the Register hang on them. Measure: publishes with a red eval set = 0; articles retired as wrong per period, with the cases that pinned them reviewed (Support SG-14). |
| PG-15 | Every module keeps eval sets that re-run, batched per domain, when its memory, skills or model route change; a profile whose set is not green does not publish. PG-14 · PG-15 — Governance and evaluation P As Agent Framework, Agents § 0.4 and Agents Memory § 7.4b specify; promoted to goals because the Metrics and the Register hang on them. Measure: publishes with a red eval set = 0; articles retired as wrong per period, with the cases that pinned them reviewed (Support SG-14). |
Agent graphs, and knowledge domains
How agents are composed per module, and what they know. P The two goals describe one object from two sides and are numbered separately only because they are separately measurable. The object is the profile: a versioned row carrying its published instruction, its one owned knowledge domain, its skills, its tools per environment scope, its denied context, its escalation and budget protocol, and its eval set (Agents § 0.1). A graph is what profiles form when they interact — delegation downward, consults sideways, handovers between modules. A knowledge domain is what one profile owns and writes; one writing profile per domain, and profile, instance and domain are distinct objects (Agents Memory).
| # | Goal |
|---|---|
| PG-24 | Each module is a graph of profiled agents: one root that converses with the operator and alone reaches the human; stage agents; isolated sub-agents (verifier, analyst, reviewer, grader); write executors that act only under a grant; connector agents per system. A lateral consult is evidence, never authority; recruiting another module is a gate (Hd); the graph is TASKS data, and every profile of every module is catalogued with what it boots from, writes, may use, receives and returns (Agents).PG-24 — Agent graphs Why: the modules differ in what they do — the desk included — and share how they are built — a root, stages, isolated sub-agents, executors, connectors — and the case studies test exactly that composition (Agents). P The graph is instantiated as |
| PG-25 | One memory tree, an AGENTS.md index per node; an agent is a domain and writes only its own. Articles are governed — proposed, active, retired — versioned, pinned per case and carry provenance; anything that must always happen is a mechanic, not an article; a past-experience index answers "has this been seen" in seconds; v1's corpus migrates per domain and is accepted only when its retrieval on held-out cases reaches at least 50 % top-5 hit-rate, against the measured 10 % grep baseline; a wrong article's retirement reviews the cases that relied on it (Agents Memory).PG-25 — Knowledge domains Why: v1's 548 files exist and do not fire — grep over one-liners finds a precedent for 10 % of held-out tickets (Measurements § TB). P One tree, one writing profile per node, reads unrestricted, writes inside the own domain; article states proposed → active → retired with provenance and version pinning (Agents Memory § 7.4b); mechanics instead of memories for anything that must always happen; the past-case index of Agents Memory and Skills § 5; git as the store, Oracle as the projection (Software Architecture); migration per domain in waves, accepted on the hit-rate (Agents Memory § 7.2). Measure: triage hit-rate and false-precedent rate per domain against the 10 % / 98 % baseline; articles retired as wrong and the cases reviewed. |
Support — the desk (SG)
The root's own goals: intake, classification, the route, the case and its closure.
| # | Goal |
|---|---|
| SG-15 | No operator on duty at the desk: every client request is classified, identified and routed the moment it arrives — waiting, Configuration (Hd), Development (Hd), or the Data and information stages under the same root — with its clocks running from arrival; a waiting case carries its trigger, its clock treatment and its age and re-enters the route at H2 when the trigger fires; the case, its clocks and its closure stay with the desk whichever module works it (D143, D144, D147, D149). Judged by the classification correction and re-routing rates (SG-11), breach warnings ahead of the violation, waiting cases without a recorded trigger = 0, and human turns per case falling to gate decisions (Metrics). SG-15 — The desk without an operator on duty Why: the desk is where v1's cost is least visible and most constant. F 148 fixed tickets sit in Pending without a resolution date, so the closing medians rest on the 175 the customer explicitly closed (Data and Information Module § 0.2, which carries the method of Measurements § TM); an approved write backlog sat at 39 of 51 issues for twelve weeks (backlog); the conversation with the customer is a phase of every one of the 330 tickets that carry one (Support Module § 0.2); and the current agent works only the ticket a person hands it — about 7 ticket folders per working day at a median of 3 human turns (Baseline § 2–3). Nothing watches the channels, and nothing decides what can wait. P The mechanics: intake opens every client case on |
| SG-1 | Any-connector intake: Jira ServiceDesk, shared mailboxes, Bulstrad HelpDesk (OTRS), a request started in place on the client surface (D97, D98) and any further channel the plug-in names (D51) are equal citizens — one case model regardless of arrival channel. SG-1 — Any-connector intake Why: v1 already works three channels — Jira SD (509 ticket folders), the shared mailbox (256 archived threads), HDesk/OTRS (52 cached tickets), frozen baseline 31.08.2026 — but each has its own ad-hoc handling; the HDesk→Jira path accumulated a 39-issue write backlog invisible between sessions (F backlog). P One case model; connector agents normalize arrival (reporter, subject, referenced policies/ids, attachments) into it; channel-specific mechanics (ADF quirks, provenance stamps, mail filters) live in the connector agent, not in every investigation. |
| SG-4 | The solution take is explicit and by kind: an existing skill, a memory answer, a configuration change, the Development module (id source) work, or a combination — with handovers to the Configuration/Development modules under prior human confirmation.SG-4 — Escalation into configuration and development Why: tickets regularly end in "this is a configuration cell" or "this needs code" — v1 evidence: the recurrence-escalation rule, config-toggle-vs-CR classification, and the CR process (F memory files above; classification).
P The support root agent recruits the Configuration or the Development module (id |
| SG-5 | Requests are routed by type and level like a support organization; contract classification and SLA clocks follow the support contract — including its business-hours calendar (Bulstrad: § 1.6.2, Mon–Fri 09:00–18:00 excluding holidays — a plug-in configuration value, Whitelabel Catalogue), so a business-hours platform does not by itself breach a clock; a case parked outside hours is visible in the held view with its age. SG-5 — Routing by type and level Why: a general support organization routes by request type, not by whoever picks up the phone; v1 already classifies by contract (§1 Standard Sev 1–4 / §2 Personalizations P1–P3, workaround downgrade §1.5.3) and by support level (L1/L2) (F contract, levels). P Routing model in Support Module: triage classifies request type (incident, question, data correction, access, master data, configuration change, CR candidate) and level; domain-profiled agents take L2; L3 is a module handover or a CR to the vendor/customer process. SLA clocks per classification are case fields surfaced in the UI. |
| SG-11 | The platform always classifies and the operator corrects in one action; correction rate ≤ 10 % after three months and ≤ 5 % steady (D111). Reclassification mid-case re-runs the contract position, restarts the applicable clock, records the change, and hands a CR candidate to the named commercial counterpart with a defined packet. SG-11 — Reclassification P Stage Classification § 2–3. The commercial counterpart is a named person per customer, recorded in the plug-in; the CR packet is the case's mechanism, the clause that places it outside §1, the effort estimate and the customer's own words. Targets (D111): correction rate ≤ 10 % after three months and ≤ 5 % steady; re-routing ≤ 5 %. |
| SG-12 | A case may be cancelled — the customer withdraws or a duplicate merges: cancel records the reason, tears down applied work (H7 if any) and releases grants. SG-12 — Cancel P A case state next to close: reason (withdrawn, duplicate merged into case X, out of scope), teardown of applied work through H7 where anything was written, grants released, handle map destroyed, the channel told through the gated send. |
Data and information — the working stages (SG)
The goals of the stages the desk routes a data correction or an answer to.
| # | Goal | ||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| SG-2 | Investigation runs on the inherited methodology catalog (the v1 disciplines), applied as pipeline mechanics, not remembered advice. SG-2 — The methodology catalog Why: v1's investigation quality comes from named, hard-won disciplines. They exist as memory files that must happen to fire; the 20.05.2026 audit measured them failing at author time (F write-time discipline). P The catalog is inherited as explicit pipeline mechanics. Every row of the load-bearing v1 set below is a fact citing its source:
P The full catalog is larger; triaging which become mechanics vs. domain memory is part of the v1 memory migration (SG-7). | ||||||||||||||||||||||||||||||||||||||||||
| SG-3 | Recurring and long-running work precipitates: every closed case records an experience entry always, plus at most one of skill, article, index line or justified nothing — so the next occurrence takes minutes, not hours. SG-3 — Precipitation into skills and memory Why (the pain point, stated 31.08.2026): recurring or long-running investigations are not being turned into skills or durable memories — the next occurrence costs the same 1–2 hours that memory or a tool would cut to minutes. The economics are measured: cached knowledge is 10–60× cheaper, 30–300× faster than rediscovery (F measurement). P Case closing includes a precipitation decision, recorded in the audit log: an experience-index entry always, plus at most one of skill (the investigation shape will recur and is mechanizable — e.g. a diagnostic query pack), article, index line, or nothing (justified). The Step-10 walk carries it; the Metrics track precipitation rate and reuse hits. Target (D111): reuse recorded on ≥ 60 % of Support cases within two quarters; retrieval top-5 hit-rate ≥ 50 % per domain before acceptance, from a 10 % baseline. | ||||||||||||||||||||||||||||||||||||||||||
| SG-7 | A past-experience index over resolved cases powers triage and investigation; building the well-outlined AISA v1 memory is part of this goal. SG-7 — The experience index Why: 509 ticket folders (frozen baseline 31.08.2026) + 56 KIs + checklists are a precedent corpus that today is searched by grep and file names; triage needs "has this been seen" in seconds. P A dedicated sub-index of the shared memory for past cases: per case — symptom signature, systems touched, mechanism found, fix shape, links. Structure and indexing need R&D; the first version and the migration of the v1 corpus are specified in Agents Memory and Skills § 5. Building a well-outlined memory of AISA v1 for this module is an explicit goal (31.08.2026 — reversing the earlier non-goal). | ||||||||||||||||||||||||||||||||||||||||||
| SG-10 | An isolated verifier re-derives the mechanism from evidence alone before any customer-visible statement; its verdict is part of the gate packet. Tiered: mandatory for root-cause claims and memory writes, sampled for skill and memory answers on known shapes; verifier + auditor ≤ 25 % of case reasoning at steady state (D111). At steady state the working stages run without any particular human: every shape closed by at least two operators, reuse recorded on at least 60 % of cases within two quarters, retraction cycles at zero, and each domain's retrieval on held-out cases at or above 50 % top-5 hit-rate, against the measured 10 % search baseline before it is accepted (Metrics; D111, D115, D149). SG-10 — The verifier, tiered Why: v1's three retraction cycles (Baseline § 5); and the case studies show a mandatory verifier doubling a 30–40-minute ticket (Case Studies G-3). P Mandatory for a mechanism sent to the customer or written to memory; sampled (one in N, N set from the ledger) for skill runs and memory answers on known shapes; always for the first three cases of a new shape. Targets (D111): retraction cycles 0; verifier + auditor ≤ 25 % of case reasoning at steady state. | ||||||||||||||||||||||||||||||||||||||||||
| SG-13 | Steps executed by an external owner (Bulstrad IT on INSIS, a BI template author) are a step type with a request record, expected evidence on return and an age in the held view — neither a kind of fix nor a capability gap. SG-13 — External-owner steps P A solution packet may contain steps the platform cannot execute — an INSIS action by Bulstrad IT, a template by a BI author. Each is a request record with the evidence expected on return; the case parks on it like on a question; its age shows in the held view (Stage Solution Take § 1). | ||||||||||||||||||||||||||||||||||||||||||
| SG-14 | When a memory article is retired as wrong, the cases that pinned it are listed and reviewed and customer-visible outputs derived from it are re-verified; the count is a metric next to root-cause retractions. SG-14 — Memory retraction P Agents Memory § 7.4b version pinning makes the affected cases a query; retiring an article as wrong opens a review task per affected open case and a re-verification of customer-visible outputs derived from it in closed ones; the ledger records a |
Support — both layers (SG)
Goals the desk and its working stages share.
| # | Goal |
|---|---|
| SG-6 | Customer-visible output and every write to a protected target (a customer-facing environment, a customer-visible channel, a shared configuration row) stay human-gated until the organisation accepts that risk class (N-12); reads and dry-runs run under the case's grants without asking; deferred write batches remain visible with age until applied. SG-6 — Human gates and held writes P Customer-visible output (public comments, transitions, emails) and all writes are gated until the organisation accepts that risk class (N-12); drafts arrive gate-ready. Deferred batches stay visible with age and scope; applying one is a single decision under the original approval, with per-item preflight (F why: the 12-week HDesk plateau). |
| SG-8 | Sessions are durable: stoppable, resumable, transferable; many viewers, one controller. SG-8 — Durable sessions P Per Agent Runtime: stop/resume/delete, many-view/one-control, transferable. Why: v1 session death means disk archaeology (F fact); investigations regularly span days and operators. |
| SG-9 | Support handles personal data, including product 8000 health data, and therefore runs only on GDPR-compliant, EU-resident models (Platform Details PG-7). SG-9 — The data boundary, and its budget P EU-resident, GDPR-compliant models only (Platform Details PG-7); handles at the connector (Trust and Data § 4). Measure: non-EU model calls = 0, from the route records. F The budget effect of the boundary is that the module with the most v1 evidence changes model family (review of 02.09.2026); the first ten cases measure it. |
Configuration (CG)
From stray input documents to a configured, tested product, deployed as far as the user chooses.
| # | Goal |
|---|---|
| CG-1 | Accept input from any connector — tickets, mailboxes, the help desk, files — pre-check it, ask early on obvious misses, and normalize it into the whitelabel specification every other agent understands, each field citing its source. CG-1 — Any-source intake → whitelabel specification Why: real material arrives as spreadsheets, PDFs, Word documents, emails, help-desk requests; templates differ per product and get revised; gaps discovered late poison everything built on them. v1 evidence: the operator template alone has two shapes, transposed sheets, stale legends, and cover counts that disagree across sheets (F PC |
| CG-2 | Each stage investigates what its target storage expects before writing — ABACUS, IPAL, serdica services, code — and plans with per-step assertions. Comparison against a close existing product is desirable, not a prerequisite. CG-2 — Storage expectations investigated, plans refutable Why: a spec covers a fraction of what a working product needs; the difference is discovered per target storage. v1 evidence: specs cover 4–6 of 12 configuration parts (F skill); three pre-questions each "stranded a finished product when answered late" (F artifact: closed lookup codes; a deployed process that fits; environment expectations). P Investigation is a phase of every stage's plan (protocol phase 1–2), not a separate stage; plans carry step ids and assertions so execution is reconcilable. P The comparable product is desirable, not a prerequisite (decision 31.08.2026): declared when a live donor exists (feeding clone-and-adjust and the donor diff), skipped without blocking otherwise — the stage skills compensate. |
| CG-3 | The stages are S1–S5 and run in two phases: S1 Normalization, then phase 1 Abacus, then phase 2 with Serdica and IPAL + Offer at the same time, closed by a joint proof an operator drives. Core/Camunda registration is S3 IPAL (D86). A phase ends by signing out a document the next phase reads — never its transcript. Loop-backs are allowed and re-enter the earlier phase as a delta. Every stage runs the same protocol: gather → plan → confirm (H2) → apply → test → iterate until the user is satisfied (H3) → scripts → approve scripts (H4) → approve execution on the named target (H5) → deploy → verify. CG-3 — Five stages, one protocol Why: the stages map one-to-one onto where configuration actually lives (F product configuration: rating in |
| CG-4 | Testing is skill-based: the test skills — getRates, policy, offer, the route/label sweep — and the two write skills abacus configure / ipal configure (Components § 4). Pricing factors target the POL sale stage only.CG-4 — Skill-based testing, POL only Why: improvised testing is unrepeatable; a skill encodes request manufacture + assertions once, and every run, smoke test, and eval reuses it (F getRates recipe — computes and stores nothing — the safe inner loop; it prices every configured cover, so assertions are per cover).
P The test skills are getRates (factor payload built from what the product declares — queried, never remembered; asserts per-cover premiums against the documents), policy, offer, and the route/label sweep; the write skills are |
| CG-5 | Verification is per stage; deployment is scoped: the deployment set may be abacus only, abacus + ipal, or the full product — chosen with the user, executed as script sets with teardowns, smoke-tested on the target. CG-5 — Per-stage verification, scoped deployment Why: "one big verification at the end" hides which stage broke, and deployment reality varies — a tariff update deploys abacus only; a new product deploys everything (F the 9951 lesson generalized: a product can price to the cent and still not quote — completeness is proven per layer, by executing it).
P Every stage verifies itself with its skill (working env, then target); the deployment set is chosen with the user and revisable; each stage emits idempotent scripts + teardown; smoke tests are the deployed stages' skills run read-only on the target. Detail: Configuration Module § 3.
F Idempotence guards are a documented defect class (four silent failure modes catalogued in the PC artifact) — guard patterns live in |
| CG-6 | Human gates use the gate kinds of Gating § 1. H5 is execution on a customer-facing environment (D114); Hd hands over to the Development module (id source).CG-6 — The human gates Why: these are the points where a wrong autonomous decision is expensive or irreversible; between them the agents work alone. P The platform gate set is defined once as the gate kinds of Gating § 1. In this module H5 is execution on a customer-facing environment (D114), and Hd is the Development-module handover with prior human confirmation. Gate decisions and their scopes are audit records. |
| CG-7 | Every session is stoppable, resumable, deletable; open to many viewers, operated by one. CG-7 — Session behavior P Stop/resume/delete; many viewers, one controller (Agent Runtime). Resumption replays nothing — completed steps and platform-returned ids live in the build state (F proven resumable-apply pattern). |
| CG-8 | Reversal is first-class: every applied change carries its teardown; executing one is a gate decision. CG-8 — Reversal P Teardowns derive from the write log ("the set removed is exactly the set written" — F artifact); irreversibles (consumed numbering, external registrations) are named in the stage plan; execution is gate H7. |
| CG-10 | A configuration request carries its commercial position — covered work, a §2 offer, or a program — before H1; a request without it stops at H1 with the offer path as the resolving event (Non-Goals N-7). CG-10 — Commercial position before H1 Why: a new product or a tariff change from the customer is §2 Personalizations work with offer deadlines, or program work; the module's capability to do it is not approval to do it (N-7). P Intake records the position — covered (§1), §2 offer id, or program — and H1 does not close without it; the offer path is the resolving event, owned by the commercial counterpart named per customer. |
| CG-11 | The customer's acceptance of a configured product is a gate distinct from H3: the Customer representative confirms on the working environment before any deploy to a customer-facing environment; the confirmation is a ledger record naming the person. CG-11 · CG-12 — Customer acceptance and STAGING as a gated target P The customer's business user is the Customer representative role: view, and accept on the working environment. Acceptance is recorded with the person's name and the artefact hash; H5 to STAGING/TEST or PROD follows it; QA uses H4 plus the write auditor (D114). Why: the customer works on TEST/STAGING; a deploy there is customer-visible. |
| CG-12 | Deployment to STAGING/TEST and PROD is customer-facing — H4 scripts plus H5 by an Approver for that environment; QA is H4 plus the write auditor (D114). CG-11 · CG-12 — Customer acceptance and STAGING as a gated target P The customer's business user is the Customer representative role: view, and accept on the working environment. Acceptance is recorded with the person's name and the artefact hash; H5 to STAGING/TEST or PROD follows it; QA uses H4 plus the write auditor (D114). Why: the customer works on TEST/STAGING; a deploy there is customer-visible. |
| CG-13 | Specification quality and elapsed time are measured: intake → preview ≤ 1 business day; intake → customer acceptance ≤ 5 business days median (baseline: configuration-change tickets close in 9 days median and master-data tickets in 11, over the 175 customer-closed tickets); unresolved[] ≤ 5 at H1 and 0 at close; ≤ 2 H1 correction rounds; QT rows 0; unreachable products 0 (D111).CG-13 — Measures P Metrics rows (D111): intake → preview ≤ 1 business day; intake → customer acceptance ≤ 5 business days median (baseline: configuration-change tickets close in 9 days median and master-data tickets in 11, over the 175 customer-closed tickets); |
| CG-9 | The module handles no personal data — configuration material is structure, tariffs, terms and templates, which is a different activity from handling what the product later processes. No product family is excluded on this ground. To keep it true on real threads, the intake substitutes personal data by case-local handles on arrival: identifiers and detected names are replaced at the connector before the material is stored, so the case is operator-agnostic — any operator can take it, and no route or staffing decision depends on who sees it (Trust and Data § 4). Material that consists of personal data — a real census file, a policyholder list — is not configuration material at all and is rejected at intake as the anomaly. Personal data means data about natural persons who are customers, insured or claimants; the names of Ablera and Bulstrad staff acting in their roles and synthetic test identities are not anomalies (Platform Details PG-7). CG-9 — No personal data: handles at intake, operator-agnostic cases P "Personal data" here means data about natural persons who are customers, insured persons or claimants. Reporter names on a HelpDesk request, Bulstrad staff named as role holders, Ablera colleagues, and synthetic test identities are not anomalies — without this scope every HelpDesk-sourced request would stop at S1. P Stray personal data in real intake — the policy numbers, named employees and reporter identities a genuine configuration thread carries (Configuration Module § 8 CS-3) — is substituted by case-local handles at the connector on arrival (decision Vladimir, 02.09.2026 — D57): the same handle substitution Support uses (Trust and Data § 4) runs on configuration intake before the material is stored, so the case is operator-agnostic — any operator picks it up, no model-route or staffing decision depends on who sees it, and the module's "any adapter" boundary (Agents § 0.3) holds by construction. What stops the stage is only material that is personal data — a real census file pasted into a specification thread — because that input is not configuration material; the anomaly is the wrong input, never a stray identifier in the right one. A census-rated product (8000) is configured from synthetic worked examples, marked synthetic. The normalizer's detector runs the refuse-list (ЕГН pattern, customer names against the policyholder surfaces) as the substitution driver, not as a stop rule (Trust and Data § 4). |
Development (DG)
Bug fixes and small features that extend existing functionality — not new modules.
| # | Goal | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| DG-1 | Scope: defects and small extensions over existing functionality. New modules and new-product functionality are out (they are the estate's program process, or configuration work). DG-1 — Scope: ad-hoc only Why: the measured wins are exactly here — the June 2026 work was defects and extensions over existing flows (F CEO evidence); module-scale work runs as an estate program (the health-AI program with its 17 sprint programs is the counter-scale — F branch docs). P Intake classifies: defect / small extension → this module; new module or product capability → out, with a pointer to the right process. | ||||||||||||
| DG-2 | Flow: start environment per case-type configuration (D63) — running products: bulstrad-staging → master + bulstrad-qa; new, unreleased products (health): bulstrad-qa → port to master — fix where the case's flow says, test, and prepare deployment scripts for the targets the brief names. DG-2 — Staging-first flow Why: the customer lineage is not master:
A case's flow is chosen at intake and recorded in the brief (H2); switching flows mid-case is a plan revision.
F The porting discipline is inherited: fix commits only, base commit named (rule); ancestor-merge fast-forward trap and the branch-differentiated | ||||||||||||
| DG-3 | An environment is a branch set across repositories — intentgpt, serdica-ui, serdica-backend — plus the DB model and PL/SQL on that environment's database. The divergence state is memory, not documentation, and it is re-measured, never quoted stale. DG-3 — Environment = branch set across the source's repositories F For the Bulstrad estate (the first plug-in's source set — D58), one environment spans intentgpt (Beth + AI components; separate repository; the health-AI program replaces it on the health path), serdica-ui, serdica-backend, plus the DB model (dbml) and PL/SQL on the environment's dedicated database (95 | ||||||||||||
| DG-4 | Placement first: customer-specific plugins, microservices, or environment-resident PL/SQL — every SRD_INTEGR package (POLQRY, TR_*, INS_*, ABC_PREM*, the UEXIT_* exits — 95 bodies on PROD); core only as a core-change proposition. Either way the human gets the brief — why, blast radius, test plan — before development.DG-4 — Placement first, core by proposition Why: customer-specific placement keeps the blast radius one customer; core changes hit every customer and every upgrade. The seams exist (F inspected 31.08.2026: | ||||||||||||
| DG-5 | Deployment, testing, and reversal are mandatory parts of every case — a change without its deploy path, test evidence, and revert path is not done. DG-5 — Deploy, test, revert = definition of done Why: v1's gap — promotion and rollback handled out-of-band; the KI-050 class shows what promoting config ahead of its evaluator causes (F rule).
P Every case ships deployment scripts per target, test evidence per lineage ( | ||||||||||||
| DG-7 | Every Development case publishes a merge request reviewed under the Ablera development process before its deployment scripts are approved; the review is a gate record, not a transcript line. DG-7 — The merge request is a gate Why: GitLab publication is a side effect under control (Trust and Data § 2) and the estate reviews code through merge requests. P S5 corrections end with an MR on the case branch; the review verdict of the Ablera process is recorded as the H3 decision for the case; S6 scripts follow the approved MR. | ||||||||||||
| DG-8 | Deployment is executed by the estate's mechanism — the serdica-infrastructure pipeline job runs Ansible; the write executor applies DDL under the gate (D104); the platform prepares, records what ran and verifies the runtime. The deployment agent (D130) resolves the job by a per-environment rule — the last build job of serdica-infrastructure, then the deployment-phase job that includes the service; bulstrad-staging and bulstrad-prod from the v3.0.0 branch, the rest from master — and triggers it after the target gate (H4, + H5 where customer-facing). Ablera DevOps holds the rights and the compose units, not a step in the loop.DG-8 — Who deploys Why: Software Architecture § 10.2 — deploy is a manual Ansible job from another repository; DDL is applied by the write executor under | ||||||||||||
| DG-9 | Placement is measured: ≥ 80 % entirely in seams 1–3, 100 % of seam-4 landings with a proposition; port MR ≤ 1 business day after PROD verification, rework ≤ 10 %; reverts ≤ 1 per 20 deploys and executed ≤ 1 h; interventions ≤ 4 gates + ≤ 2 questions; acceleration ≥ 2× (D111). DG-9 — Measures P Metrics rows (D111): placement ≥ 80 % entirely in seams 1–3 (baseline 5 of 8 case studies), 100 % of seam-4 landings with a proposition, port MR ≤ 1 business day after PROD verification, port rework ≤ 10 %, reverts ≤ 1 per 20 deploys and executed ≤ 1 h after the decision, interventions ≤ 4 gates + ≤ 2 questions, acceleration ≥ 2×. | ||||||||||||
| DG-6 | Agents are repository-profiled, each booting from its source/<repo> memory domain; repository knowledge (microservice indexes, build truths, branch maps) lives in memory, not in module documents.DG-6 — Repository-profiled agents Why: the repos differ in language, build system, and failure modes; a profile per repo boots focused from its own memory domain instead of generic.
P Profiles and their domains — one per declared source of the customer's plug-in (D58); for Bulstrad: |
Baseline — the measured starting point these goals are judged against
The measured state of 31.08.2026. Everything here is fact; goals cite this document as evidence. Numbers are measured in the workspace or sourced from the linked files.
1. What v1 is
One Claude Code workspace (aisa-poc) in a terminal on an operator's laptop. One conversation at a time; the operator is the controlling human. Two operator machines exist (tooling state); they synchronize through git branch merges (procedure). No web interface, no durable case state outside git and files, no parallel cases on one machine.
2. Delivered volume (measured 31.08.2026 — frozen)
| Asset | Count | Where |
|---|---|---|
| Ticket folders (analysis directories) | 509 | jira_tickets/ |
| Archived email threads | 256 | emails/ |
| HDesk (OTRS) cached tickets | 52 | hdesk/ |
| Non-ticket investigations | 10 | others/ |
| Knowledge articles | 25 + the self-contained health KB | knowledge/, bst_health/ |
| Memory files | 548 | memory/ |
| Skills | 20 | .claude/skills/ |
| Known-issue register entries | 56 | KNOWN_ISSUES.md |
| C# CLIs (jira, mail, hdesk, blob) | 4 | tools/ |
| Oracle connections | 11 BST + 1 DEV | SQLcl MCP |
This table is a frozen baseline 31.08.2026, not a live count: it is the reference point the Metrics targets are measured against, so it is not refreshed. Today's figures come from pwsh scripts/baseline_counts.ps1; the gap between the two is the growth since the baseline date.
Growth: 219 ticket folders + 89 threads on 02.07.2026 → 509 + 256 on 31.08.2026 — 290 new ticket folders in 60 calendar days: roughly 5 per calendar day, about 7 ticket folders per working day (source).
3. Measured effectiveness (evidence base of 02.07.2026)
From the CEO agent-effectiveness evidence, assembled from git, session logs, and the UAT Health defect file:
- UAT Health file, 46 dual-estimated rows: 106.75 developer-days → 49.5 with agents (2.16×).
- June 2026 realized: ~55 person-days of work in ~25 calendar days; Vladimir personally 45 → 18 days (2.5×).
- CR schedule (35 rows): Σ 179 → 136.1 days (−24 %); only technical phases shrink (implementation 63.1 → 29.9, tests 14.5 → 4.8).
- Session shape: support sessions median 3 human turns; large development sessions ~85–90 agent actions per human message, median ~18 human interventions; the agent self-ran ~138
dotnet test, ~75dotnet build, ~57nx buildin June.
4. The write discipline v1 already has
- Default posture: strict read-only — no DML on any environment, not even inside a rolled-back block.
- Human approval at exactly three gates: DB write, customer-visible publish/transition, inferred external-write target (evidence, rule).
- Authorized DB writes follow the 5-step protocol: show → apply without commit → verify in DB → replay the UI/backend query → COMMIT last; failed verification = ROLLBACK (SD-1757).
/configure-productnever executes: idempotent SQL per part, acceptance script of zero-row checks, rollback script, stop-and-ask on every ambiguity.- Jira writes: pre/post status refresh, one internal comment per ticket, closure only via Pending.
5. Documented instability
- Cross-session audit of 20.05.2026: 14 recurring error families, four recurring after the rule against them existed — root cause: discipline rules pass at review time but fail at author time in a single context (write-time discipline). Examples: ASCII quotes breaking BG JSON 4×, propagation checklist halted 4×, greeting register-clash 5×, guessed column names → ORA-00904 loops.
- Three full retraction cycles (HTML + Jira + memory) from pattern-matching a past ticket into a confident root cause without verifying the mechanism (SD-1627, SD-1636, SD-1651).
- Infrastructure fragility: SQLcl MCP wedges mid-session and is autocommit-per-call; one DB connection at a time; INSIS caps 6 sessions/user → ORA-02391 (rule); MCP servers fail to connect at session start.
- Context death: long investigations hit session limits; recovery is disk archaeology. A case survives only as files plus the operator's memory.
- Held-write friction: the HDesk→Jira backlog sat at 39 of 51 issues for 12 weeks across seven refresh-only runs — approved-in-principle work queues invisibly between sessions.
- Retrieval economics: cached knowledge is 10–60× cheaper, 30–300× faster than rediscovery — but 548 flat files retrieved by grep and one-line descriptions is exactly what the 20.05 audit shows failing to fire.
6. The sibling that already executes — the PC agent
A single-purpose Product Configurator workspace configured product 9951 «Каско Максимум» end to end on dev — catalogue, rating, offers, routing, then the real sales wizard until a premium rendered and reconciled (source archive). It proves in working detail: sub-agents isolated by denied context (tariff-analyst, grader), scripts as the only write path with dry-run defaults and environment locks that refuse before connecting, a semantic product-model.json contract with mandatory count reconciliation, the donor-diff completeness gate, a five-rung proof ladder, resumable apply via state files, per-product working papers, and a round-trip acceptance harness. Its named gaps: the write path ran under a personal session (no service account), one hard-wired environment, no case control, no audit ledger. Its boundary list ("ServiceDesk tickets — other agents own them") shows an estate of focused agents already in operation, including a shared memory MCP fed by multiple agents.
7. What v1 cannot do
- No web access, no parallel cases, no multi-user coordination.
- No durable case object — plan, evidence, approvals live in chat scrollback, HTML files, and git.
- No execution for configuration in this workspace (
/configure-productstops at files); the PC sibling executes but single-environment, single-purpose, outside any session control or audit. - No simulation-environment lifecycle; rehearsals are manual and cleanup is unproven.
- No policy engine — the three gates are convention, enforceable only by the model's own discipline.
- No verifier separate from the author — the proven failure mode.
- No audit ledger beyond git history and Jira comments.