Support Dark Factory · Serdica estate

The trainable intellect that operates the systems behind your products.

People teach it how their products and systems work. Their expertise becomes reusable skills and verified knowledge, refined through reviewed results. They define the outcome and authorise consequential changes; AISA carries out configuration, development and support, checks the result and retains what the next case needs.

Design specification · platform implementation has not started. One real configuration request is worked end to end under the goals, with its screens, and all 68 case types are in the walkthrough.

How it works The goals Technical documentation
How it works

One platform carries the work across the systems it touches.

A request arrives on a channel the customer already uses. The platform opens a durable case, issues its grants and starts its clocks. The Support root classifies and identifies it; trained agent profiles work it, in the module the work belongs to, across every system it touches. Between decisions the software proceeds within its authority.

Open the detailed view for the agent map; it fills the browser tab. Hover a node to read its brief in the board below the diagram, click it to lock the brief; the board carries its methods, helpers and knowledge domains and links to the full technical page. Ctrl+wheel zooms at the pointer; hold the middle button to pan. The detailed view has its own address: index.html#agent-map opens this page with it already open.

Orchestration agentStage agentUtility agentSkillToolDecision gatePrecipitation eventflow · return or rework↔may consult · in the node's linewhat these mean →

The operating model (Bulstrad case study)

The middle of this picture is the product. The top and the bottom are the Bulstrad case study. The platform is for complex products — products that span many services, systems and procedures — whatever administers them. Bulstrad on Serdica and IPAL is the case study this page draws. A second customer replaces bricks and not the building: its channels, its systems and their connectors, its clocks, its environments and its field catalogue are the plug-in.
Input channels · For Bulstrad case study
Jira ServiceDesk Mailbox Serdica UI … and others
The platformthe part that does not change per customer or complex product UI · Backend · Agent framework · Agents and their graphs · Knowledge domains Platform diagram →
Modules — Support is the root: every request is classified and identified there, then waits or goes to the module whose work it is. Each module is a set of agent profiles trained for that kind of work, and the tree they form, running on the platform above.
Root module

Support

Every client request enters here. It is classified against the contract and identified, and either waits — for the next release, or for the customer's own step — or goes to the module whose work it is. The case, its clocks and its closure stay here: one voice to the customer.

routeswaitsConfigurationDevelopmentAssessment & OffersData & Manipulation Its purpose and operating model
Module

Configuration

Tariff files, templates and emails become a rated, catalogued, packaged and wired product, deployed as far as the user chooses.

Its purpose and operating model
Module

Customer-specific development

Plug-ins, extensions and stored code on the lineage the customer runs: reproduced on that branch set, placed at the narrowest customer-specific seam, reviewed and deployed with its revert path.

Its purpose and operating model
Module

Data & Manipulation

A data correction or an answer: investigated across every system it touches, verified independently, applied under a grant, re-checked on the customer's surface, and kept for the next case.

Its purpose and operating model
Module

Assessment & Offers

Everything else — core product development, new releases, contract and SLA matters: establish the required work and effort, present the offer and delivery terms, and obtain the customer’s decision.

Its purpose and operating model
The working agents interact in two ways: a consult asks another module's domain for knowledge — evidence, never authority — and a handover recruits it as a sub-case behind gate Hd, accepted or rejected with a reason.
Systems connected · For Bulstrad case study
Serdicathe suite the customer's insurance systems run on — and the suite this platform is built insideConfiguration · Data & Manipulation · Customer-specific development
The incumbent systemoutside the suite, with its own document and interface servicesData & Manipulation
Infrastructurenot systems the platform configures — how it builds, delivers and observesthe platform's own operation
Estate · Insurance systems

Two policy administrations, a rating engine, a process engine.

One product lives across all of them, per environment. The platform configures, investigates and repairs them; it does not replace them. Every access goes through a connector under a grant that is refused before contact.

