Operational method evidence

P This is the sourced catalogue of recurring operational shapes behind Data & Manipulation. Counts describe the archived workload, not the number of installed v2 skills. Current method definitions are on Agents and methods.

Recurring case shapes

Evidence base F: the archive of 03.09.2026: 513 ticket folders, 340 of them with a written analysis; 485 unique Jira tickets (the 03.09 recount gives 486); the effort row uses 331 tickets (request-side keyword rules over summary + description, analysis-side token rules over the analysis HTMLs, effort class inferred from analysis size and comment count) — full method, tables and caveats in Measurements § TM; scripts scripts/mine_tickets_extract.py, scripts/mine_tickets_classify.py.

The denominators, once F. Six different counts appear on this page and none is interchangeable with another — the runs behind them are Measurements § TM and § TT, plus the 03.09.2026 archive pass; every share below names which one it is a share of, and “analysed tickets” is never written without its label:

What the tickets are F

Corrections close in a day or two; configuration and master-data requests take 9–11 days — five to ten times longer — which is the Configuration module's case in one row. 148 tickets sit in Pending with no resolution date (Measurements § TM-3), so the medians rest on the 175 the customer explicitly closed. Shares above are of the 485 unique Jira tickets, except the corrected configuration-change row, whose 74 is a count across three streams. No combined working-set figure is stated, because no measurement produces one — the streams are counted separately.

220 of 333 — the DB-write denominator above — end in a database write (03.09.2026 archive; the 02.09 run measured 219 of 332 = 66 %). Most "data corrections" are consequences of transfer defects — the two classes overlap, which is why the retransfer skill and the sync-compare skill sit at the top of the list below. Contract classification on the 322 of the 332 analysis HTMLs of the 02.09 run that carry a classification block (Measurements § TM-4; pre-correction Jira counts): §1 Standard 296 · §2 Personalizations 19; Sev 3 151 · Sev 4 43 · Sev 2 16 · Sev 1 3; L2 204 · L1 113.

The catalogue P

Ordered by tickets that asked for the shape. Now / with skill are hours over the mined archive (≈ six months of dense coverage), computed from the inferred effort distribution with trivial = 15 min, routine = 30 min, investigation = 2 h, multi-day = 8 h, and with the skill taking the mechanical part down to 5 / 10 / 45 min and leaving multi-day cases unchanged. They are estimates to be replaced by the ledger (Value and ROI § 4); their use is ranking, not accounting. Calibration F: the classes match the analysis authors' own estimates (median 2.0 h per ticket), not the true time of a skilled person — 25 % of that by the flat rule, raised to about 31 % (median 0.63 h) by the D54 adjustment — so read the saving as estimate-hours, or take roughly a third for true hours; times vary by domain and person (Value and ROI § 2b). Hours only; provider usage is a control, never a metric (D117). The bus-factor and parallelism arguments do not scale down with it. Holders with ≥ 2 tickets is measured from the Jira Internal Tag on 267 tagged tickets (D115), not proposed — the table of holders below is the source, and it supersedes the judgement flags the catalogue carried before. Skill #1, the customer conversation, is the desk's and sits in Support Root § 0.2; the shapes below are the working stages'.

Reading the table honestly. Two thirds of the hours sit in investigation and multi-day cases, which a skill shortens but does not remove — the saving there comes from precedent retrieval and the isolated validator, not from packaging. The skills' own contribution is the ~625 hours of mechanical work per six months, roughly 1 250 hours a year, and — more important than hours — the holders column: it now carries the measured count of people with two or more tickets on the shape (D115), not the team's earlier judgement flag; the seven thin shapes are marked in it and listed below.

Knowledge holders, measured from the Jira Internal Tag F

Vladimir's instruction (02.09.2026): the bus factor is read from Jira, not guessed — the Internal Tag (customfield_10110) on each ticket names the person who worked it. Measured over the newest snapshot of 438 tickets: 267 carry a tag; the people are Georgi 132, Vlad 52, Mira 45, Reneta 18 (and AISA on 176). Per skill shape below: tickets matching the shape, how many of them carry a person tag, how many distinct people, how many people with at least two tickets on the shape (the bus factor: 1 = one head, 2 = thin, 3+ = shared), who, and the leading person's share.

Who the names are (roster): Georgi = Georgi Stoyanov, the ServiceDesk operator; Vlad = Vladimir Moushkov; Mira = Branimira Damyanova; Reneta = Reneta Ekimska — all Ablera IT. Who controls what: Georgi leads 33 of the 35 shapes with a tag — ≥ 50 % of the tagged tickets on 25 of them and 37–47 % on the remaining ten (D115) — of the tagged tickets; Vlad leads one (VIN / registration-number corrections, 43 %); Mira leads one (cargo text corrections, 57 %). Domains effectively under one person (the second person has fewer than two tickets): office/issuer codes on debit notes, customer reports and extracts, person/company policy lookups, vehicle make/model additions — all Georgi's. Thin domains (two people at most): Kibana log tracing (Georgi 21, Vlad 2), policyholder/insured swaps (Georgi 16, Vlad 5), cargo text corrections (Mira 4, Georgi 3). Four plus three is seven — the thin-shape count of the reading below. Georgi's highest concentrations are Kibana tracing 87 %, product-role grants 75 %, Camunda/process items 73 %, agent/office setup 72 %, office codes 70 %, policyholder swaps 69 %, MYR repairs 66 %, ЕИСОУКР checks 65 %. Note the measurement's limits: the tag names who worked the Jira ticket, which understates Vlad and Mira where they executed the INSIS or PL/SQL side under the shared account, and it says nothing about who could work a shape.

Reading it. Lead share is ≥ 50 % on 25 of the 35 tag-bearing shapes; it is 37–47 % on the remaining ten — policy sync (37 %), getRates, LOV, validation threshold, BSO, VIN, framework extension and sync, 1103 and FX (D115). Thin shapes — seven (≤ 2 holders with ≥ 2 tickets): Kibana trace, policyholder swap, office/issuer code, cargo text, report/extract SQL, person/company lookup, vehicle make/model add. The blank/GC/sticker (BSO) shape is not thin — the table gives it four holders (Georgi 11 · Mira 5 · Reneta 4 · Vlad 3) — which is the erratum to D115's “eight”. The proposed flags in the catalogue are superseded by this table; the build order below holds — the five largest shapes are also concentrated on one person. Script: scripts/mine_tickets_holders.py; source data jira_tickets/*/SD-*_ticket_*.json field customfield_10110.

Order of building P

One list, and it is Data & Manipulation components § 5 — four build groups: the five largest shapes, then volume with knowledge already shared, then the measured thin shapes, then the tail on the 3 / 7 / 20 ladder (Stage Precipitation § 2). Two things this page adds to it:

• VIN / registration corrections move into group 1 — 16 → 29 tickets once the OTRS mail stream is counted (D59).
• The Configuration stage test skills are not Support shapes. They gate the configuration slice in Delivery T2 and are built there (Configuration Module § 0.2).

Tools. The read connectors — oracle-ipal, oracle-insis, kibana, the rating gateway's getRates (it computes and stores nothing) — per environment scope; the browser for the customer's own surface at verification; writes only through the platform's effect applier under a grant, past the effect applier (Gating § 6). What each connector operation does, and what it does on a timeout: Data & Manipulation components § 6.