Measurements — 02.09.2026

Everything the platform's design cites as a measured fact was taken on 02.09.2026, in five passes over five different sources, plus a sixth pass — § CE, the case census — taken on 07.09.2026. This page holds all six. Each section states its own source, its method and its date, so a figure can be re-taken rather than trusted; where a later pass superseded an earlier one, the earlier one says so and stays.

Section ids are stable. A reference is written § DB-1a, § RE-5, § TT-2 — the prefix names the pass, so inserting a measurement never renumbers an existing one. The CH ids that appear in the DB and RE sections are the register ids of 02.09.2026 and do not resolve against today's Challenges Register.

TM. The ticket archive — 485 Jira tickets

Measured 02.09.2026 over C:\dev\aisa-poc\jira_tickets\ — 485 unique tickets (514 directories → 485 keys after merging duplicates; 2 empty directories dropped). Scripts: scripts/mine_tickets_extract.py (→ tickets.csv, tickets_full.json) and scripts/mine_tickets_classify.py.

The per-ticket table that used to close this pass was raw archive data cited by nothing; it is regenerable from the two scripts above and has been removed. The HDesk and e-mail counts of § TM-8 were superseded the same day by a full read of the two archives — Challenge Rounds § R2-1 — which reclassified them.

TM-0 Method

1. Newest Jira JSON snapshot per ticket dir (412 tickets); 73 older dirs have only the analysis HTML, whose header table supplied key/summary/status/created/priority (reporter mostly missing there). Duplicate dirs for one key merged (newest snapshot wins; any HTML wins).
2. Request type = ordered keyword rules (BG+EN) over summary + description, tuned after reading headings/internal notes of 40 analysis HTMLs spread across the range; contract class / severity / L-level regexed from the HTML classification block (322 of 332 HTMLs have one).
3. Skill candidates counted as union of a request-side regex (summary+description) and an analysis-side regex (technical tokens in the HTML); effort class inferred from analysis size + comment count (see caveats).

TM-1 Request-type distribution