How the estate is reached

  1. Only through connectors, one per system, per environment scope, with a capability description per operation: input, target, expected effects, authorization, timeout behaviour, recovery. An unlisted operation is a capability gap to escalate, not a call to improvise.
  2. Under grants refused before contact. A case opened as an incident holds read grants and nothing else; a data fix needs a gate; a second, unshown statement is refused before the connection is used.
  3. Per environment as a real credential boundary, so a case opened against a test environment cannot reach production even if every other detail is right.
  4. Simulation first, except for changes both very small and without blast radius; the exemption has five conditions and is recorded in the plan.
  5. Effects no transaction covers are named: process instances, queue messages, generated documents, consumed numbering, external registrations — compensable or irreversible, declared per step before approval.

Facts

  • Configuration for one product lives in four places in two databases with no foreign key between them. Nothing enforces consistency, and two of the four have no maintenance screen.Product Configurator Requirements § 01
  • The rating call computes a quote without changing policy data, so it supports the repeated checks in configuration and pricing work; its operational effects are declared by the connector.Stage Abacus
  • The rating engine prices only a deployed version, so a version on the working environment can be tested under its declared scope and effects — and the deployment set to customer-facing targets stays a separate, role-gated act that names every version consuming a changed file.Product Configurator Product design § 05, decision D113
  • Code changes to the incumbent system stay change requests to the customer. Data corrections under a grant are the whole write scope there.Non-Goals N-1, N-10
Continue Trust and Data Failure and Recovery Glossary
Estate · Engineering

The platform prepares. The estate's mechanism executes.

Build, push and deploy are the estate's own pipeline and job; a deployment agent resolves the right job by a per-environment rule and triggers it once the target gate is passed, while the operations team keeps the rights and the compose units. Database changes the platform prepares are applied by its own write executor under the DDL gate, with the identity the database administrator grants. The platform records what ran and verifies the runtime.

Who operates what

  1. Operations: build, push, deploy, container restarts. The platform is one more unit alongside the existing services.
  2. Database administration: the identities, their rights and the backup inventory; the platform's own schema is created by the DBA once; estate PL/SQL changes are applied by the write executor under the DDL gate, always a human decision.
  3. The customer's IT: network and the agreed identity/operational prerequisites — the platform's six roles are rows it adds itself and Authority issues as claims, so there is no directory request; a direct route the reach probe finds closed becomes one specific network request.
  4. The platform team: a reachability probe on first deployment; every connection is direct, and reach per target — reachable or not — is written as data; a closed route becomes one specific, named network request.

Facts

  • The minimum alert set raises into the existing log channel: ledger export lag, connector health, budget hard-stops, gate escalation, a red eval set, parked-case age, the kill switch flipped.Software Architecture § 10.5
  • Secrets never reach the repository or a model. Files read from a worktree are scrubbed before a model sees them.Trust and Data § 4
  • The QA database — the environment the platform runs on — had no working backup on 02.09.2026 (last RMAN 26.07.2024, failed). Restoring it precedes the platform's schema; until then the 15-minute off-database export is the only durable copy.Software Architecture § 10.5
  • The process engine is a configuration target, not the agents' orchestrator. Agents control their own jobs.Non-Goals N-4
Continue Software Architecture Trust and Data § 3 — roles
Goals · Proof

What this operating model should change.

Make the expertise behind your products reusable: work that can be taught, carried out and checked, then improved from experience.

The goal, in one configuration request

Make the change.
Prove the right caller gets it.

“Give KOLHIDA and MAXO their own EUR prices — and no one else.”

CF-05 is the modal ABACUS change on this estate: product 4704 alone carries 115 rating versions against 71 product versions. HDesk 00097862 and 00102031; the INSIS five-table anatomy of SD-1443.

Today each template is a version prepared on TEST and promoted one to two months later — and thirteen online-channel templates of 06–07.2026 never left TEST at all.

For this customer

Each approved template becomes its own bounded work item: a pinned leaf specification and effective version, the approved offer selector and permitted audience, then per-cover rating proof on the requested target. The request is not finished because the versions compiled — it is finished when the intended caller resolves the approved template, the default caller keeps its existing tariff, and the excluded role still sees nothing.

For the next request

