AISA v2.0 / Technical documentation / Whitelabel Catalogue
Whitelabel Catalogue
F verified factP decided planC open challenge
Purpose
The platform is whitelabel (decision Vladimir, 02.09.2026 — D51). Bulstrad is its first customer, IPAL support its first use; everything in this wiki that is a contract clause, a calendar, a severity scale, an identifier pattern, a threshold, a schedule, a host, a channel behaviour or a role mapping is therefore a configuration value with a default, never a constant in code and never a rule of the architecture. This page is the catalogue: every such value, its default (the Bulstrad value the other pages state), where it is set, and the page that uses it. A page that states a number states a default and points here (CR-10).
Where a value lives — one of four scopes, all data in SRD_SUPPORT or in the customer plug-in (Software Architecture § 5):
| Scope | Set by | Holds |
|---|---|---|
| Platform policy | Administrator | values true for every customer of the platform: budget thresholds, compaction, seal interval, gate kinds, effect classes |
Customer plug-in (AI.Support.Plugin.<Customer>) |
the customer's plug-in author, published through governance | contract clauses and clocks, calendar, severity scale, identifier patterns, channel behaviours, register rules, environments and hosts, commercial counterpart, role → estate role id |
| Case type | Administrator, per module | initial grants, budget, stage set, SLA class |
| Profile | the profile author, published | route, tools, budget, escalation, eval set (Agents § 0.1) |
1. Contract, clocks and classification — customer plug-in
| Key | Default (Bulstrad) | Used by |
|---|---|---|
contract.sections |
§ 1 Standard (Sev 1–4), § 2 Personalizations (P1–P3) | Stage Classification § 3, Support SG-5 |
contract.response_resolution |
Sev 1 12 h / 24 h · Sev 2 48 h / 5 bd · Sev 3 3 d / 30 d · Sev 4 1 w / 60 d; P1 3 bd · P2 7 bd · P3 15 bd (offer deadlines) | the contract clock |
contract.workaround_downgrade |
§ 1.5.3: an established workaround → Sev 3 | classification |
contract.business_hours |
Mon–Fri 09:00–18:00, Sofia, excluding public holidays (§ 1.6.2, § 2.4.4) | both clocks; PG-22 degraded operation |
contract.out_of_hours_factor |
person-days × 2 | § 2 offers |
contract.rates_per_role |
the § 2.4.3 daily rates; the § 2.4.1 envelope (600 person-days/year) | § 2 offer deadlines (P1–P3) |
clocks.channel_clock |
Jira SLA as configured on project SD |
Stage Classification § 3 |
clocks.pause_states |
Pending | both clocks pause |
gates.escalation_intervals |
Sev 1 30 min → 2 h · Sev 2 2 h → 8 h · others next business day | Platform Details PG-12 |
gates.auto_confirm |
per case type × gate × target class; conditions and the suspension rule per Gating § 1 (D70); never on the always-human gate kinds of Gating § 1 | Gating § 1 |
writes.target_classes |
which rows and environments count as working, shared, customer-facing, external and customer-visible — the shared-row set is the customer's impact_keys.shared_rows (D72) |
Gating § 2 |
writes.always_human |
default human set: W3 shared · W4 irreversible · W5 DDL · W6 customer-facing · W7 customer-visible; ordinary plug-in edits may only strengthen it. A matching organisational RISK_ACCEPTANCES record is the separate exception path | Gating § 3 |
writes.shapes |
the approved write shapes per customer: operation, template, classes, expected counts, assertions, teardown, permitted case types, state | Gating § 4 |
configure.endpoint_coverage |
per configuration object, which of the three write paths applies — the system's own endpoint · a guarded statement under a shape · the gateway publication sequence — and why (D74, D136); the same map is the skill manifest's coverage_map |
Agents Memory and Skills § 10, Write Envelopes § 1 |
configure.responsibilities.translations |
which stage holds the translation sweep — default configuration.serdica.stage; the verifier re-runs the same skill read-only at H3 (D137: a responsibility, not a stage) |
Translations |
contracts.inter_stage.mode |
draft — the platform validates the required core of an inter-stage paper and accepts the open body; a stage may extend a paper per case and record the extension in its sign-out (D139) |
Contracts § 2 |
support.levels |
L1 = Sev 3–4 and known shapes; L2 = Sev 1–2 or high complexity; L3 = handover or CR | Support Details SG-5 |
support.commercial_counterpart |
a named person per customer | Support SG-11 |
2. Channels and customer-visible behaviour — customer plug-in
| Key | Default (Bulstrad) | Used by |
|---|---|---|
channels |
Jira ablera.atlassian.net project SD; shared mailbox servicedesk@ablera.com (Inbox only); HelpDesk OTRS hdesk.bulstrad.bg; started in place on the client surface (D98) |
intake, Stage Classification § 1 |
channels.authoritative |
the channel the customer speaks on; mirrors are projections | dedup, Stage Classification § 4 |
channels.closure |
closure via Pending; the customer closes (closure rule) | Stage Application § 4, PG-13 |
channels.internal_note |
one internal note per ticket, === AISA INTERNAL === marker, Internal Tag names the person |
communicator |
channels.ignore_senders |
zabbix@…, monitor@…, noreply@hdesk…, MSSecurity-noreply@… |
mail connector |
register.language_rules |
Bulgarian register: no Russianisms, „…“ quotes, full name „Булстрад Живот“, product names from HT_INSR_TYPE |
communicator prompts |
monitors.schedules |
Jira JQL sweep, mailbox scan, HelpDesk queue — intervals per channel | Agent Runtime § 11.6 |
3. Personal data and identifiers — customer plug-in
| Key | Default (Bulstrad) | Used by |
|---|---|---|
pii.identifier_patterns |
ЕГН (10 digits with checksum), ЕИК, VIN, policy and claim numbers by prefix, IBAN | handle substitution, Trust and Data § 4 |
pii.name_surfaces |
the policyholder and insured surfaces used to detect customer names in free text | CG-9 refuse-list, Stage Normalization |
pii.staff_roster |
Ablera IT and Bulstrad staff who are not anomalies in configuration intake | CG-9 scope |
pii.special_categories |
health data — product 8000 / ДЗО | data classes |
data_boundary.allowed_routes |
Support: EU-resident, DPA-covered only; Configuration: any estate-approved route compatible with the actual material; Development (id source): as Support with real data |
Agents § 0.3 |
retention.per_class |
case papers and ledger never expire; handle maps die at case close; special-category evidence defaults to the contract term; manual erase/anonymise/extend/export are gated writes (D109) | PG-13, Trust and Data § 4 |
4. Estate and environments — customer plug-in
| Key | Default (Bulstrad) | Used by |
|---|---|---|
environments |
PROD · TEST/STAGING (serdicastaging) · QA · Ablera DEV, with the branch each runs and the default per module (Support PROD; Configuration and Development per environments.paths — the working → target path per product line, D123, generalising source.start_flows: existing PAS products local → bulstrad-staging → PROD, port master → bulstrad-qa; health line QA → master, target the planned bulstrad-prod-2) |
Software Architecture § 10.3, environment defaults |
environments.<env>.customer_facing |
Bulstrad defaults: STAGING/TEST true, PROD true, QA false (D114) | Gating § 1, Software Architecture § 10.3 |
platform.host |
the control plane's placement (D63) — Bulstrad: one deployment on the QA compose host, reaching every environment through connectors | Software Architecture § 10.1 |
source.start_flows |
running-product: local → bulstrad-staging → master + bulstrad-qa → prod scripts · new-product (the health line): bulstrad-qa → backport to master → the planned bulstrad-prod-2 (D63; per product line and shared with the Configuration module's working environment — D123) |
Development Details DG-2, Stage Planning § PL-3 |
connectors.reach |
per target per environment: direct · unreachable (probe result; no tunnel, no via host — D132) |
CONNECTOR_SCOPES (D46, D132) |
connectors.hosts |
the DB, broker, Kibana, BI Publisher, LDAP, OSB addresses of the estate | connectors |
connectors.session_caps |
INSIS SESSIONS_PER_USER = 6 per account; IPAL per DBA profile |
budgets |
connectors.identities |
SRD_SUPPORT; AISA_RO per environment; ABLERA_SUPPORT, ABC_ACCESS; the Jira service account; the mailbox app registration |
Software Architecture § 10.4 |
impact_keys.shared_rows |
LT_LD_CODES, SR_MESSAGES, global factor values, LB_OBJECT_NA, the engine cache |
Configuration Module § 3 |
deployment_sets.presets |
rating only (phase 1) · rating + product (phase 1 + 2B) · full (phase 1 + 2A + 2B) — D75 | Configuration Module § 3 |
sources |
the Development module's (id source) declared systems per customer (D58): repositories, DB side, branch model + start flows (source.start_flows), seam catalogue, build/test gates, deploy mechanism — Bulstrad: serdica-backend, serdica-ui, intentgpt, the env DBs' PL/SQL (the BPMN files live in serdica-backend and belong to the backend implementer) |
Development Module, Stage Planning |
products.families |
the optional configuration families asked per product family (commission, reinsurance, BSO, questionnaire, claims) | Stage Serdica § Challenges |
roles.estate_role_ids |
the six platform roles → the estate's role ids in SRD_SYS.LT_USER_ROLES (Bulstrad: AISA_VIEWER · AISA_OPERATOR · AISA_APPROVER · AISA_PROMPT_PUBLISHER · AISA_ADMIN · AISA_CUSTOMER_REP), delivered as role claims by Authority from USER_ROLES — replaces roles.group_mapping (D97 → D134): roles are platform rows, not directory groups |
Trust and Data § 3 |
roles.gate_holders |
H5-SIM: Ablera support lead + Bulstrad system owner per system (D107) | Gating § 1, Failure and Recovery § 5 |
write_register |
removed (D64 — v1 is baseline + migration source only, no coexistence machinery); target collision inside v2 is covered by impact keys (PG-20) | Delivery § 3 |
graphs.stage_sets |
the modules' agent graphs as data — stage sets, profiles and their wiring per module, instantiated as TASKS from the profile catalogue (D67) |
Agents, Agent Runtime § 3 |
memory.domains |
the memory tree's domain skeleton as rows (D67); content is governed by the promotion rule, structure is configuration | Agents Memory |
sla.protocols |
the contract clocks, escalation intervals and business-hours calendars as policy rows (D67) — the Bulstrad set of § 1 | Stage Classification § 3, PG-12 |
5. Runtime, budgets and thresholds — platform policy
| Key | Default | Used by |
|---|---|---|
budget.dimension |
minutes — the only budget dimension (D135): a case budget is its predicted delivery time, a task budget its share of it; tokens/turns are usage facts; context/output limits and estate/provider/session caps remain technical constraints separate from the time budget |
Agents § 0.1, Agent Runtime § 2 |
budget.soft_warning / budget.hard_stop |
80 % / 100 % of the task's minutes | Agents § 0.1, Agent Runtime § 2 |
budget.per_role |
the starting time shares of Agents § 6 | case budgets |
budget.case_default_minutes |
per case type (CASE_TYPES.BUDGET_MINUTES): the prediction at classification replaces it per case; where two sources predict differently the maximum stands (D135) |
Stage Classification, case budgets |
writes.shape_expiry_default / writes.shape_extension_max |
P90D from approval (D133) · the approver may extend an approved shape once, by at most P1D — the rule of A-9 | Gating § 4 |
escalation.failed_attempts |
2 | profiles |
compaction.threshold / compaction.retain |
80 % of the window / the summary plus the last N turns; tool-result pruning at 8 k chars → 4 k head / 1 k tail | Agent Runtime § 6 |
verifier.tiers |
mandatory for customer-facing mechanisms and memory writes and the first three cases of a shape; sampled for known shapes — proposed 1 in 5, not yet sourced | Stage Investigation § 3, SG-10 |
write_auditor.tier |
mandatory on every write, never sampled (D73) — its cost is queries and a template comparison, not a re-derivation | Gating § 6 |
precipitation.ladder |
3 / 7 / 20 occurrences | Stage Precipitation § 2 |
held_batches.preflight_sampling / held_batches.repreflight_after |
ordered batches preflighted ordinally; others per item · a batch older than 7 d is re-preflighted at application time, from the first unapplied item (D66) | Stage Application § 1 |
grants.expiry |
at case close or a fixed wall-clock, whichever first; proposed 4 h for a write grant, 7 d for a read grant | Trust and Data § 2 |
grants.iteration_window |
same object set, same day | Trust and Data § 4 |
simulation.exemption_test |
the five items of Failure and Recovery § 5 | simulation |
simulation.production_criteria |
the five criteria and the H5-SIM roles — Ablera support lead + Bulstrad system owner per system (D107) |
Failure and Recovery § 5 |
ledger.seal_interval / ledger.export_interval |
15 min / 15 min off-database (D45) | Architecture § 3.2, Delivery § 4 |
roi.switch_cost_share |
20 % of the ticket's handling time (D53) | Value and ROI § 1 |
roi.agent_time_adjustment / roi.human_time_adjustment |
−25 % / +25 % on the archive figures until the stopwatch measurement replaces them (D54) | Value and ROI § 2b |
roi.unit |
hours; human effort is never monetised; provider usage is a control, not a metric (D117) | Value and ROI, Metrics |
roi.human_minutes_per_ticket |
30 — the planning average of human time per ticket for non-agent work (D69); replaced per type by the stopwatch protocol, then by the ledger | Value and ROI § 1 |
nfr.targets |
20 concurrent cases (50 ceiling); gate round-trip < 2 s; transcript lag < 5 s; ledger RPO ≤ 15 min; case RPO ≤ 1 h; RTO 4 h; quarterly restore test — durability targets conditional on D45 (QA backup restored first) | Delivery § 4 |
kill_switch.mode |
off / soft / hard; Administrator controls live state checked at case admission and every effect dispatch | PG-18 |
eval.batching |
per domain, on a schedule and before publish | Agent Framework § 6.5 |
memory.promotion_rule |
case-local → proposed at filing → active on confirmation (human review, or two independent uncontradicted uses — the initial rule, measured on the migrated corpus before it is relied upon) | Agents Memory § 7.4b, Agents Memory § 2 rule 7 |
summarizer.node_cap / summarizer.refresh |
proposed 300 lines / 5 articles; refresh at 50 commits or 90 days | Agents § 0.6 |
metrics.targets |
defaults point to Metrics § Baseline → target; re-baselined by the ledger after the first ten cases of its kind (D111) | Metrics |
ui.transcript |
reference payloads; proposed pages of 200 and ≤ 10 notifications/s — neither number is stated on the UI page yet | UI § 8 |
5b. Inter-module traffic — platform policy
| Value | Default (Bulstrad) | Set where | Used by |
|---|---|---|---|
consults.catalogue |
the catalogued question→domain rows — the platform row on Agents § 5, the module rows in each module's what it asks of the others section (Support Module § 3, Configuration Module § 4b, Development Module § 2b) | platform policy | every root and stage agent |
consults.depth_max |
1 — a consulted profile may not consult onward | platform policy | the framework, when it spawns a consult |
budget.consult_concurrency |
2 — the slice of a consultable profile's capacity reserved for answering other agents' consults; stage work cannot consume it, and it stays a cap, never a budget dimension (D135) | platform policy | Agents § 0.1; the consult queue (Agents § 5) |
consults.budget_share |
10 % of the asking case's budget, all consults together | platform policy | Agents § 6 |
handovers.directions |
the four Hd directions of Agents § 5 | platform policy | the module roots |
intake.routing |
per channel × shape × customer — every client channel opens on the Support root; the help-desk queue's configuration request default is a classification hint the desk's S1 reads (D143 narrows D59, D93) | customer plug-in | platform.intake, Support Module § 0 |
intake.low_confidence_flag |
on | platform policy | platform.intake, the Inbox brief |
intake.initiation |
per role × module: Customer representative → support start, configuration request, development none; operator → support and configuration start | customer plug-in | platform.intake (Trust and Data § 3b) |
intake.origins |
ticket system · mailboxes · help desk · in place (the client surface) | customer plug-in | platform.intake, the case's origin field |
routes.waiting_triggers |
customer step · external-owner step · deferred wish — each with the pause state it maps to (clocks.pause_states) and the trigger that re-enters the route |
customer plug-in | the route (Support Module § 1–2, D147) |
intake.approver_notify |
the customer's own approver, where the plug-in names one | customer plug-in | the authorisation request |
6. Case types — per module, Administrator
| Module | Types (default) | Each carries |
|---|---|---|
| Support | incident · question · data correction · access · master data · configuration change · CR candidate | initial grants (read on the default environment), budget, SLA class, stage set |
| Configuration | new product · tariff change · packaging change · time-boxed change | working environment, deployment-set preset, stage set |
Development (id source) |
defect · small extension · process change · operations action | start flow (source.start_flows), branch set template, test plan template |
7. Rules
P Storage and precedence. POLICY_VALUES is the versioned source for this catalogue. Match the exact customer/module/case-type/profile context, resolve profile > case_type > customer > platform for ordinary defaults, and record the selected row ids/hashes in the case/request snapshot. Reject equal-specificity ambiguity. Safety ceilings, deny rules and current revocation compose restrictively; a more specific ordinary value never grants a risk acceptance or removes an estate credential boundary. CASE_TYPES carries the initial grant/stage/gate variant; MODEL_ROUTES and PROFILES are governed references, not strings interpolated into an endpoint.
P Module manifests. modules.
P A value in this catalogue is read from configuration at case open (case-type and customer values) or at publish (profile values); a change to a customer value is a governed change of the plug-in, not a code release. The wiki's pages state the Bulstrad defaults so that a reader sees a concrete number; a second customer changes the plug-in and none of the pages.
P The catalogue is maintained like the register: a page that introduces a new number, name or schedule adds the row here in the same change.
Challenges
- P Completeness — this first version lists what the pages state today; the build of the first plug-in finds what was still a constant.