Resolution days are available only for tickets carrying a Jira resolutiondate (Completed/Closed/Canceled/Done). Most fixed tickets are parked in Pending (customer's turn) without a resolutiondate, and the JSON snapshots were taken at investigation time (usually the creation day), so no reliable time-to-fix exists for them; the two right-hand columns give the counts instead.

TM-1a Request type per year-month

TM-2 Monthly volume (created)

The archive is not the full SD project: it holds the tickets AISA worked on. 2025 rows are sparse (mostly re-opened/related cases); coverage is dense from 2026-03 on.

TM-3 Status distribution (newest snapshot; HTML-only tickets show status at analysis time)

TM-4 Contract classification found in analysis HTMLs

Of 332 tickets with an analysis HTML: contract section {'(none)': 17, '§1': 296, '§2': 19}; severity {'(none)': 119, 'Sev 2': 16, 'Sev 3': 151, 'Sev 4': 43, 'Sev 1': 3}; personalization level {'P3': 9, 'P2': 13}; support level {'(none)': 15, 'L1': 113, 'L2': 204}.

TM-5 Skill candidates (sorted by count)

Count = tickets whose summary/description match the request-side regex (what the customer asked for) — the conservative figure. Analysis mentions = tickets whose analysis HTML contains the technical tokens of that operation (how the fix was done); it exceeds Count when the operation is a means rather than the request (e.g. retransfer after a data fix). Effort class = modal inferred class over the request-side set, with distribution T/R/I/M = trivial / routine / investigation / multi-day. Example keys = lowest-numbered request-side matches (analysis-side for the two analysis-only rows).

Seed items with fewer than 5 matches are still listed so the absence is visible. "Jira conversation" and "Kibana trace" are analysis-side only (they describe how a ticket is worked, not what was asked). Existing workspace skills already cover: add-car, add-bso, add-agent, print-policy, check-transfer, sync-framework, person-policies, analyze-policy, classify-ticket, investigate-ticket, jira-access, configure-product.

TM-6 Top reporters (only 4 distinct reporter accounts exist in the archive; the shared ServiceDesk account files OTRS-transferred tickets)

TM-7 DB-write share (proxy for data-correction load)

• Analysis HTMLs containing an SQL block that starts with UPDATE / INSERT INTO / DELETE FROM / MERGE INTO: 219 of 332 analysed tickets (66%), i.e. 45% of all 485 tickets.
• By request type (share of analysed tickets with a DB write):
• incident/defect: 29/52 (56%)
• question/how-to: 4/10 (40%)
• data correction: 75/106 (71%)
• transfer/sync failure IPAL<->INSIS: 57/79 (72%)
• access/account: 30/35 (86%)
• master data: 9/13 (69%)
• configuration change: 14/20 (70%)
• report/extract: 0/1 (0%)
• CR candidate/new feature: 0/13 (0%)
• other: 1/3 (33%)
• Caveat: the SQL block may be proposed (for Bulstrad-IT / an operator to run) rather than executed by ServiceDesk; the regex does not distinguish. Verification-only analyses (SELECT only) are the complement.

TM-8 HDesk (OTRS) cache and e-mail threads — titles only, superseded

Superseded by Challenge Rounds § R2-1, which read every hdesk/*/metadata.json and every THREADS.md heading instead of titles and reached different numbers: 39 of the 52 HDesk tickets are Configuration-module intake (not 20+4), and the OTRS support stream is 30 of the 38 mail threads. The title-level pass is kept because it is what the counts on this page were computed against.

• hdesk/: 52 cached OTRS tickets. Title-only classification: configuration change (product spec) 20, other 11, CR candidate/new feature 7, configuration change 4, incident/defect 4, data correction 2, transfer/sync failure IPAL<->INSIS 2, master data 1, access/account 1. These are predominantly product-configuration/CR requests from Bulstrad product owners (3602/3607/3618/3636/4727/2200-2222 tariff and cover changes), i.e. the /configure-product shape, plus a few „куха полица" sync cases.
• emails/THREADS.md: 38 thread headings. Recurring shapes by title: VIN/рама correction requests 9, куха полица / stuck transfer / sync 6, ИП office / broker onboarding 5. The VIN-correction stream (HelpDesk-originated, e.g. Ticket#00099850_VIN_correction_BG_03_126001300229) rarely becomes a Jira ticket, so the Jira count under-represents it.

TM-9 Caveats (what the heuristics miss)

• The archive is AISA's working set, not the whole SD project; ticket volume per month reflects what was investigated, and 2025 is under-sampled.
• Request type is a first-match keyword rule; a ticket asking for a correction because of a defect lands in "data correction" while the root cause is a defect — the two classes overlap heavily (most data corrections are consequences of transfer defects).
• Bulgarian morphology is handled by stems only; typos in summaries („гтрансфер", „посрдедник") and pure policy-number summaries fall through to description rules or to "incident/defect" by default.
• Skill-candidate Count is the request-side regex only (summary+description) and under-counts requests phrased as a bare policy number; the Analysis-mentions column over-counts because deep analyses mention many subsystems (PREM_INST, ABACUS, EISOUKR, Kibana) even when the fix lay elsewhere.
• One ticket can match several candidates (e.g. a MYR case is also a transfer case); the candidate table is not a partition.
• Effort class is inferred from analysis HTML size and comment count; the v2 analysis template is ~45 KB even for a trivial fix, and 155 tickets have no HTML at all (effort then rests on comment count alone). Real hours were not recorded.
• Contract class/severity/level come from a regex over the HTML classification block; retrofitted v1→v2 analyses (SD-1442…SD-1622) often have a placeholder block, so §/Sev may be absent or defaulted.
• Resolution time uses Jira resolutiondate, present only for Completed/Closed/Canceled; Pending tickets (the majority of fixed ones) carry none, and snapshot updated dates equal the fetch day, so median resolution is measured on a 175-ticket subset biased toward tickets the customer explicitly closed.
• 73 HTML-only tickets (Mar–Apr 2026) lack reporter and comment count; "(missing)" in the reporter table is that gap, not an anonymous reporter.
• HDesk and email streams were classified by title only; a substantial VIN-correction and framework-onboarding stream lives there and never reaches Jira, so Jira-only counts under-state those two skills.

TT. Agent time against the human estimate

Measured 02.09.2026 13:56 over C:\dev\aisa-poc\jira_tickets (485 ticket keys, 512 directories). Script: scripts/mine_tickets_timing.py, data: ticket_timing.csv.

Read with D54: the flat 25 % rule below was later adjusted — agent time down 25 %, the person's time up 25 % — until a stopwatch measurement replaces both, and times vary by domain and by person. Hours are the unit; no figure here is money (D52, D79).

TT-0 Method

Per ticket key (dirs SD-<n> and SD-<n>_<slug> merged; git history keyed by jira_tickets/SD-<n> path so renames are followed):

• (a) snapshot_ts — earliest SD-<n>_ticket_<ISO>.json filename timestamp = moment AISA fetched the ticket.
• (b) first/last commit, n_commits — git log --name-only -- jira_tickets, aggregated per key. Repo history starts 2026-04-10; two operator machines merge via git, so commits are batched.
• (c) mtime_min/max — filesystem mtimes; flagged below as unreliable.
• (d) AISA timeline stamps — first <td> of tr.timeline-aisa-internal|response rows in the analysis HTML; formats YYYY-MM-DD[ HH:MM[:SS]], DD.MM.YYYY[ HH:MM], DD.MM HH:MM, bare HH:MM (date taken from the snapshot). Date-only stamps are recorded but not used for elapsed (no time of day). Jira fields.created from the JSON is also kept.
• agent_elapsed = (d) last time-bearing AISA stamp − (a) snapshot; else (b) first commit at/after the snapshot − snapshot (the commit that landed the analysis; the last commit is dominated by later bulk edits — retrofits, finalize_analysis re-runs — so lastcommit_minus_snapshot_h is reported as a column but not used); else last − first commit. agent_time = agent_elapsed + 0.25 h operator overhead. elapsed_reliable = timeline-based, or commit-based with elapsed ≤ 24 h (a later commit means the analysis was committed in a batch, not when it was finished).
• active_h — events = commits + snapshot + time-bearing AISA stamps, clustered with gap > 4.0 h; sum of cluster windows (a lone event = 0 h). Separates elapsed from active work but is a lower bound (a single-commit session shows 0).
• human_est_h — sum of the hours column of the role × hours × rate table in the aspect-financial card (header Часове/Дни/Човеко-дни sets the unit; cell units ч/h/MD/чд/ден/мин override; 1 day = 8 h; total/colspan rows skipped). human_true_h = 0.25 × human_est_h. fin_check compares hours against amount/rate×8 per row (ok if every row within ×0.5–×2).

TT-1 Source availability

Elapsed source used: firstcommit_after-snapshot=301, timeline-snapshot=111, lastcommit-firstcommit=71, none=2. Financial card source: table=230, none=186, placeholder=48, text-only=18, table-unparsed=3. Financial check (hours vs amount/rate): ok=194, na=33, mismatch:3/3=2, mismatch:3/5=1. Timeline stamp cells: 330 rows, 181 with time, 108 date-only, 41 unparsed (—, "re-analyze", etc).

TT-1a mtime reliability

mtime_min collapses onto a few dates: 2026-07-17 (147), 2026-05-19 (55), 2026-08-28 (41) — top-3 dates cover 50% of 483 dirs. These are checkout/merge dates, not work dates → mtimes are not used in any estimator.

TT-1b Commit batching

n_commits per ticket: 0: 2, 1: 181, 2: 81, 3: 116, 4: 72, 5+: 33. Most common first-commit dates: 2026-08-28 (47), 2026-08-03 (43), 2026-07-24 (36), 2026-04-10 (32), 2026-08-21 (26) — the first ones are bulk imports of pre-existing analyses, so first_commit is not a start time for them.

TT-2 Distributions (hours)

agent_time_h — why the all-tickets figures are not the measurement

Over all 483 tickets with a computable elapsed, agent_time_h has an ALL median of 76.9 h and a mean of 1 497 h. Those are commit-batching artefacts: 301 of the 483 take their elapsed from a commit, and many analyses were committed in bulk days or weeks after the work. The subsets below are the measurement; elapsed_reliable is the filter.

agent_time_h — RELIABLE subset (timeline-based, or commit ≤ 24 h after snapshot)

agent_time_h — only tickets whose elapsed came from AISA timeline − snapshot

timeline_span_h — the span between the first and last AISA stamp

Over the 43 tickets carrying two or more time-bearing stamps: median 0.95 h, p25 0.31, p75 1.77 (the mean, 11.3 h, is one 43-hour incident row). This is the agent's own working span within a ticket and is the comparator Challenge Rounds § R2-10 names for the switch-cost measurement — never elapsed.

lastcommit_minus_snapshot_h — not used

The naive "last commit − snapshot" estimator gives an ALL median of 836.8 h over 412 tickets, because bulk retrofits and finalize_analysis re-runs later touched every directory. It measures the archive's edit history, not agent time, and no figure on this page or in Value and ROI is derived from it.

active_h is 0 for 325 of 485 tickets (single commit + snapshot more than 4.0 h apart → no measurable window).

active_h (clustered work windows) — tickets with active_h > 0

human_est_h (analysis author's own estimate)

human_true_h (= 0.25 × human_est_h)

Ratio human_true_h / agent_time_h (tickets with both)

Also the ratio of medians (median human_true / median agent_time) is shown implicitly by the last two columns; the median of per-ticket ratios is the more robust figure.

TT-3 Ten example tickets (all columns)

TT-4 Financial-table parsing — the day-rate examples are removed (D79)

The five raw parse examples that closed this section quoted the analyses' own role × hours × day-rate tables in full, with the sums in currency and two revenue-impact figures. Money is not a metric of this platform (D52, D79) — no figure on any page is expressed in currency — so the examples are gone. What they demonstrated is already measured above: the parser's own cross-check of hours against amount ÷ rate passed on 194 of 230 parsed cards, failed on 3 and was not applicable on 33. Only the hours column of those tables is used; human_est_h is the sum of it.

TT-5 Caveats

• Elapsed ≠ effort. agent_elapsed is wall-clock between fetch and last AISA stamp/commit; the operator may have been away, or the ticket may have been re-analysed days later (multi-day elapsed values). active_h is the opposite bias (lower bound).
• Commits are batched across two machines and merged; many analyses were committed in bulk (see first-commit dates). Commit-based elapsed is only trustworthy where the snapshot exists and the last commit is close to it.
• mtimes are reset by checkouts/merges — reported in the CSV but excluded from all estimators.
• AISA timeline stamps are written by the analysis author (the agent), sometimes date-only or HH:MM only; bare HH:MM is assigned to the snapshot date.
• human_est_h is the analysis author's own number (the agent wrote the financial card), scoped to the fix as the author saw it (sometimes includes development + testing of a CR, sometimes only L1 diagnosis). It is not an independent human estimate. human_true_h applies a flat 0.25 factor (Vladimir's rule of 02.09.2026); D54 then adjusted it to about 0.31 and stated that the medians are the shape of the comparison, not a number for any one ticket.
• Tickets analysed before the repo existed (2026-04-10) have no meaningful git start; tickets without a snapshot JSON (legacy v1 dirs) fall back to commit deltas.

TB. Triage baseline — v1 retrieval on held-out tickets

The number the memory tree has to beat. Measured 02.09.2026 by scripts/triage_baseline.py: grep over v1's flat memory — the 563 MEMORY.md one-line descriptions plus the 56 KNOWN_ISSUES.md headings, 619 index lines in all — asked to find the reference article or known issue that a resolved ticket's own analysis actually cited. Truth = the articles and KIs named in that ticket's analysis HTML. Three figures come out of it: hit-rate 10 %, false-precedent rate 98 %, 7 of 30 tickets return nothing.

This is a baseline, not a verdict on the articles: 548 v1 files exist and are individually good; what fails is retrieval over one-line descriptions. The measurement is the acceptance test of the migration — re-run the same script on the same held-out set against the tree.

TB-0 Protocol

• Corpus: jira_tickets/SD-*/ directories holding both a ticket JSON snapshot and an analysis HTML — 267 such directories; 216 resolved (newest snapshot statusCategory = done, or newest snapshot older than 2026-08-01 and presumed resolved since, marked *); 194 of them name at least one precedent.
• Query = the ticket as it arrived: fields.summary + fields.description (ADF flattened) from the oldest snapshot.
• Index = what v1 memory offers a grep: the 563 memory/MEMORY.md one-liners (title + hook + file stem) plus the 56 KNOWN_ISSUES.md ## KI-### — title headings = 619 lines.
• Truth: the memory/reference/*.md articles and KI-### ids the ticket's analysis HTML cites (feedback/methodology articles excluded — they are not precedents).
• Retrieval: grep-style token overlap — query tokens ≥ 3 chars, stop-words removed, ids > 6 digits dropped, IDF-weighted sum over shared tokens, top 5.
• Hit = any truth item in the top 5. False-precedent rate = share of the 30 × 5 = 150 possible slots not filled by a truth item — the denominator is the possible slots, not the returned ones, because 7 tickets return nothing and several return fewer than five. Sample: 30 tickets, round-robin over ten request-type buckets (access, BSO, transfer, framework, cargo correction, print, premium, product configuration, annex, other), newest first.

TB-1 The numbers, and the thirty tickets

hit-rate (truth in top 5) : 3/30 = 10% top-1 correct : 1/30 = 3% false-precedent rate (noise slots): 147/150 possible slots (30 x 5) = 98% tickets with empty result : 7/30

DB. Database evidence — Bulstrad QA, STAGING and PROD

All statements SELECT-only over the SQLcl MCP; every subsection carries the queries that produced it, so a re-measurement is a re-run. Page names are today's; the pages these findings were written against were renamed and merged on 03.09.2026 (D88, D94, D96).

Connections used and what they are:

QA host ablera-db-actuary is the same database the wiki's 01.09 cadence measurement names, so the QA comparison is like-for-like. The QA session ran as SRD_CUST, not SRD_INTEGR; every SRD_IPROD.* and dictionary query resolved, so nothing below is gated by that.

"dev" columns quote the Ablera dev numbers as written in the pricing-factor model, now Stage IPAL § PF-8b (76 products / 2,511 / 4,660 / 16,400; POL 2,261 vs QT 250; 23 products with QT; 170 dual-stage factors).

DB-1 Pricing-factor distribution — QA vs dev vs STAGING vs PROD

DB-1a Headline counts and stage split

SELECT 'products' k, COUNT(DISTINCT product_code) n FROM srd_iprod.pr_pricing_factors
UNION ALL SELECT 'factor_rows',    COUNT(*) FROM srd_iprod.pr_pricing_factors
UNION ALL SELECT 'value_rows',     COUNT(*) FROM srd_iprod.pr_pricing_factor_values
UNION ALL SELECT 'dependent_rows', COUNT(*) FROM srd_iprod.pr_pricing_factor_dependent
UNION ALL SELECT 'stage_'||sale_stage, COUNT(*) FROM srd_iprod.pr_pricing_factors GROUP BY sale_stage
UNION ALL SELECT 'products_with_QT', COUNT(DISTINCT product_code) FROM srd_iprod.pr_pricing_factors WHERE sale_stage='QT'
UNION ALL SELECT 'factors_both_stages', COUNT(*) FROM (
  SELECT product_code, NVL(object_code,'~'), NVL(cover_code,'~'), pricing_factor_code
  FROM srd_iprod.pr_pricing_factors
  GROUP BY product_code, NVL(object_code,'~'), NVL(cover_code,'~'), pricing_factor_code
  HAVING COUNT(DISTINCT sale_stage)>1);

Note: the dependency table is PR_PRICING_FACTOR_DEPENDENT (not _DEP); dev's 16,400 is well below every Bulstrad environment.

DB-1b Products using QT (QA only — the other two have none)

SELECT product_code, COUNT(*) qt_rows FROM srd_iprod.pr_pricing_factors
WHERE sale_stage='QT' GROUP BY product_code ORDER BY 2 DESC;

QA: 4704 (40), 4710 (33), 3407 (24), 1126 (20), 3618 (15), 2215 (14), 2214 (13), 2227 (13), 2204 (6), 1116 (2), 3615 (1), 3801 (1), 4716 (1), 4723 (1), 4728 (1), 4800 (1). Dev's top QT product 9951 (40 rows) does not exist on QA at all (0 factor rows for product 9951); 4704 is 40 on QA vs 52 on dev.

FINDING. The QT/POL split the page measured on dev is a development-database artefact. On the customer's STAGING and PROD the estate is 100 % POL — no QT row, no dual-stage factor, on any product. QA sits in between (16 products still carrying 186 QT rows). The "size of the obsoletion work" is therefore 186 rows on QA and zero on the two customer environments; the question "would any of the 53 POL-only products break if a quote step were added" is moot for STAGING/PROD, which have never carried a QT row.

Resolution. CH-11 → F Re-measured 02.09.2026 on Bulstrad QA/STAGING/PROD: STAGING (1,992 factors) and PROD (1,977) carry SALE_STAGE=POL only — zero QT rows, zero dual-stage factors; QA carries 186 QT rows over 16 products (4704 40, 4710 33, 3407 24 …). The dev distribution (250 QT / 23 products / 9951) does not describe the customer estate; 9951 is absent from QA. CH-17 gains a data point: the QT obsoletion is already the data state on the target branches' databases (STAGING and PROD), whatever the code state is — confirm the code side separately.

DB-1c Column distributions

SELECT * FROM (
 SELECT 'DATATYPE' col, NVL(datatype,'<NULL>') val, COUNT(*) n FROM srd_iprod.pr_pricing_factors GROUP BY datatype
 UNION ALL SELECT 'VALUE_SOURCE', NVL(value_source,'<NULL>'), COUNT(*) FROM srd_iprod.pr_pricing_factors GROUP BY value_source
 UNION ALL SELECT 'QT_REQUIRED', qt_required, COUNT(*) FROM srd_iprod.pr_pricing_factors GROUP BY qt_required
 UNION ALL SELECT 'UI_FLAG', ui_flag, COUNT(*) FROM srd_iprod.pr_pricing_factors GROUP BY ui_flag
 UNION ALL SELECT 'UI_REQUIRED', ui_required, COUNT(*) FROM srd_iprod.pr_pricing_factors GROUP BY ui_required   -- ORA-00904 on PROD
 UNION ALL SELECT 'POLICY_TABLE', policy_table, COUNT(*) FROM srd_iprod.pr_pricing_factors GROUP BY policy_table
 UNION ALL SELECT 'PRICING_TYPE', pricing_type, COUNT(*) FROM srd_iprod.pr_pricing_factors GROUP BY pricing_type
 UNION ALL SELECT 'HAS_DEFAULT_VALUE', has_default_value, COUNT(*) FROM srd_iprod.pr_pricing_factors GROUP BY has_default_value
 UNION ALL SELECT 'F.STATUS', NVL(status,'<NULL>'), COUNT(*) FROM srd_iprod.pr_pricing_factors GROUP BY status
 UNION ALL SELECT 'V.STATUS', NVL(status,'<NULL>'), COUNT(*) FROM srd_iprod.pr_pricing_factor_values GROUP BY status
) ORDER BY col, n DESC;

FINDING. (1) The pricing-factor model's § PF-7 row "STATUS is populated: A on factors" is dev-only — on QA, STAGING and PROD PR_PRICING_FACTORS.STATUS is NULL on every row; the value-table codes M/MO/O/U/A do exist on all environments (~2–3 %). (2) VALUE_SOURCE confirms the model: ~84 % POV, then a long tail of C# member paths and expressions, i.e. it is the dispatch key and carries code. (3) POLICY_TABLE is a single space on 161 (QA) / 144 (PROD) rows and DATATYPE is ' ' on 2 rows per environment — blank-string, not NULL, so IS NULL predicates miss them. (4) One QA row carries HAS_DEFAULT_VALUE='B', which no reader should accept.

Resolution. CH-12 → F Eight confirming queries run 02.09.2026 on QA and PROD (results in § DB-1c). DATATYPE/VALUE_SOURCE/QT_REQUIRED/UI_FLAG distributions are as modelled; factor STATUS is NULL everywhere in the customer estate (the A seen on dev is not there), value STATUS carries M/MO/O/U/A on ~2–3 % of rows on every environment — still "populated, do not retire by it". Blank-string sentinels (' ') exist in POLICY_TABLE (144–161 rows) and DATATYPE (2 rows); treat TRIM(col) IS NULL as empty. Amend § PF-7's STATUS row: "populated on values; NULL on factors on QA/STAGING/PROD".

DB-1d Hygiene checks

SELECT 'dep_not_null' k, COUNT(*) n FROM srd_iprod.pr_pricing_factors WHERE dependent_on_factor IS NOT NULL
UNION ALL SELECT 'dep_blank_only',        COUNT(*) FROM srd_iprod.pr_pricing_factors WHERE dependent_on_factor IS NOT NULL AND TRIM(dependent_on_factor) IS NULL
UNION ALL SELECT 'dep_no_pipe_nonblank',  COUNT(*) FROM srd_iprod.pr_pricing_factors WHERE TRIM(dependent_on_factor) IS NOT NULL AND INSTR(dependent_on_factor,'|')=0
UNION ALL SELECT 'hasdef_Y_null_default', COUNT(*) FROM srd_iprod.pr_pricing_factors WHERE has_default_value='Y' AND default_value IS NULL
UNION ALL SELECT 'hasdef_N_with_default', COUNT(*) FROM srd_iprod.pr_pricing_factors WHERE has_default_value='N' AND default_value IS NOT NULL
UNION ALL SELECT 'F.descr_link_missing', COUNT(*) FROM srd_iprod.pr_pricing_factors f WHERE f.descr_link IS NOT NULL
        AND NOT EXISTS (SELECT 1 FROM srd_iprod.sr_messages m WHERE m.msg_id=f.descr_link)
UNION ALL SELECT 'F.ui_group_descr_link_missing', COUNT(*) FROM srd_iprod.pr_pricing_factors f WHERE f.ui_group_descr_link IS NOT NULL
        AND NOT EXISTS (SELECT 1 FROM srd_iprod.sr_messages m WHERE m.msg_id=f.ui_group_descr_link)
UNION ALL SELECT 'V.descr_link_missing', COUNT(*) FROM srd_iprod.pr_pricing_factor_values v WHERE v.descr_link IS NOT NULL
        AND NOT EXISTS (SELECT 1 FROM srd_iprod.sr_messages m WHERE m.msg_id=v.descr_link);
-- shape of the non-pipe dependency strings
SELECT pricing_factor_code, COUNT(*) n, MIN(dependent_on_factor) sample FROM srd_iprod.pr_pricing_factors
WHERE TRIM(dependent_on_factor) IS NOT NULL AND INSTR(dependent_on_factor,'|')=0 GROUP BY pricing_factor_code ORDER BY 2 DESC;

The no-pipe dependencies are dominated by DURATION → DURATION_DIMENSION (81 rows on QA) and the car chain CAR_MODEL/CAR_MAKE/ATTR2/ENGINE_TYPE → CAR_SUBTYPE / CAR_MAKE (≈38 rows): a bare factor code, no |policyAttributes.… path. The Y-with-NULL-default rows are cargo (1100/1101/1102/1103: FREIGHT_DIMENSION, AVERAGE_AGENT, ACTUAL_VALUE, SHIPMENT_DOC), 2227, 4704, 2214, 2222, 4710, 1126, 8000, 4703. The orphan value DESCR_LINKs are mostly literal Bulgarian labels used as ids (1123 FLAG: „Андора“, „Албания“, …), and the orphan factor links are literal text too („Cargo policy type“, 1126_RECONSTR_DATE with a trailing space, COVER, MEMBER_CARD, PF_MANUALLY_CORRECTED).

FINDING. The "pipe" form is the minority (44 of 170 on QA); 119 rows use a bare factor code. Either the model's "every dependency carries a | path" is wrong, or ~70 % of the live rows are in a legacy form the code tolerates — the reader must accept both. DESCR_LINK is used as a free-text label on ~30 % of value rows and on a few factor rows; the SR_MESSAGES join is not a validity test one can enforce retroactively, though it should be for new rows.

Resolution. Added to the pricing-factor failure atlas (Stage IPAL § PF-8) as F: DEPENDENT_ON_FACTOR has two live shapes — CODE|path (44 rows on QA) and bare CODE (119 rows; DURATION→DURATION_DIMENSION, car chain); DESCR_LINK is a literal label on ~1,000 value rows per environment; 36 (QA) / 80 (PROD) factors say HAS_DEFAULT_VALUE='Y' with no DEFAULT_VALUE; one QA row has HAS_DEFAULT_VALUE='B'. The S3 validator should flag all four on new rows and never "repair" existing ones.

DB-2 PR_PRICING_FACTOR_ANNEX

SELECT column_name, data_type, nullable FROM all_tab_columns
WHERE owner='SRD_IPROD' AND table_name='PR_PRICING_FACTOR_ANNEX' ORDER BY column_id;
SELECT COUNT(*) rows_, COUNT(DISTINCT product_code) products, COUNT(DISTINCT pricing_factor_code) factor_codes FROM srd_iprod.pr_pricing_factor_annex;
SELECT owner, name, type, COUNT(*) hits FROM all_source WHERE UPPER(text) LIKE '%PR_PRICING_FACTOR_ANNEX%' GROUP BY owner, name, type;
SELECT owner, name, type FROM all_dependencies WHERE referenced_name='PR_PRICING_FACTOR_ANNEX';
SELECT object_name, TO_CHAR(created,'YYYY-MM-DD') created, TO_CHAR(last_ddl_time,'YYYY-MM-DD HH24:MI') last_ddl
FROM all_objects WHERE owner='SRD_IPROD' AND object_type='TABLE' AND object_name='PR_PRICING_FACTOR_ANNEX';
SELECT COUNT(*) FROM srd_iprod.pr_pricing_factor_annex a WHERE NOT EXISTS
 (SELECT 1 FROM srd_iprod.pr_pricing_factors f WHERE f.product_code=a.product_code AND f.pricing_factor_code=a.pricing_factor_code);

ANNEX_PREM.cCHCover(pi_CovPrev, pi_CovNew) returns TRUE when at least one pricing factor listed in PR_PRICING_FACTOR_ANNEX for the cover has a different POL_OBJECT_VALUES.PRM_CVALUE than in the previous annex — the header comment reads "Purpose: Checks for a changed cover … The list of price factors is defined in srd_iprod.pr_pricing_factor_annex … Usage: Any annex without Policy cancellation". Top products by rows on QA: 2200 (49), 2214 (27), 2215 (24), 1116 (23), 1117 (22), 2204 (21), 3602 (20, orphaned), 3618 (20), 3303 (18), 2222 (17), 3304 (15), 3636 (10).

FINDING. The table is not consumer-less — it is consumed by PL/SQL, not by serdica-backend, which is why the C# grep found nothing. It is the per-product list of "premium-relevant" factors that the annex premium engine compares to decide whether a cover changed in an annex. It has 501 rows on the customer environments, 42 products, and a static shape (no date column; created 01.08.2025 on PROD). Nothing writes it at runtime; it is configuration.

Resolution. CH-10 / CH-13 → F PR_PRICING_FACTOR_ANNEX (5 columns, 501 rows / 42 products on STAGING and PROD, 340 / 41 on QA) is read by SRD_CUST.ANNEX_PREM.cCHCover — the annex engine's "did this cover change" test — and by nothing in serdica-backend. A product that supports non-cancellation annexes must list its premium-relevant factors here, or every annex will see the cover as unchanged. 20–21 rows reference (product, factor) pairs with no PR_PRICING_FACTORS row (product 3602 on QA). The pricing-factor model's "three tables" becomes four (Stage IPAL § PF-1); Stage IPAL's lifecycle-scope challenge (CH-20) gains a concrete artefact.

DB-3 UI_REQUIRED

SELECT column_name, nullable, data_type, column_id FROM all_tab_columns
WHERE owner='SRD_IPROD' AND table_name='PR_PRICING_FACTORS' AND column_name='UI_REQUIRED';
SELECT COUNT(*) FROM all_tab_columns WHERE owner='SRD_IPROD' AND table_name='PR_PRICING_FACTORS';
SELECT ui_required, COUNT(*) FROM srd_iprod.pr_pricing_factors GROUP BY ui_required;

FINDING. The pricing-factor model's § PF-7 verdict — "the compiled model says UI_REQUIRED is absent; wrong, the table has 26 columns and it is NOT NULL" — is true on QA and STAGING and false on PROD. On PROD the compiled EF model (25 properties) and the table (25 columns) agree; emitting UI_REQUIRED there does raise ORA-00904, exactly as the compiled model predicted. The column was added to QA on or before 18.03.2026 and has not been promoted to PROD. Both parties in § PF-7 were right about a different environment.

Resolution. § PF-7 row → F UI_REQUIRED exists NOT NULL on QA (since ≤ 18.03.2026) and STAGING; PROD's PR_PRICING_FACTORS has 25 columns and no UI_REQUIRED (verified 02.09.2026) — a schema drift between environments. An insert script is environment-specific: supply UI_REQUIRED on QA/STAGING, omit it on PROD, and re-check ALL_TAB_COLUMNS at plan time rather than trusting either the compiled model or this page. Add the drift to KI-054 (branch drift) or its DB-side sibling, and to the Stage IPAL plan as an environment-introspection step.

DB-4 PL/SQL change cadence on STAGING (the cadence of Stage Planning § 3b, re-measured)

SELECT TO_CHAR(TRUNC(last_ddl_time),'YYYY-MM-DD') d, COUNT(*) objs, COUNT(DISTINCT last_ddl_time) ts,
       TO_CHAR(MIN(last_ddl_time),'HH24:MI:SS') first_t, TO_CHAR(MAX(last_ddl_time),'HH24:MI:SS') last_t,
       ROUND((MAX(last_ddl_time)-MIN(last_ddl_time))*24,2) span_h
FROM all_objects WHERE owner='SRD_INTEGR' AND object_type IN ('PACKAGE','PACKAGE BODY')
  AND last_ddl_time >= SYSDATE-90 GROUP BY TRUNC(last_ddl_time) ORDER BY 1;
SELECT object_type, status, COUNT(*) FROM all_objects WHERE owner='SRD_INTEGR'
  AND object_type IN ('PACKAGE','PACKAGE BODY') GROUP BY object_type, status;
SELECT TO_CHAR(TRUNC(last_ddl_time,'MI'),'YYYY-MM-DD HH24:MI') minute_bucket, COUNT(*) objs, COUNT(DISTINCT last_ddl_time) ts
FROM all_objects WHERE owner='SRD_INTEGR' AND object_type IN ('PACKAGE','PACKAGE BODY') AND last_ddl_time >= SYSDATE-90
GROUP BY TRUNC(last_ddl_time,'MI') HAVING COUNT(*)>=5 ORDER BY 2 DESC;

STAGING, 90 days to 02.09.2026:

Package status STAGING: 107 PACKAGE valid; PACKAGE BODY 91 valid / 13 INVALID. Of the 173 objects touched on 19.08, 0 were created that day and 11 are INVALID now → a mass recompile, not a deployment of new objects.

Same query on QA (to validate the page's numbers) and PROD (bonus):

FINDING. (1) STAGING is less frequently changed than QA over this window (6 active days vs 13), contradicting the description "the most frequently changed" — at least for the last 90 days; the description may reflect release weeks rather than a steady state. (2) STAGING's dominant event is one mass recompile (171 objects in a minute on 19.08, nothing created, 11 left INVALID); on that day a timestamp-based poll would have flagged the entire schema — exactly the case the page's "signature, not timestamp" rule exists for. (3) The page's characterisation of QA 07.08 as "not a mass recompile" needs a nuance: 86 of the 105 objects were bumped in 28 seconds — a mass action embedded in a 5.4-hour session. (4) QA carries 46 INVALID package bodies (43 %), STAGING 13, PROD 0 — the sync's health baseline differs sharply per environment, and an apply on QA that triggers dependent revalidation will surface pre-existing breakage that is not the apply's fault.

Resolution. CH-29 → F Re-measured 02.09.2026 on bulstrad-staging (ablera-db-test): 6 active days in 90 (QA 13, PROD 15); normal day 2–5 objects; one mass recompile of 171 SRD_INTEGR packages inside a single minute on 19.08.2026 (0 created, 11 still INVALID). The "most frequently changed" description does not hold for DDL cadence in this window. Baseline invalid package bodies: QA 46/108, STAGING 13/104, PROD 0/95 — the snapshot must record STATUS per object so a post-apply INVALID is attributable. Amend the QA 07.08 line: "105 objects, 86 of them in a 28-second burst".

DB-5 SRD_SUPPORT prerequisites on QA

SELECT username, TO_CHAR(created,'YYYY-MM-DD') FROM all_users WHERE username LIKE 'SRD%' ORDER BY 1;
SELECT banner_full FROM v$version;
SELECT tablespace_name, status, contents FROM user_tablespaces;                                  -- ALL_TABLESPACES: ORA-00942
SELECT tablespace_name, ROUND(SUM(bytes)/1024/1024/1024,1) size_gb, ROUND(SUM(maxbytes)/1024/1024/1024,1) max_gb FROM dba_data_files GROUP BY tablespace_name;
SELECT tablespace_name, ROUND(SUM(bytes)/1024/1024/1024,1) free_gb FROM dba_free_space GROUP BY tablespace_name;
SELECT * FROM user_ts_quotas;
SELECT resource_name, limit FROM user_resource_limits;
SELECT username, profile, account_status, default_tablespace FROM dba_users WHERE username LIKE 'SRD_%';
SELECT parameter, value FROM v$option WHERE parameter LIKE 'Unified%' OR parameter LIKE 'Flashback%';
SELECT policy_name, enabled_option, entity_name, success, failure FROM audit_unified_enabled_policies;
SELECT name, value FROM v$parameter WHERE name IN ('audit_trail','sessions','processes','compatible','recyclebin');
SELECT action_name, COUNT(*), MAX(TO_CHAR(timestamp,'YYYY-MM-DD')) FROM dba_audit_trail GROUP BY action_name;
SELECT * FROM dba_stmt_audit_opts; SELECT * FROM dba_priv_audit_opts;

FINDING. Nothing pre-exists: no SRD_SUPPORT user, no dedicated tablespace, no profile. All SRD schemas share USERS, which is at its 48 GB max with 8.4 GB free — an append-only snapshot store of package bodies (≈95 packages × N versions × environments) fits, but the store should get its own tablespace with AUTOEXTEND rather than compete with SRD_CUST in USERS. Enterprise Edition means Flashback Data Archive and partitioning are licensed options available for the ledger, if wanted. Auditing: unified auditing is off and no traditional audit options are set, so the Stage Planning § 3b proposal "a unified-audit policy on CREATE/ALTER PACKAGE" would be the first audit policy on this database — it needs a DBA, not just Ablera dev.

Resolution. CH-02 / CH-60 stay [B] (written confirmation still needed) but gain the F preconditions: On QA (02.09.2026) SRD_SUPPORT does not exist; 19c EE 19.15, USERS tablespace 48/48 GB (8.4 GB free), profile DEFAULT with unlimited sessions, unified auditing FALSE, no statement/privilege audit options configured. Request to the DBA: create SRD_SUPPORT with its own autoextend tablespace and a profile with a SESSIONS_PER_USER cap; enable a unified-audit policy on CREATE/ALTER PACKAGE for SRD_INTEGR.

DB-6 Non-production restore / rehearsal capability

SELECT name, log_mode, flashback_on, force_logging, cdb, database_role FROM v$database;
SELECT name, value FROM v$parameter WHERE name IN ('undo_retention','undo_tablespace','db_flashback_retention_target','db_recovery_file_dest','db_recovery_file_dest_size');
SELECT name, guarantee_flashback_database, time FROM v$restore_point;
SELECT retention FROM dba_tablespaces WHERE tablespace_name='UNDOTBS1'; SELECT MAX(tuned_undoretention) FROM v$undostat;
SELECT name, space_limit, space_used, number_of_files FROM v$recovery_file_dest;
SELECT TO_CHAR(start_time,'YYYY-MM-DD HH24:MI') start_t, input_type, status, ROUND(output_bytes/1024/1024/1024,1) out_gb
FROM v$rman_backup_job_details ORDER BY start_time DESC FETCH FIRST 8 ROWS ONLY;

FINDING. QA — the platform's development target and the proposed home of SRD_SUPPORT — has no working backup: RMAN last ran two years ago and failed, NOARCHIVELOG means no point-in-time recovery, flashback is off, there are no restore points, and undo is 15 minutes NOGUARANTEE (so FLASHBACK TABLE … TO TIMESTAMP is good for minutes, not a rehearsal). The only reversible-rehearsal primitives available today on QA are transaction rollback, the recycle bin for dropped objects, and short-window flashback query. STAGING is backed up nightly (also NOARCHIVELOG, so restore = to last night's backup, whole database). PROD is ARCHIVELOG with completed backups.

Resolution. CH-55 → F Measured 02.09.2026: QA has no valid backup (last RMAN 26.07.2024, FAILED), NOARCHIVELOG, flashback off, no restore points, undo 900 s NOGUARANTEE. A complete restore of QA is not possible today; only in-transaction rollback and ≤ 15-minute flashback query are. STAGING: nightly RMAN incremental succeeding, NOARCHIVELOG (restore to last night, whole DB). The rehearsal design must either (a) get QA backups fixed and a guaranteed restore point created before each simulation (needs ARCHIVELOG + flashback on — DBA change), or (b) treat QA rehearsal as non-restorable and rely on effect inventories (CH-81). CH-02 / CH-60 sharpen: the question is not whether SRD_SUPPORT is in the QA backup inventory — there is no QA backup inventory to be in. This is the single most consequential finding of the sweep; the git mirror of Stage Planning § 3b is currently the only durable copy of anything on QA.

DB-7 Identical-fix counting — DML / correction logs on QA

SELECT owner, table_name, num_rows, TO_CHAR(last_analyzed,'YYYY-MM-DD') analyzed FROM all_tables
WHERE owner IN ('SRD_INTEGR','SRD_CUST','SRD_SYS','SRD_IPROD')
  AND (table_name LIKE '%LOG%' OR table_name LIKE '%AUDIT%' OR table_name LIKE '%CORRECT%' OR table_name LIKE '%SUPPORT%'
       OR table_name LIKE 'HIST%' OR table_name LIKE '%_HIST' OR table_name LIKE '%TRACE%' OR table_name LIKE '%FIX%')
  AND table_name NOT LIKE 'XX%' AND table_name NOT LIKE 'Z%' ORDER BY 1,2;
SELECT operation_type, COUNT(*), MIN(operation_date), MAX(operation_date), COUNT(DISTINCT operation_user) FROM srd_cust.audit_logs GROUP BY operation_type;
SELECT end_point_type, COUNT(*), COUNT(DISTINCT model), MIN(created_on), MAX(created_on) FROM srd_integr.dbtools$mcp_log GROUP BY end_point_type;
SELECT owner, COUNT(*) FROM all_triggers WHERE owner IN ('SRD_INTEGR','SRD_CUST','SRD_IPROD','SRD_SYS') GROUP BY owner;

FINDING. There is no table on QA IPAL that records operator or support DML against policy data. The only structured audit is the SQLcl MCP's own log — which captures what AISA ran, with the SQL text, but nothing that Toad, SQL Developer or a colleague's script did. A fix signature (target table + column + fix shape) therefore cannot be joined to anything that exists; it has to be written by the platform at apply time (the SRD_SUPPORT ledger), and DBTOOLS$MCP_LOG is the only source from which v1's historic fixes could be back-filled — and only the fraction that went through the MCP.

Resolution. CH-39 stays C but with the frame fixed as F: No DML/correction log exists on QA IPAL (02.09.2026): 0 triggers on SRD_INTEGR/SRD_CUST/SRD_IPROD/SRD_SYS, no Oracle statement audit options, app-level AUDIT_LOGS covers two claims operations only. The fix signature is recorded by the platform at apply, not derived from the database; SRD_INTEGR.DBTOOLS$MCP_LOG (1,559 AISA statements since 10.09.2025, SQL text in LOG_MESSAGE) is the one back-fill source for v1's recurring families and is blind to non-MCP sessions.

DB-8 Cross-cutting corrections to the wiki (all F, 02.09.2026)

1. Stage IPAL § PF-7 — UI_REQUIRED: present NOT NULL on QA/STAGING, absent on PROD (25 columns). Both the compiled model and the page were right for different environments; inserts are environment-specific.
2. Stage IPAL § PF-7 — STATUS: NULL on every factor row on QA/STAGING/PROD (dev's A is not in the customer estate); value STATUS M/MO/O/U/A is on ~2–3 % everywhere.
3. Stage IPAL § PF-7 — PR_PRICING_FACTOR_ANNEX has a consumer: SRD_CUST.ANNEX_PREM.cCHCover (annex "cover changed" test). 501 rows / 42 products on STAGING+PROD.
4. Stage IPAL § PF-8b — STAGING and PROD are 100 % POL; QA 186 QT rows / 16 products; product 9951 does not exist on QA.
5. Stage IPAL § PF-8b — dependency shapes: bare-code (119) outnumbers CODE|path (44) on QA.
6. Stage Planning § 3b — STAGING cadence 6 active days / 90 with one 171-object recompile minute; QA 07.08 contained an 86-object 28-second burst; INVALID bodies QA 46, STAGING 13, PROD 0.
7. Failure and Recovery § 5 / Software Architecture § 10 — QA has no working backup (last RMAN 26.07.2024 FAILED), NOARCHIVELOG, flashback off, no restore points.
8. Workspace — BST-QA-IPAL-SRD_INTEGR is not in this machine's SQLcl connection store (QA reached via BST_QA_SRD_CUST); memory/project/sqlcl_connections_state.md should be corrected.

Not done / not verifiable here: last-modified of PR_PRICING_FACTOR_ANNEX (no date column, SCN too old); DBA_* views on STAGING/PROD were not exercised beyond v$database/RMAN; PROD dependent-STATUS and UI_GROUP_DESCR_LINK counts were skipped to keep PROD light.

RE. Repository evidence — serdica-backend and the workspace

Read-only pass over serdica-backend (origin/master, origin/bulstrad-qa, origin/bulstrad-staging, origin/bulstrad-prod, origin/codex/health-ai-csharp-architecture), serdica-infrastructure (local clone C:\dev\serdica-infrastructure-health-ai-services, HEAD), and the workspace files. No checkout, no database. Citations are path@branch:line. Verdicts: F now a fact · P decision proposal for Vladimir · C still open, with what is missing.

Register ids as the register stood on 02.09.2026; it has been regenerated several times since and these ids no longer resolve: 1→CH-10, CH-13 · 2→CH-14 · 3→CH-25 · 4→CH-57 · 5→CH-47 · 6→CH-75 · 7→CH-39 · 8→CH-50, CH-66, CH-69 · 9→CH-26 · 10→(no row; fed the configuration-summary challenge) · 11→CH-05, CH-30, CH-49 · 12→CH-19.

Where a section's conclusion was later decided differently, the section says so.

RE-1 PRICING_TYPE and PR_PRICING_FACTOR_ANNEX consumers — CH-10, CH-13

Challenge. PRICING_TYPE has no behavioural consumer; PR_PRICING_FACTOR_ANNEX exists as a table with no consumer in code — establish what writes and reads it.

What I did. git grep -n -i -E "PrPricingFactorAnnex|PR_PRICING_FACTOR_ANNEX" on origin/bulstrad-staging and origin/master; git grep for PricingType / PRICING_TYPE on both, excluding DBModels/migrations/EntityTypes; read every hit on master; git cat-file -e per branch; git log --diff-filter=A for the entity.

Finding. - Staging has zero references to the annex table — the grep on origin/bulstrad-staging returns nothing. The table is unknown to the staging (and prod) code base. The entity exists on master, bulstrad-qa and the codex branch only; absent on bulstrad-staging and bulstrad-prod. First commit carrying it: b425b15e53 2025-10-10 (Preslav Petkov, "register par claim notification"). - Shape: src/PolicyAdministrationSystem/__Libraries/Ablera.Serdica.DBModels.IPAL/DBModels/IPAL/PrPricingFactorAnnex.cs@master:6-18 — five columns: PfAnnexId, ProductCode, ObjectCode, CoverCode, PricingFactorCode. Mapped to SRD_IPROD.PR_PRICING_FACTOR_ANNEX with unique key (ProductCode, CoverCode, ObjectCode, PricingFactorCode) — IPALDbContext.cs@master:9136-9140. - Readers (master): - PasPremium.Service/Services/PremiumEngine/CalculationContextLoader.cs@master:75-78 loads all rows for the policy's product into CalculationContext.AnnexPricingFactors (PasPremium.Plugin.Base/Models/CalculationContext.cs@master:17). - PasPremium.Service/Services/PremiumEngine/CoverChangeDeterminer.cs@master:109-121 GetAnnexPricingFactors: if the product has rows in the annex table, those factors are the change-sensitive set (IsRequiredForChange = true for every row); otherwise the fallback is PR_PRICING_FACTORS rows with SALE_STAGE = 'POL', where QT_REQUIRED = 'Y' marks the factor as change-sensitive — Ablera.Serdica.Ipal.ChangeDeterminer/Models/AnnexPricingFactor.cs@master:12-29. - Ablera.Serdica.Ipal.ChangeDeterminer/Services/IpalCoverChangeDeterminer.cs@master:87-131: PolicyPricingFactorsChanged (factors with no object/cover scope, compared over POL_VALUES) and ObjectPricingFactorsChanged (factors scoped to the object type + cover, compared over POL_OBJ_VALUES) — a changed value of a listed factor raises CoverChangeReason.PolicyPricingFactorChanged / ObjectPricingFactorChanged, i.e. the cover counts as changed on the annex and is re-rated. - PasHealth.Services/Services/DependentPolicyChangeDetector.cs@master:334-356 — the same override-then-fallback pattern for the health dependent-policy detector. - Writers: none in code on any branch (no Add/insert). The table is configuration, written by hand or by a configuration script. - PRICING_TYPE: on staging the only non-model references are the generated GraphQL setters Ablera.Serdica.GraphQL.WebServer/Schema/Models.Generated.cs@bulstrad-staging:81524,81580 (pass-through) and the EF mapping; on master none outside DBModels. No branch branches on BP vs LD.

Resolution. - F PR_PRICING_FACTOR_ANNEX is the per-product annex change-sensitivity list: which pricing factors, when their value differs between the annex and the previous state, force the cover to be re-rated. When a product has no rows, PR_PRICING_FACTORS(SALE_STAGE='POL', QT_REQUIRED='Y') is that list — which gives QT_REQUIRED a second meaning on master/qa that the pricing-factor model (Stage IPAL § PF-) does not carry yet. Nothing writes it; it exists only on master, bulstrad-qa and the codex branch, so a product configured on staging or prod cannot use it. - F PRICING_TYPE has no behavioural consumer on staging or master. - F The DB count was out of scope for this pass but was taken the same day by the database pass, measured 02.09.2026: 501 rows / 42 products on STAGING and PROD, 340 / 41 on QA* — the query is in § DB-2 of this page.

RE-2 The pageSize:-1 truncation cap — CH-14

Challenge. The branch difference is confirmed, the cap value is not.

What I did. git show d7f8c72210; git branch -r --contains; grep MaxPageSize / DefaultMaxPageSize on all four branches; compared the PagingHelper per branch.

Finding. - Staging: commit d7f8c72210 2026-08-19 "Clamp the no limit requests" (Vladimir Moushkov). src/Common/CommonCustomLibraries/Ablera.Serdica.CrudBaseServices/Helpers/PagingHelper.cs@bulstrad-staging:11 — DefaultMaxPageSize = 25000. Applied in BaseMainService.cs@bulstrad-staging:258 and Services/Crud/CrudOperations/GetListCrudOperation.cs@bulstrad-staging:109. A page size of -1 (or any non-positive value) becomes one page of the cap; MainServiceConfig.MaxPageSize = 0 means the default, a negative value disables the cap (Config/MainServiceConfig.cs@bulstrad-staging:16-21). The only service that configures it: src/BusinessInsurance/PasNotes/App/appsettings.json@bulstrad-staging:133 → "MaxPageSize": 100. ⚠ The XML doc comment on MainServiceConfig.MaxPageSize says "(1000)" while the constant is 25000 — a stale comment. - Master and bulstrad-qa: commit a44b7e21c8 2026-08-30, same title, different path src/PolicyAdministrationSystem/__Libraries/Ablera.Serdica.CrudBaseServices/Helpers/PagingHelper.cs@master — DefaultMaxPageSize = 1000; no appsettings.json sets MaxPageSize on either branch. - bulstrad-prod: no PagingHelper, no clamp — BaseDataService.cs still treats pageSize <= 0 as "no paging" (unbounded). - Unrelated MaxPageSize constants exist on master in the Claims services (200) and RevoxyMaxPageSize (100) — per-endpoint, not the CRUD clamp.

Resolution. F The server cap for pageSize:-1 on CRUD "get list" requests is 25 000 rows on bulstrad-staging (100 for PasNotes), 1 000 rows on master and bulstrad-qa, and no cap on bulstrad-prod. Configurable per service through MainServiceConfig.MaxPageSize. The two branches carry different defaults under the same commit title — whoever promotes staging→prod or merges master→staging must pick one number; the staging doc comment should be corrected to match.

RE-3 Microservice endpoints and core's appsettings.json — CH-25

Challenge. "Some microservice endpoints also register in core's appsettings.json" — trace one recently added endpoint end to end and state the rule.

What I did. Read Ablera.Serdica.Microservice.Initializer.EndpointsRegistration/Initializer.cs, every reader of EndPoints/EndpointSections, every reader of RabbitMQRoutingConfig, MessageHandler.TryResolveRouteConfig, and the RouteConfigs block of core's appsettings; git log -S for the example key and for the prefix-match code.

Finding. - DB registration is automatic. src/__Libraries/Ablera.Serdica.Microservice.Initializer.EndpointsRegistration/Initializer.cs@master:29-121: at startup each microservice upserts its EndpointSections row (Name = SectionName, ExchangeName) and one EndPoints row per endpoint map (Name, Command, Action, AllowedRoles, Timeout, input/output JSON schemas). No hand work: deploying the service creates the rows. - Callers that resolve from the DB: the REST gateway Ablera.Serdica.RestApi.WebServer/Services/MessageBus/MessengersManager.cs@master:55-90 builds one messenger per EndpointSections row (exchange = ExchangeName, route key <exchange>.request, reply queue <exchange>.response.to.rest-api.<instance>); service-to-service RPC Ablera.Serdica.Microservice.Rpc/MicroserviceRpcClient.cs@master:70-105 resolves (section, command) through EndPoints → <exchange>.request and the endpoint timeout. Neither reads appsettings. - Core is the exception. src/Serdica/Core/Core/Services/MessageHandler.cs@master:82 takes routeMap = RabbitMQRoutingConfig.RouteConfigs; TryResolveRouteConfig@master:552-575 matches the exact command key, else the longest key K such that the command starts with K. (section-prefix match, added by b6a7d75d32 2026-02-17 "Health Policy Actions implementation" — present on master and bulstrad-qa, absent on bulstrad-staging); otherwise IncorrectCommandException (:297-299, :354-356). RegisterTopologies@master:250-272 declares exchanges/queues/bindings from the same map; Program.cs@master:161-169 and MessageBus/RabbitBrokerConfigurator.cs@master:47-50 pre-create the exchanges. - The table: src/Serdica/Core/Core/appsettings.json@master:136-137 (RabbitMQRoutingConfig.RouteConfigs), 1 057 "Exchange" entries on master; src/Core/Core/appsettings.json@bulstrad-staging 1 021 entries (every command listed — no prefix match there). - Worked example: pas_health_manager.open_policy_for_change — appsettings entry added by 044455a364 2025-12-30 (appsettings.json@master:162-167, exchange pas_health_manager); consumed by the Camunda service task WorkflowEngine/ProcessServices/PolicyChangeServiceTasks.cs@master:620-625 via FireRequestToMicroserviceConsumer, with the comment "must be configured in RabbitMQRoutingConfig" (:620-621). The section-level key "pas_health_manager" (:155-160) already covers it on master by prefix, so the specific entry is redundant there — and mandatory on staging.

Resolution. F The rule: a new endpoint always gets its SRD_SYS.EndPoints / EndpointSections rows for free from the owning service's start-up registration; the REST gateway and service-to-service RPC resolve from those rows. A core appsettings.json entry is needed only when Core itself (a workflow service task through MessageHandler) sends the command — and on master/qa one entry per exchange section suffices because of prefix matching, while on bulstrad-staging every command needs its own entry. A new product needs no core entry unless it introduces a new microservice or exchange that Core calls. The wiki sentence should say "commands Core sends", not "some endpoints".

RE-4 Ablera.Serdica.CiJobsBuilder invocation recipe — CH-57

Challenge. Read Program.cs on master before generating.

What I did. Read tools/Ablera.Serdica.CiJobsBuilder/Program.cs@master in full, listed the tool folder, found the .gitlab-ci.yml includes and the template folder.

Finding. - Invocation (from the repo root): dotnet run --project tools/Ablera.Serdica.CiJobsBuilder -- -s src -o .gitlab-ci/autogenerated [--sdk 9.0] [--alpine 3.19] [--code-quality-dotnet-scanner-tag scanner-dotnet-9.0] [--security-scanner-service-tag 0.63.0-ablera3]; -v <template> prints a template; -h help. Switch map Program.cs@master:23-36, defaults :11-14, usage text :44-70. - Inputs: every *.csproj under --src, classified (Program.cs@master:379-393): path contains /__Libraries/ → Library; /__Integrations/ and not an app → Library; /__Plugins/ → Plugin unless the name contains .Base. → Library; SDK Microsoft.NET.Sdk.Web / .Worker or an exe → Application; else Library. Test projects are skipped (:400-404). Templates: tools/Ablera.Serdica.CiJobsBuilder/templates/{docker-app.sbn, docker-plugin.sbn, gitlab-ci.sbn} (Scriban). - Outputs: <ProjectDir>/../<ProjectName>.Dockerfile — written only if missing or its first line carries generated-by: Ablera.Serdica.CiJobsBuilder (:149-176, custom Dockerfiles are skipped); .gitlab-ci/autogenerated/microservices/<kebab>.yml for applications and .../plugins/<kebab>.yml for plugins (:180-184) with jobs build_<kebab>, push_<kebab>, code_quality_<kebab>, scan_<kebab> extending .build_job_svc, .push_job_svc, .code_quality_job_svc_rules, .scan_job_svc_rules (:191-208); changes: = the project folder, its transitive project references, the Dockerfile and the yml itself. Stale ymls are removed by SafeCleanAutogeneratedDir, which refuses any path outside .gitlab-ci. Exit code 0 = nothing changed, 1 = files updated, -1 = error. - Wiring: .gitlab-ci.yml@master:6-8 includes .gitlab-ci/autogenerated/*.yml, microservices/*.yml, plugins/*.yml; shared job templates in .gitlab-ci/templates/{build-job,push-job,deploy-job,code-quality-job,test-job,variables,before-script}.yml; 96 autogenerated files on master. No CI job runs the builder — it is run locally and the outputs are committed. tools/Ablera.Serdica.CiJobsBuilder/tools/Ablera.Serdica.CiJobsBuilder/apply_changes.ps1 is an empty file (0 bytes).

Resolution. F A new deployable (application or plugin) gets its Dockerfile and build/push/scan jobs by running the builder locally from the repo root and committing <Service>.Dockerfile plus .gitlab-ci/autogenerated/<kind>/<kebab>.yml; the deploy job (.gitlab-ci/configs/deploy-jobs.yml, templates/deploy-job.yml) is not generated and stays hand-written — CH-58/CH-63 remain with Ablera DevOps.

RE-5 Cross-service message ordering — the reused contract's message id — CH-47

Challenge. Over RabbitMQ the outbox gives at-least-once delivery; handlers must be idempotent on message id — verify the reused ServiceActivity contract carries one.

What I did. Listed and read every file of src/Serdica/Ablera.Serdica.AI/Ablera.Serdica.Workflow.ServiceActivity.Contracts on origin/codex/health-ai-csharp-architecture; grepped the branch for idempotency terms.

Finding. (all @codex/health-ai-csharp-architecture, path prefix src/Serdica/Ablera.Serdica.AI/Ablera.Serdica.Workflow.ServiceActivity.Contracts/) - Request AiActivityRequestV1.cs: attemptId :24, dispatchId :27, requestHash :36 (sha-256 of a canonical projection, verified in Validate :58-63). No eventId. Identity is (workflowExecutionId, stepExecutionId, attemptId); ValidateExactReplayOf :66-81 accepts a re-delivered request only if the identity matches and the bytes are identical (ACTIVITY_REPLAY_IDENTITY_MISMATCH / ACTIVITY_REPLAY_CONFLICT) — duplicate delivery is idempotent by construction; ValidateContinuationOf :83. - Completion AiActivityCompletionV1.cs: eventId :13, attemptId :25, dispatchId :28, requestHash :34, plus activityTimeline.revision :220. - Revision AiActivityRevisionsV1.cs: eventId :13, sourceCompletionEventId :16, sourceCompletionSha256 :19; ValidateAgainst :70-81 pins the revision to one completion and requires Timeline.ValidateExtensionOf(previous) (AiActivityAuditTimelineV1.cs:117). - Timeline AiActivityAuditTimelineV1.cs: revision (long, positive) :31, previousHeadSha256 :34 (hash chain: null only at revision 1), per-milestone sequence :226 (must equal index+1) and unique milestoneId :229, with a prerequisite-order table for milestone codes :8-17. - Cancel AiActivityCancelV1.cs: eventId :12, cancelId :15, cancelFenceVersion :33 (monotonic fence). - Start StartWorkflowContracts.cs:35: callerIdempotencySha256.

Resolution. F Completions, revisions and cancels carry a message id (eventId); requests carry no eventId but are idempotent through (workflowExecutionId, stepExecutionId, attemptId) + requestHash exact-replay validation; ordering does not depend on transport order — revisions are numbered and sha-256-chained to their predecessor, milestones carry a sequence, cancels a fence version. A handler can therefore dedupe on eventId and reject an out-of-order revision from the contract alone. F The transport envelope carries the id too: src/__Libraries/Ablera.Serdica.RabbitMQ.Client/RabbitPublishContracts.cs@codex:15-21 — RabbitPublishRequest(…, string MessageId, …, Headers); RabbitConfirmedPublisher.cs@codex:56-64 sets Persistent = true, BasicProperties.MessageId = request.MessageId and a MessageIdHeader header, and on an ambiguous confirm tells the caller to "reconcile by republishing the same ID" (:103-104) — at-least-once with a stable id, as the design assumes.

RE-6 RabbitMQ.Client delta, codex vs master — CH-75

Challenge. Whether the ~500-line supervisor / confirmed-publisher addition should go into master's library — the proposition needs the exact delta.

What I did. git diff --stat origin/master origin/codex/health-ai-csharp-architecture -- src/__Libraries/Ablera.Serdica.RabbitMQ.Client src/__Libraries/Ablera.Serdica.RabbitMQ.Topology; extracted the added public types; read the builder diff; listed codex-only sibling libraries.

Finding. - 13 files, +632 / −6 lines (net +626). Ablera.Serdica.RabbitMQ.Client/: AGENTS.md +21, .csproj +6 (TreatWarningsAsErrors, Microsoft.Extensions.{DependencyInjection.Abstractions,Logging.Abstractions,Options} 9.0.5), Constants/ConstantsClass.cs +9, RabbitClientBuilder.cs +28/−6, RabbitClientOptions.cs +10, RabbitConfirmedPublisher.cs +147, RabbitConnectionSupervisor.cs +194, RabbitPublishContracts.cs +49, RabbitTraceContext.cs +49. Ablera.Serdica.RabbitMQ.Topology/: AGENTS.md +19, RabbitTopologyServiceCollectionExtensions.cs +1, IRabbitStrictTopologyValidator.cs +8, RabbitStrictTopologyValidator.cs +91. - New public types: IRabbitConnectionSupervisor : IDisposable, RabbitConnectionSupervisor, RabbitSupervisorStatus (record), IConfirmedRabbitPublisher, RabbitConfirmedPublisher, RabbitPublishRequest / RabbitPublishResult (records), RabbitPublishOutcome (enum), RabbitClientOptions (Uri, ClientProvidedName, RequestedHeartbeat 30 s, NetworkRecoveryInterval 5 s, ConfirmTimeout 10 s), RabbitTraceContext (static), ConstantsClass, IRabbitStrictTopologyValidator, RabbitStrictTopologyValidator, RabbitTopologyMismatchException. - The six deletions are the placeholder body of AddRabbitClientDefaults (master's comment: "thin placeholder used to stage the extraction"); codex replaces it with AddSupervisedRabbitClient(services, configure, topology) registering the supervisor and confirmed publisher via TryAddSingleton, and keeps AddRabbitClientDefaults() as a wrapper — source-compatible with master's callers. - Codex-only sibling libraries (not in the diff, absent on master): Ablera.Serdica.RabbitMQ.Outbox (3 .cs), .Broadcast (1), .Integration (7).

Resolution. P Proposition to the library owner: fold the 13-file delta into master's RabbitMQ.Client + .Topology — it is purely additive (the only removed lines are a placeholder), keeps the existing extension method, adds no dependency on the health-AI code, and replaces a stated TODO in master itself. Merge Outbox/Broadcast/Integration separately, after the reuse verdicts of Software Architecture § 9 (they carry the health-AI persistence assumptions).

RE-7 Identical-fix signature — CH-39

Challenge. Counting "identical fixes" needs a fix signature — target table + column + fix shape proposed; validate it against v1's recurring families.

What I did. Read KNOWN_ISSUES.md (56 KI entries) and memory/feedback/recurring_manual_fix_escalate_to_config.md; extracted the fix shape and ticket list of KI-030, KI-017, KI-043.

Finding — three families as the register records them.

Proposed signature (fields): system (IPAL | INSIS | ABACUS) · table (schema-qualified) · op (INSERT | UPDATE | DELETE) · columns_core (the sorted set of columns always written; optional columns listed separately as columns_variant) · selector (the key column(s) that pick the row — never the value) · discriminator (product code / object type / template name — the configuration axis the fix is scoped to) · value_class per column (constant | copied-from-other-system | operator-supplied). Actual ids and values are excluded, so two policies get the same signature.

Would it have grouped them? - KI-030 → INSIS · GEN_RISK_LIMITS · INSERT · {insured_obj_id, cover_type, policy_id, limit_type, limit_amnt, currency, limit_dimen} · selector policy_id · discriminator 2200/EXPENSE · constants — identical on all five tickets (and on the SD-1963 re-application after the retransfer). Grouped at the second ticket (SD-1963, 21.07) — five weeks before the root cause was written down on SD-2068. - KI-017 → IPAL · SRD_CUST.OBJ_CAR · UPDATE · core {regno, r_type} · variant {r_date} · selector sr_object_id · discriminator 4704/CAR · copied-from-INSIS — grouped (SD-1707, SD-1737, SD-1938) only because r_date is a variant column; a signature on the full column set would have split SD-1737 off. - KI-043 → shape A SRD_SYS.USER_ACCOUNTS · UPDATE · {current_branch} (SD-1917) versus shape B SRD_SYS.IC_USERS · UPDATE · {branch} (SD-2144): the table+column signature splits one mechanism into two families. They share the symptom (debit note stamped with the wrong P_OFFICE_ID) and the consumer (UserSessionService.ExtractSessionInfo → PrintSingleDocumentService), not the fix.

Resolution. P Adopt the signature above with columns_core/columns_variant split, and count a recurrence when two cases share (system, table, op, columns_core, discriminator). Treat the count as a trigger for the escalation rule (second identical fix → find the writer of the missing data), not as the family definition: the KI id, once assigned, is the family key, and a second signature key — the consumer code path that exposes the symptom — is recorded so that KI-043-type families (one mechanism, two fix shapes) are joined. Validated on KI-030 (grouped at ticket 2 of 5), KI-017 (grouped, needs the variant split), KI-043 (not grouped by fix alone — hence the consumer key).

RE-8 Retrieval mechanics and the two-independent-uses rule — the measurement and the v1 baseline — CH-50, CH-66, CH-69

Challenge. grep vs vector, and the promotion rule, cannot be judged without the platform — design the measurement and run the grep baseline now.

What I did. Designed the measurement and ran it: scripts/triage_baseline.py. The protocol, the numbers and the per-ticket table are § TB — one measurement, one home. What follows is what this pass adds to them.

Typical misses. SD-1969 (Клауза 002) actually returns KI-030 in its top 5, but counts as a miss because its analysis predates the KI and cites only the reference article — a truth-set artefact worth knowing (the hit-rate is a floor); SD-1858 / SD-1998 (framework extension, Bulgarian "разширение на рамков договор") return nothing because the one-liners are English; SD-2035 (13 truth items, all KIs) returns nothing. The two hits with a KI (SD-1941 → KI-018, SD-1836 → KI-051) came from product codes and system error words present in both the ticket and the title.

Resolution. - F The v1 grep baseline on the migrated one-liner index is 10 % hit-rate at top 5, 98 % false-precedent rate (30 held-out resolved tickets, protocol above, script reproducible). This is the number the retrieval decision of Agents Memory § 7.2 must beat; it also quantifies why v1 memory "did not fire" (Stage Precipitation challenge). - P Measure the alternatives on the same script by swapping only the index: (a) full article bodies instead of one-liners, (b) Bulgarian symptom aliases added to each entry, (c) a vector index (Qdrant or local embeddings) — same 30 keys, same truth, same metrics. Decide grep vs vector on the delta, as the pages say. - C The two-independent-uses promotion rule still cannot be measured: the corpus has no "use" events (which article an analysis actually relied on, versus merely linked). The held-out set above is the right sample; the missing data is a per-case "relied-on" mark, which the ledger will produce — the event named in the register stands.

RE-9 Whitelabel renderer — skill, platform service, or the analysis-HTML toolchain — CH-26

Challenge. Decide with the T0 work.

What I did. Inspected tools/analysis-assets/ (aisa_analysis.css 8.9 KB, aisa_analysis.js 6.9 KB, contract_clauses_bg.json 16 KB), read scripts/finalize_analysis.ps1 (129 lines), read aisa-next/10 Architecture/20 Configuration/contracts/validate_product.py (227 lines, JSON-Schema + semantic rules, fixtures folder) and the whitelabel specification's rendering rule, now Stage Normalization § WS-2.

Finding. - finalize_analysis.ps1 is a marker inliner for hand-authored HTML: it expands <!-- AISA:HEAD/CSS/JS --> and <!-- AISA:CLAUSE:<id> --> markers, computes the asset depth, is idempotent on re-run (scripts/finalize_analysis.ps1:6-22). It renders nothing from data. - validate_product.py is the only code next to the schema; it is Python, reads product.json, recomputes counts from the body, exits 0/1 — the shape of the S1→S2 gate. There is no renderer anywhere in aisa-next/. - The spec fixes the contract: product.json authored, product.md and HTML generated, never edited in place (Stage Normalization § WS-2).

Resolution — taken as D40: the renderer is a skill. The proposal below (a script beside the validator) is what D40 settled on, against the platform-service alternative of Solutions CH-26. P Build the renderer as a sibling Python script in contracts/ (render_product.py: JSON → product.md, and optionally → HTML that emits the AISA:* markers and is finished by finalize_analysis.ps1), invoked by the S1 stage skill right after validate_product.py. Reasons: one toolchain and one fixture set with the validator (the broken fixture must render too); the analysis-HTML assets are reused for the look without adopting a hand-authoring script as a renderer; a platform service has nowhere to run at T0 (Hosting CH-59…63 open) and the contract is unaffected — promote the same script to a platform endpoint when the UI needs on-demand rendering.

RE-10 /configure-product's twelve parts against the five stages — feeds CH-09

Challenge. Map every part to a stage; name parts no stage owns.

What I did. Read .claude/skills/configure-product/skill.md Step 3 (the twelve parts) and the five stage pages plus Configuration Module § 4.

Finding.

Stages also own things the skill does not list: S1 normalization (the specification itself), and S5 endpoints and core registration. Process registration moved to S3 IPAL (D86) — the process key and its task and role bindings belong to the policy product; authoring a BPMN is Development work at Hd.

Resolution. P Amend the stage pages: give Numbering and Documents/print explicit rows in the Stage Serdica surface table (with CFG_PRINT_DOCS cross-referenced from S3 where the product-documents LOV lives); assign Checks (7) to S3 — the tables are IPAL-side and the policy skill is the test that exercises them; assign Tariff request (6) to S2, since getRates cannot run without it; record 8, 9 and the optional five as outside the module — D85 then settled 8 and 9 as one PL/SQL script per product, with no stage, no sub-stage and no transferred proof rung — so every part in the skill has a written owner or a written deferral. Each is an amendment to the stage contract, now Configuration Module § 7.

RE-11 intentgpt — reachability and known seams — CH-05, CH-30, CH-49

What I did. ls C:\dev; .gitmodules on master (none); grep on master; grep + file list on the codex docs; grep in the local serdica-infrastructure clone.

Finding (10 lines). 1. The repository is not on this machine: C:\dev has no intentgpt checkout and serdica-backend has no .gitmodules on master; master mentions it only in tech-debt.md:537 and src/Analytics/riskmodel/run_request.py. 2. It is deployed as the image registry.ablera.dev/ablera/intentgpt (serdica-infrastructure docker-compose.serdica.yml:31, .gitlab-ci/configs/deploy-jobs.yml:217) — so the source is a GitLab project under ablera/ on gitlab.ablera.dev; the path is inferred from the image, not verified. 3. The codex branch carries 573 references in docs/; the dossiers are docs/architecture/health-ai/18-retirement.md, dossiers/d26-retirement.md, and reviews/intentgpt-main-convergence-2026-08-15.md (compares IntentGPT main at 5c518396b; treats it as "a behavior source, not a runtime dependency"). 4. Runtime seam: Python + MCP; Core reaches it through McpProxy — the mcp_proxy.* commands in core's appsettings (call_agent, get_agent_status, call_tool, bethos.*, agents.*, appsettings.json@master:178-231); McpProxy lives in docker-compose.serdica.yml. 5. Consumers (A04 inventory, 18-retirement.md): six UI callers + Core — claims agent-status.service.ts (starts the agent via Camunda, executionId = claimId), PNC pnc.service.ts, reinsurance import-treaty.service.ts, admin agents.service.ts and bethos.service.ts, and Core's MCP tool flows. 6. State seam: MongoDB collections agent_context / agent_session / agent_state plus the Bethos outreach collection; Qdrant as vector index (to be transferred to AI-Manager ownership). 7. Data seam: it mutated Claims directly through GraphQL (16-quality-and-rollout.md:53) and used live GraphQL introspection — both forbidden in the new design. 8. Document seam: its OCR library wraps Azure Document Intelligence (prebuilt-layout/-invoice/-receipt, 06-document-processing.md:49) with a hidden empty-result fallback the C# port removes. 9. Secrets committed in its repo: LLM_KEYS.OPENAI, OCR_MODELS.AZURE_DOC_INTEL, QDRANT.API_KEY, AZURE_BULSTRAD, TRANSLATOR.API_KEY — an immediate hygiene item independent of retirement; it also holds an ablera_insurance LOB mirror. 10. Retirement order: consumers exit → Proxy routes/clients → IntentGPT deployment/secrets → agent-Mongo export → CI guard; CAMUNDA_V1 stays deployable for rollback until then.

Resolution. F The seams above are established from the dossiers; C the repository itself remains unreached — closing needs a clone of gitlab.ablera.dev/ablera/intentgpt (path inferred), which is the "first intentgpt case" the register already names.

RE-12 Loop-back semantics — amend the plan revision or replan — CH-19

What I did. Grepped aisa-next/90 Reference/pc_agent_9951_artifact_extract.txt for resume / revision / re-entry handling and read the passages.

Finding. - The run leaves five working papers — "the plan, the write log, the run log, the build state, and the record of deliberate omissions … what make a run resumable rather than repeatable" (:167). - Re-entry after a failure: "Record completed steps and their returned ids to a state file, stop at the first failure, and resume by skipping what is done. Continuing past a failure manufactures orphans" (:4011; also :1200). - Re-entry on an existing product: "If a row comes back, you are looking at a revision, and the interesting question changes from what is this product to what is the delta" (:2215); "The commonest mistake is treating an update as a build: creating a second product, or rewriting configuration that was already right" (:588). - The gap found later is reconciled against the source document, not the live product, and every difference is either configured or written to MISSING.md with a reason (:640, :3387).

Resolution. P Rule: a re-entered stage amends, it does not replan. It keeps its plan and build state, takes the gap reported by the later stage as a delta item, appends plan revision n+1 (trigger = the gap's id, affected steps, unchanged steps marked kept), applies only the delta through the state file (skip-done semantics), and re-runs its test phase in full so the later stage receives a whole result. Replanning from scratch is reserved for a gap that falsifies a plan premise — one of the "three questions" (process fit, object codes, deployment scope) — and that is a gate to Source (Hd), not a loop-back. Every plan revision is a ledger event and a candidate amendment to the stage contract, now Configuration Module § 7. The 9951 run followed exactly this (state file + revision-as-delta); the rule generalises it.

RE-13 Summary

CE. The case census — what the three modules' work actually is

Taken 07.09.2026 to answer one question per module: are the "typical cases" the module pages carry typical, and what is the real recurring list. Three passes, one per module, each read-only; the reports with the full case lists and the census files are docs/aisa_next_use_cases_2026-09-07/01_data_and_information_cases.md, 02_development_cases.md, 03_configuration_cases.md; the case lists themselves are the three typical-cases pages. Every figure here is F measured 07.09.2026 unless tagged otherwise.

CE-0 Method

• Desk (CE-1). Every analysis HTML under jira_tickets/ (366 files in 362 folders + 16 flat files → 345 unique tickets of 540 folders; 126 bare and ~70 slugged folders carry no analysis). Per ticket a digest — title, created date, executive summary, § 5.1 root cause, § 7.1 internal note, and a regex count of UPDATE/INSERT/DELETE/MERGE — was classified into one primary shape (what the desk had to do) and one ending (write executed in IPAL / INSIS / both · proposed SQL left to Bulstrad IT, an operator or a held batch · UI action · none) by three Opus sub-agents, one at a time, over a 36-label vocabulary seeded from § TM-5; 19 of 19 spot-checks agree at shape level; 30 borderline rows flagged, none changing a verdict. Dates: 228 from the HTML, 83 from the snapshot date, 5 from Jira JSON, 30 legacy tickets interpolated from the ticket number. This is a different denominator from § TM (which counts what the customer asked for by keyword over 485 tickets) and must not be mixed with it.
• Development (CE-2). git log origin/bulstrad-staging --no-merges --since=2025-06-01 in serdica-backend (300) and serdica-ui (134), with --name-only per commit; shape = regex on subject + touched paths, spot-checked on ~180 rows (± 10 % between neighbouring shapes); "on master / on prod" = same id in git rev-list, else same subject since 2025-06-01; ticket linkage = SD ids in messages, then file names and same-day dates in the analyses, then git branch -r. Never a checkout; git ls-tree for file presence (git cat-file -e ref:path mis-reports under MSYS path conversion).
• Configuration (CE-3). See below — taken on STAGING (10.239.82.122 SRD_IPROD/SRD_ANLT, 10.239.82.123 ABC_ACCESS) against PROD, SELECT only.

CE-1 Desk — 345 analysed tickets by the shape actually worked

• The DB-write denominator re-read. § TM-7's 66 % counts analyses that contain a write statement; reproduced here as 213 of 346 = 62 %. The share of cases in which the desk itself executed a write is 42 %. Both figures stand; they measure different things.
• § TM-5 against CE-1. The keyword counts overstate most shapes two- to four-fold against what the analyses did (retransfer 112 vs 32; installments 30 vs 13; ИП setup 31 vs 9; print 50 vs 19; framework sync 13 vs 5) and keep the order; framework extension (14 vs 13) and MYR (25 vs 18–22) are close.
• Per month (analysed tickets): Mar 20 · Apr 60 · May 57 · Jun 71 · Jul 80 · Aug 51 (+4 outside). Declining: account/agent provisioning (7 → 2 a month), cargo framework sync (none since 26.06.2026). Rising: print (7 in August), status/period desync and restore-after-mistaken-cancel (from July), ЕИСОУКР (3 in August). Flat: MYR ≈ 3, cargo extension ≈ 2, installments ≈ 2 a month.
• Streams outside Jira: VIN corrections 6 Jira vs 12 OTRS mail threads + 1 HDesk; „куха полица" 2 vs 7 threads + 3 HDesk; ИП offices 9 vs 4 threads (stream counts from Challenge Rounds § R2-1).

CE-2 Development — the customer line since 01.06.2025

• Shapes (backend): reinsurance stream 84 (28 %) · small extension without ticket 51 · fix without ticket 37 · print 20 · riskmodel pricing filter 15 · product BPMN 14 · CI 12 · euro changeover 11 · prod → staging reconciliation 10 · master → staging port 9 · revert 8 · integration 8 · appsettings-only 6 · perf 4 · dependency 4 · tooling 3 · GraphQL schema 3 · ticketed fix 1. UI: fix without ticket 41 · extension without ticket 37 · bg number/locale series 14 · ticketed fix 11 · euro 7 · tooling 5 · i18n 4 · the rest 15.
• Lineage facts (git, verified 07.09.2026): .claude/rules/code-changes.md is on all four origin refs of both repositories (last touched 14.04.2026 on staging; blob differs from master's); bulstrad-test is the staging branch's former name (renamed 22.10.2025; backend ancestor of staging, UI diverges 29.10.2025); master/staging merge base 2a2bdbbca4 18.03.2025; staging/prod merge base f252a711b6 21.01.2026 with 111 staging-only and 52 prod-only commits since; UI bulstrad-staging force-rewritten 04.09.2026 (backup/bulstrad-staging-pre-rewrite-20260904); src/BusinessInsurance/* on master = 319 files, 0 .cs, on staging 2 259 .cs; 168 .bpmn files on staging.
• Timing: ticket → staging commit 0–1 day in 11 of 13 measured pairs (17 d SD-1863; 385 d SD-524); staging → prod the same day in 9 of 9 UI and 4 of 6 backend pairs (36 d SD-1863; never for the SD-1709 backend half, the flat rate and the FRAME series as of 07.09.2026); eight tickets in status Next Release have no matching commit (oldest SD-547, 14.07.2025).
• Deploy mechanics (from the staging .gitlab-ci): the image is built and pushed on push (branch = tag); .deploy_job runs the serdica-infrastructure Ansible playbook when: manual; configs/deploy-jobs.yml names only demo2 and marketing-demo — the Bulstrad targets live in serdica-infrastructure (D130).

CE-3 Configuration — STAGING against PROD, twelve months

Connections BST-TEST-IPAL-SRD_INTEGR, BST-PROD-IPAL-SRD_INTEGR, BST-TEST-INSIS-INSIS (the ABC_ACCESS schema read through the INSIS user's grants — no BST-*-INSIS-ABC_ACCESS connection exists in this workspace), BST-PROD-INSIS-ABLERA_SUPPORT; SELECT only; no @insis distributed query. SRD_IPROD has no audit column on any of its 81 tables; recency comes from three signals — ALL_TAB_MODIFICATIONS (DML since the last statistics gather, per table 2023–2026, flushed irregularly), block-level ORA_ROWSCN bucketed into months by a calibration table (TEST SRD_CUST.SR_USER_NOTES.TSTAMP; PROD POL_ANNEXES / ACCS_POLICIES) — an upper bound, a row counts in the month its block was last written — and a TEST ↔ PROD COUNT(*) + SUM(ORA_HASH(business columns)) diff over 113 tables per product (IDs excluded on the 30 hand-listed tables; JSON_OBJECT(*) hashes on ~60 small tables include IDs and over-report "content differs"). SRD_ANLT.PPA_PRODUCT_VERSIONS carries real dates. The full month × table-group tables, the per-product diff and the SQL are in docs/aisa_next_use_cases_2026-09-07/03_configuration_cases.md § 1 and § 6.

• STAGING row-blocks last written, twelve months, by group (upper bound): ABACUS tariff 38 121 (10.2025 EUR wave 19 494; 07.2026 5 778) · pricing factors 11 871 · numbering/BSO 11 249 (the 09.2025 policy-year roll) · catalogue/covers 5 756 · mapping IPAL↔INSIS 5 114 · offers 2 048 · validations 1 893 · routes/roles 1 146 · prints 535 · commission 40. Top products: 4704 12 775 · 4710 5 177 · 3443 5 141 · ALL 3 706 · 2200 3 673 · GLOBAL 3 277 · 2214 3 154 · 3618 2 552 · 2222 2 445 · 3602 2 443.
• INSIS TEST (ALL_TAB_MODIFICATIONS): CFG_GEN_COVER_RULES 10 ins / 2 527 upd (30.07.2026) · CFG_GEN_RISK_LIMITS 2 / 621 · CFG_DISCOUNTS 118 ins (1 583 rows, all keyed by CLIENT_GROUP, 0 by CAMPAIGN_ID) · CFG_QUEST_QUESTIONS/ANSWERS/REFS 22 / 52 / 22 ins (21.07.2026) · CFG_PRINT_DOC* 19 + 89 + 38 + 21 (06.08.2026) · HT_INSR_TYPE 1 ins / 20 upd · CFG_GEN_TARIFF_* 139 deletes (INSIS-native clauses retired as ABACUS takes over). 2345 exists on INSIS TEST (HT_INSR_TYPE, AB_CFG_RATE_ABC_ON); 3606, 3410 and 1105 exist in no INSIS environment.
• Intake, HDesk (42 configuration tickets, every _cached_view.html read): validation 10 · tariff 10 · discount 6 · questionnaire 4 · nomenclature 3 · new product 2 · new clause 2 · promo 1 · visibility 1 · other 3; INSIS or МАТРИЦА named as target in 38 of 42; ask → first TEST delivery 0–1 day (desk, INSIS), 8–24 days (Ablera, both systems), 56–155 days (cross-system), 287–496 days (ABACUS + IPAL twins, nomenclatures); PROD arrival confirmed 3 of 42; „очаква доработка" 20 of 42; twelve explicit waiting complaints; no ticket mentions an offer or CR.
• Intake, Jira (68 tickets, analyses read): kinds — validation relax-and-revert 10 · print defect explained 9 · print data fix 6 · discount rule 6 · numbering 5 · nomenclature 5 · validation permanent 4 · print template configuration 4 · label 4 · BSO 4 · LOV add 3 · cover limit 3 · promo 1 · other 4. Environment applied: PROD 31 · none (proposed or explained) 20 · TEST 7 · both 3 · unclear 7. Executor: Ablera IT 25 · a person running AISA-drafted SQL 14 · Bulstrad IT 11 · none 15. Elapsed to PROD where dated (n = 32): 26 on day 0, 4 on day 0–1, one in 6 days. Recurrence: 30 of 68 name an earlier identical case. About eleven a month, flat 03–08.2026. Most-written tables: CFG_ABC_FLD_VALIDATION 9 · CFG_PRINT_DOCS 8 · CFG_FLD_VALIDATION 7 · CFG_POLICY_NO_SEQ 5.
• The code half (from CE-2): product BPMN 11 commits (5 on prod), riskmodel pricing filters 12 (11), print selectors 14 (9), Add configurable policy date checks with .sql (17.07.2026), a per-product engine toggle (05.2026, reverted). Every new product on the customer line needed a plugin commit.