Retain that template existence, caller selection and product visibility are three different checks, and turn the probe into a tool that records the resolved template and version for the intended, the default and the excluded caller. The next partner request resolves the caller and the active template first, then writes a version delta instead of copying an example.

The screen the approver works in, with this case’s own contenthover it for full size

What it touches in the Configuration module

  • Parts 5, 3 and 12 of the twelve — tariff, packages, access — plus the INSIS discount configuration and its five-table anatomy (CFG_ABC_QUEST_DISC_AGENT 4 → 33 rows, SD-1443).
  • Stages S2 Abacus, S4 Offer and S5 Serdica only; the deployment set is abacus-only plus the product-visibility roles (“Show custom product 4704 / 4710 for (AVVI)”).
  • The rows a partner template actually moves: LB_OFFER_PRICING_RULE 8, CFG_SPECIAL_OFFER_MOTOR 14 (08.2026), and one rating version per template — KOLHIDA_EUR, MAXO_EUR, BL / ER_RENT / ER_LEASE.
  • S1 has to hold N templates for one product where the product schema holds one, so every template is a leaf specification with its own selector, audience and effective version.

What has to be proved before it is delivered

  • KOLHIDA and MAXO examples select their declared template/version, not silent fallback.
  • Default callers keep their existing tariff and excluded roles gain no visibility.
  • Every declared template has per-cover rating proof on the requested target.

The variant that must fail: All templates compile but every caller falls back to the default: fail.

ModuleBaseline · by handBaseline · current agentThe goal
Support — the rootevery request, at the desk 148 fixed tickets wait in Pending with no resolution date, and an approved write backlog stood at 39 of 51 for twelve weeks.Support Module § 0.2 7 ticket folders a working day, median 3 human turns — but only for the ticket a person hands it. Nothing watches the channels.Baseline § 2–3 No operator on duty. Every request classified, routed and clocked the moment it arrives; whatever waits shows its reason and its age.Metrics
Configurationone product or tariff change 9–11 days to close a configuration request against 1–2 for a correction, and the written specification covers 4 to 6 of the 12 parts.Configuration CG-2 There is none. Four configuration surfaces in two databases, written by hand, with no foreign key between them.Baseline § 6 A preview in one business day, customer acceptance in five — and nothing unreachable after release.Configuration CG-13
Customer-specific developmentone change 106.75 developer-days over 46 dual-estimated rows, on a change-request schedule of 179 days.Baseline § 3 49.5 developer-days on the same rows — 2.16× — at a median of 18 human interventions a session.Metrics Hours or days for a customer-specific change, with 80 % of it landing in customer-specific seams.Development DG-9
Data & Manipulationone correction or answer 40 minutes of a skilled person on the median ticket — and one person leads 33 of 35 shapes.Value and ROI § 2b 1.5 h, of which the operator spends 15–30 minutes; the analysis, the ticket notes and the memory entry fall out as by-products. Three retractions came from pattern-matching a past ticket.Baseline § 5 No person-specific knowledge. Every shape closed by at least two operators, and retraction cycles at zero.Support SG-3, SG-10

What the platform holds, for all four

Platform

Autonomy that graduates

Consequential actions stay with people while a work shape is learning. Policy answers the same gate only after three clean, person-confirmed instances, the auditor's pass and an accepted risk class — and one revert suspends the shape.

Gating § 9
Platform

Audit by construction

Every action lands in an append-only, hash-chained ledger, sealed and exported off-database every 15 minutes. Metrics are parsed from it by tools, never counted by agents — and the database administrator is inside the threat model.

Architecture § 3.2
Platform

Knowledge confirmed before it is shared

What a case learns stays with that case until a person reviews it or two independent uses confirm it, version-pinned. A knowledge domain is accepted only when its retrieval on held-out cases beats the measured search baseline of 3 hits in 30.

Agents Memory and Skills
Platform

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, its four modules, the gate set and the ledger are not touched. Bulstrad on Serdica and IPAL is the case study.

Whitelabel Catalogue

What it is deliberately not — a policy administration system, a process engine driving the agents, new modules in Development, or autonomy the platform granted itself: the non-goals.