AISA v2.0 / Technical documentation / Glossary
Glossary
F verified factP decided planC open challenge
| Term | Meaning |
|---|---|
| AISA | AI ServiceDesk Assistant — v1 is the aisa-poc Claude Code workspace; AISA Next is the platform this wiki specifies. |
| IPAL | Ablera's own policy administration system (Serdica suite): quotation → underwriting → issuance → annexes → renewal + FNOL → settlement; UI is serdica-ui. Not a front end over INSIS. |
| INSIS | The incumbent PAS at Bulstrad (Oracle + Oracle Forms). Code changes there are CRs to the customer. |
| ABACUS | Ablera's pricing and rating engine; design side in SRD_ANLT.PPA_*; ABC_ACCESS is its resident schema on the INSIS DB. |
| Serdica estate | The repositories and services around IPAL: serdica-backend, serdica-ui, intentgpt, plus the per-environment databases. The suite holds IPAL, ABACUS and the process engine. BI Publisher and the client SOAP interfaces belong to the incumbent side, not to the suite (stated 03.09.2026 — D78). |
| MATRICA / Матрица | Bulstrad's own web interface onto INSIS — not onto IPAL. With INSIS Forms and the PORTAL channel it is the non-IPAL issuing path, and it skips IPAL's checks. POLICY_SALE_CHANNEL.CHANNEL_ID distinguishes IPAL · PORTAL · INSIS · INTEGR; “portal” in this wiki means the PORTAL channel, never IPAL. |
| Environments (the Bulstrad plug-in) | PROD · TEST = the rebuilt STAGING (serdicastaging.bulstrad.bg, app .112, databases .122 IPAL / .123 INSIS; the earlier serdicatest generation is decommissioned, and both names are used for this one, so key on the address) · QA (10.239.82.106 IPAL / 10.239.82.120 INSIS) — the working environment where the product line says so (D123) and where feature-gated work runs · the Ablera DEV host (10.18.55.3), Ablera's own, with no INSIS or ABACUS counterpart. environments.<env>.customer_facing is a plug-in flag: STAGING/TEST and PROD true, QA false (D114). Branch names: bulstrad-staging runs TEST/STAGING and was called bulstrad-test until 22.10.2025 — the two names are one branch. |
| intentgpt | The estate's separate AI repository hosting the Beth and AI components; being replaced on the health path by the C# health-AI program. |
| Beth | The estate's virtual assistant (Master Bot → domain → line-of-business → MINIBOT routing). |
| PC agent | The Product Configurator sibling workspace that configured product 9951 end to end on dev — the proven-pattern source (archive). |
| Health-AI program | The C# program on codex/health-ai-csharp-architecture: Ablera.Serdica.AI (Manager host, provider/prompting/metering/persistence libraries), Ablera.Serdica.Workflow (StellaOps), replacing MCP Proxy/IntentGPT/long-lived AI sessions on the health path. |
| StellaOps | The workflow engine of the health-AI program (Ablera.Serdica.Workflow). |
| AGENTS.md | The index document of a memory-tree node; the root AGENTS.md carries the protocol (boot, writing practice, dreaming, node creation). |
| Dreaming protocol | The post-case/scheduled memory pass: harvest → classify (skill/article/experience/index/nothing) → write in the own domain → consolidate → new nodes only if really necessary. |
| Deployment set | The chosen scope of a configuration deployment: abacus only, abacus + ipal, or the full product. |
| Module | A work area on the platform, run by a graph of profiled agents. Support is the root module (D143): every client request enters it, is classified and identified, and leaves by one of four routes — waiting, Configuration, Development (id source), or Data and information, the former Support module's working stages, which run under the same root (D144). A module is nothing more than its stages (D87): each module page draws its agent tree, its memory branch and its skills at its head (D145), and each stage page names its agents, its isolated sub-agents, the memory domain it owns and its skills. A module is a unit of behaviour, not a unit of work — the work divides by discipline (D80). "The three modules" in older text means the three working modules under the Support root. |
| Stage | One document, one phase of a module's work, with an id (S1…S9). The ids name the documents, not a running order (D83) — Support enters investigation from the take, and a case with a ready solution never enters S2. |
| Whitelabel specification | The normalized product-specification format the configurator fills from stray inputs; seed: the PC agent's product-model.json. |
| Sale stage (QT/POL) | The two pricing-factor stages in IPAL. QT (quotation) is being obsoleted; AISA Next configures POL only. |
| LT / lookup | The closed lookup-code tables (LT_*) whose codes are platform-wide vocabulary. |
| Routes / EndPoints | SRD_SYS."Routes" (UI visibility tree, role-gated) and SRD_SYS."EndPoints"/"EndpointSections" (live endpoint registry). |
| Core | The router service (src/Serdica/Core); old-style microservice endpoints register in its appsettings.json; it hosts the Camunda integration ("core-Camunda"). |
| BSO | Strict-accountability blank stock (Green Cards, stickers) with numbering lifecycles. |
| ДЗО / product 8000 | The Bulstrad health product family; АО = provider (амбулаторни отчети) report processing. |
| Case / Session | Case: the durable work object (objective, material, papers, decisions). Session: a live execution of it — stoppable, resumable, deletable; many viewers, one controller. |
| Working papers | The per-case artifact set: plan (step ids + assertions), semantic contract, write log, build state, MISSING, report. |
| Gate (the full set) | A defined human decision point. The set is platform-wide and defined once in Gating § 1, and it is larger than H1–H7: H1…H7 · Hd (handover) · the write gates HW-approve (a shape approved), HW-instance, HW-shared (a shared row), HW-irreversible and HW-ddl (a schema change, D104) · H5-SIM (production simulation, D42/D107) · H5-send (a customer-visible send) · publish (a prompt or skill version made live, D10) · and the customer's own acceptance, CG-11. Each module declares where each gate fires. Hd = handover between modules. Drawn amber; the other diagram states — a signed result, a person deciding on a signed result, a step after the workflow — are Gating § 1b (D148). |
| Waiting (a route) | One of the four outcomes of the desk's route at H2 (D147): the case names its trigger — a step only the customer or an external owner can perform, or a wish deferred to a later release — its clock treatment (Pending pauses both clocks) and its age, visible in the held view; it re-enters the route when the trigger fires (Support Module § 1). |
| Client surface | The customer's own application built from the same case (UI § 5b): its requests, its acceptance, its message box. A request started there is the in place origin (D97, D98); the message box is a door of the surface, not a channel of its own. The product page labels it Serdica UI. |
| Consult | One module asking another for knowledge. The owning domain's profile is spawned as an isolated read-only sub-agent inside the asking case, booted from that domain's AGENTS.md chain with the asking case's grants narrowed to reads; the answer returns as a paper in the asking case, labelled evidence and never authority. Addressed to a domain, never to an agent; depth is one; it holds no write connector, so a consult that needs a write returns "this needs a change in my module". The catalogue is configuration, not architecture (D92). |
| Handover (Hd) | One module asking another for a changed system. The receiving root opens a sub-case with its own stages, gates and writes, behind prior human confirmation. The operator holds the handover right — which is why a client who may only start a support request still gets a code fix (D92, D97). |
| Intake router | platform.intake, the platform profile that owns platform/intake. It normalises the arrival, stamps the origin key, dedups, resolves the customer and checks the initiation right, and opens every client case on support.root — it never names the working module. Naming it is Support's S1 and the route at gate H2 (D143, narrowing D93); the help-desk queue's Configuration default is an S1 classification hint, not a channel route. It always decides, one operator action re-routes and the re-routing rate is a metric; it is not a classifier of severity or clocks (that is the owning module's S1); a mixed arrival is decomposed into one case per module with an explicit ordering. A case started in place by an operator on Configuration or Development is the exception. |
| Initiation grant | intake.initiation per customer × role × module, with three outcomes and no fourth: granted opens the case; may request opens an authorisation request that parks visibly in the Decisions queue; not granted refuses at intake with the contract clause and the commercial path, keeping the description. It governs starting only. Every cell is a plug-in value (D97). |
| Origin | How a request arrived — mail, the ticket system, the customer's help desk, or started in place on the client surface — carried as a field on every client screen, because one case model with four doors is only visible if the door is a field (D98). |
| Write class | The classification of every write by effect class × target class, into seven classes. Only the two scoped-and-working classes (W1 transactional, W2 compensable) may ever auto-confirm; W3 shared-row, W4 irreversible, W5 schema change, W6 customer-facing execution and W7 customer-visible send are always human. A class leaves that set only on a recorded organisational acceptance of the named risk class, per case type and per target — never by the platform's own action and never by a configuration value (D72, D76, N-12). |
| Write shape | A versioned row — operation, template with bound parameters, target and effect class, expected counts as a function of the plan, assertions, derived teardown, permitted case types — immutable once approved at the HW-approve gate. An auto-confirmed write is an instance of an approved shape. An approved shape expires: expires_at = now + writes.shape_expiry_default (P90D), and a holder of the Approver role for the target class may extend it once, by at most P1D (writes.shape_extension_max); an expired shape behaves as suspended, and longer is a re-approval as a new version (D133). One revert suspends the shape for every case type until a person re-approves (D72). |
| Write auditor | platform.write_auditor, the isolated agent that confirms a write may proceed. It receives the packet, the approved shape, the case's grants and read access to the target, and is denied the author's transcript, reasoning and provenance. Four checks: exactness, boundedness, reversibility, scope. It refuses rather than repairs, and it is mandatory for every write, not sampled (D73). |
| Deployer | The agent that turns an approved plan into the deploy request: it emits the script set with its teardown, merges under H4, and records what ran and what the runtime verification found. It does not execute the deploy: the deployment agent resolves the estate's pipeline job by the per-environment rule and triggers it after the gate — H4, and H5 where the target is customer-facing — while DevOps holds the rights and the compose units (D130); estate DDL is applied by the platform's write executor under HW-ddl, the DBA being the holder of rights and the reviewer of the identity path rather than a step in the apply loop (D104). DG-8 keeps code deploys with Ablera DevOps. |
| Root / stage / sub-agent | The agent tree: module root → stage agents → profiled sub-agents (Agents Memory). |
| Connector agent | The per-system agent wrapping that system's tools with environment scoping, logging, and operational knowledge. |
| Grant | A bounded authorization: environment × system × target × mode, issued at case open, bound to the approved artefact, expiring, refused at the connector before contact (Trust and Data). |
| Effect class | Per plan step: transactional (rollback undoes it), compensable (needs a teardown action), irreversible (named before approval), and DDL — which auto-commits, so it carries its own loop: capture-before → preflight on the signature → apply in one call → verify including cross-database dependents → compensate by re-applying the snapshot at H7 (D60, CR-9) (Failure and Recovery). |
| Agent profile | The versioned data that defines an agent: model route, tool grants, memory domains, denied context, escalation, budget, eval set (Agents). |
| Memory domain | A node of the shared memory tree with its AGENTS.md index; agent == domain; writes only within the own domain (the dreaming protocol). |
| Experience index | The support sub-index over resolved cases: symptom signature → mechanism → fix shape. |
| Donor diff | Completeness check of a configured product against a live selling product of the same shape — accounted, never blind-copied. |
| Proof levels | Per-module verification ladder; configuration: structural → priced → reachable → quoted → issued; reports name the level reached (Product Configurator § P, pattern P-13 — a configurator pattern id, not the platform requirement P-13 of the Requirements Register). |
| Golden set | Exported known-good outcomes + their real inputs, used for round-trip evaluation by an isolated grader. |
| getRates | The rating engine's pricing call — computes and stores nothing; the configurator's testing inner loop. |
| KI register | KNOWN_ISSUES.md — open defects/TODOs; a closed ticket does not close its KI. |
| F / P / C | Statement classification: verified fact / decided plan / open challenge (see Home). |
| Protected target | A customer-facing environment (PROD, STAGING/TEST), a customer-visible channel (public Jira comment, mail, transition), or a shared configuration row read by more than one product; writes to protected targets are gated (SG-6, CR-2); the working environment (dev/QA) is not protected — its writes run under the case's grants. |
| Case type | The intake vocabulary that decides a case's initial grants, budget and stage set: Support incident · question · data correction · access · master data · configuration change · CR candidate; Configuration new product · tariff change · packaging change · time-boxed change; Source defect · small extension. Data, extensible per module (Agent Runtime § 11.6). |
| Retention | Configuration per data class, set by the Administrator; default never expires — cases do not expire, and only the customer closes one; the handle map is destroyed at that closure; the ledger is never deleted (Platform Details PG-13, D49). |
| Commercial counterpart | The named person per customer who receives a CR candidate or a §2 offer request with its packet (mechanism, clause, estimate, the customer's words); recorded in the customer plug-in. |
| L1 / L2 / L3 | Support levels: L1 severity 3–4 and known shapes; L2 severity 1–2 or high complexity; L3 a module handover (Hd) or the CR path (Support Details SG-5). |
| Customer representative | The role held by the customer's business user: view a case and give the customer's acceptance where a module asks for it (CG-11); no control, no approval of writes. |
| Configuration value | Any contract clause, calendar, severity scale, identifier pattern, threshold, schedule, host, channel behaviour or role mapping: data with a default in SRD_SUPPORT policy rows or the customer plug-in, never a constant (CR-10, D51); catalogued in the Whitelabel Catalogue. |
| Origin key | Channel plus external identifier — the OTRS TicketID, the Jira key, the mail Message-ID — stamped on every arrival by the connector and checked first by dedup, so a help-desk ticket and its Jira mirror are one case even though reporter and subject differ (Stage Classification § 4; D93, D98). |
| Sign-out document | What a configuration phase ends with, and what the next phase reads instead of the transcript: what was built with counts from the write log, what was tested with its assertions, the proof rung actually reached, what the next phase needs, what is open, and the phase's teardown. It carries a revision; a consumer records which revision it read, so a re-issue makes dependent assertions re-run (D75) (Configuration Module § 1b). |
| Coverage map | The per-object declaration of which write path a configuration object takes — the system's own endpoint, a guarded statement under an approved shape, or the gateway publication sequence — and why; the executor refuses an object with no entry (D74, D136) (Write Envelopes § 1). |
| Curator | support.curator — the only profile that confirms proposals into shared memory; the agent that worked the case writes the entry case-locally and files it as a proposal (D25, D56). Curation itself is an Operator duty per branch of the tree, not a seventh role (D119) (Stage Precipitation § 1). |
| Estate prober | The isolated sub-agent that counts what a target system actually contains: given no product intent, holding a SELECT-only credential, returning counts and never advice, and keeping permitted distinct from used — a value present in two rows out of thousands is reported as such, never as a convention (Components — Configuration § 3). |
| Write executor | platform.write_executor — the only component that writes. Every statement, configuration-endpoint call, gateway publication and UI action runs through it, under the case's grant and past the write auditor, as an instance of an approved write shape; estate DDL too, behind HW-ddl (D104) (Gating). |
| Held batch | Work approved in principle but not yet applied, kept visible with its age and scope. Two states — proposed (a question is outstanding) and approved; an ordered batch is preflighted ordinally, and a batch older than held_batches.repreflight_after (default 7 days) is re-preflighted at application time (D66) (Stage Application § 1). |
| Isolated verifier | support.verifier — given the evidence and the symptom and denied the author's transcript and the case's provenance, it re-derives the mechanism independently; agreement is recorded, and disagreement returns the case to investigation as what evidence separates these two mechanisms. Mandatory before a mechanism reaches the customer or memory, sampled otherwise (default one in five) (Stage Investigation § 3). |
| Solution packet | The one paper a gate holder decides on: the mechanism in one sentence with its layer named and the verifier's agreement, the chosen kind and the rejected alternatives, the exact change with expected row counts, the revert path and effect classes, the replay, what remains uncertain, and the predicted minutes (D135). Presented as the plan at H2, confirmed at H3 (Stage Solution Take § 3). |
| Ledger | The append-only, hash-chained audit record (AUDIT_LEDGER) in SRD_SUPPORT: every gate decision, grant, write, consult, handover and cost entry. It is the audit record, it never expires (D49), and the platform's own numbers are parsed from it rather than scraped (D78) (Architecture § 1). |
| Eval set | The fixtures and their expected outcomes that prove a profile or a prompt before it goes live — deterministic-first grading, graded by an isolated grader that sees two artefacts and no provenance; a version is published only on a green set, and a precipitated skill or article re-runs the sets that depend on it (D66, CR-4) (Agent Framework § 6.5). |
| Handle | The case-local pseudonym substituted for a personal identifier at the connector boundary, before any content reaches a model. The connector exposes structural facets on it — length, prefix, checksum validity, equality with another handle — so a malformed identifier is still findable without the value; there is no stable pseudonym for a natural person, the handle map is destroyed at case close, and re-identification is an audited action (D33, D44) (Trust and Data § 4). |
| Risk class | The named class of risk a write carries. A write class leaves the always-human set only when the organisation accepts that named risk class explicitly, per case type and per target, in a recorded decision; the platform never moves a class itself and no configuration value can, and one revert moves it back (D76, N-12) (Gating § 2). |
| Provenance class | provenance.kind ∈ {spec, system, decision}, carried beside source on every specification line: the customer wrote it, the database settled it (a constraint, a key, a counted convention the estate prober cites), or it was decided here. decision lines are by construction unresolved[] items (D124) (Stage Normalization). |
| Write register | Removed (D64) — v1 is the baseline and the one-time migration source, not a coexistence peer; target collision inside v2 is covered by impact keys (PG-20) (Delivery § 3). |
Premium vocabulary — the term and the column it means
A business reader and a database reader stay in the same conversation only if the word maps onto exactly one column, so the platform uses these terms and names the column beside the term wherever both readings matter. Every row is structural rather than measured; the vocabulary itself is the configurator's F (Requirements § GV).
| Term | Means | Column |
|---|---|---|
| Base premium | the rating table's output, before anything is applied; one row per cover | PREM_TYPE='BASEPREM' |
| Written premium | base premium after loadings and discounts | PREM_TYPE='WRITTENPREM' |
| Loading / discount | an uplift or a reduction — the sign distinguishes them, not the type | LD_TYPE='LD', LD_SIGN ±1 |
| Tax / fee | kept separately from premium; each is refundable or not, first-instalment or spread | LD_TYPE='TAX' |
| Insured value | the sum insured; its currency is the policy currency | the object-value row of type IV |
| Short rate | a non-proportional rate for sub-annual periods — raises short premiums, cuts early refunds | SHORT_AMNT |
| Earned / unearned premium | the elapsed and the remaining parts of the period; unearned = written − earned | computed |
| Write-off | unearned premium; base is the annual premium less non-refundable items | — |
| Refund | unearned paid premium; base is instalments actually paid, less non-refundable items. A different number from the write-off | — |
| Annex | an endorsement. A premium change appends a negative row; it never edits the old one | the policy annex table |
| Deductible / limit | per cover: percent or absolute, aggregate or per event | PR_BASIC_COVER_DEF |
Two rules travel with the vocabulary. Never call either policy administration system "the core" — both are policy administration systems, so name them; Core in this wiki means the router service and nothing else. And show the currency code with every monetary value: amounts are stored in main units, and a bare number in a product document or a customer reply is a defect.
⚠ The source these terms come from is a design intent, not a description of a running system, and it contradicts the live database in at least two places — see Schema Quirks § 8.