Data and Information Module

The former Support module's working stages. A request the desk has identified as a data correction or an answer is investigated across every system it touches, resolved by the right kind of solution — a skill run, a memory answer, or a combination — applied under a grant after a person confirms, verified on the customer's surface, and precipitated into what the next case will reuse (decision Vladimir, 04.09.2026 — D144). Methodologies and past experience live in the support/* memory domains (§ 0.1); this document is the process.

The flow, as the product page draws it. Solution take — is there a ready solution? then: skill · memory · combination; a person decides. Investigation — only if no ready solution: the databases, the source code, or both; nine fixed mechanics with a required output each; an isolated agent re-derives the mechanism from the evidence alone. Confirmation — one packet: the statement, its counts, the revert, the replay; gate H3. Application — writes under an execution grant bound to the H3-approved packet and the applicable effect decisions, H5 where the target is customer-facing; sends through the gate. Verification — the customer's symptom on the customer's surface; a signed result. Reversal — only on a problem: the standing revert, on a human decision. After the workflow: Precipitation — skill · article · experience entry; it does not wait for the customer's closure, and the consolidation pass runs on schedule. Investigation is what happens when there is no ready solution: a case an existing skill covers, or one memory and the experience index answer, goes from the desk straight to the take and never investigates — which is the whole point of precipitating recurring work into skills.

P It runs under the same root as the desk. support.root decides whether and who; these stages decide how. The module keeps the profile and memory names it had as the Support module — support.*, support/, the identifiers the stage pages and the components inventory cite — and changes nothing about them (D144). A case that turns out to be configuration or code after all goes back to the root, which raises the handover.

Stages: S2 Investigation · S3 Solution Take · S4 confirmation — gate H3 on the packet · S5–S7 Application, Verification, Reversal · S8 Precipitation.

0. The agents

P Family expertise: multi-year motor and cargo are tagged skills, assertion packs and evaluation cases owned by support.investigator.transfers under its existing node; pricing/printing consult that owner for family judgement. No profile is created per case. Case journeys traces DC-01…DC-24, including external INSIS actors, whole-family proof and the temporary-versus-permanent configuration boundary.

P The tree. Six investigators profiled by symptom family over one shared set of mechanics; a verifier given the evidence and neither the transcript nor the reasoning — the direct countermeasure to v1's three retraction cycles; a resolution agent that owns the packet and the re-check; the platform's write executor as the only writer and its auditor as a mandatory independent checker; a curator as the only writer of shared memory.

flowchart TB
  R["support.root"]:::owner
  S["Resolution: known solution?"]:::work
  I["Domain investigator"]:::work
  K["Family skills and
reviewed experience"]:::learn
  V["Independent verifier"]:::proof
  P["Resolution packet
S3–S7"]:::work
  G["Audit, required gates
and execution"]:::decision
  C["Curator and domain owner"]:::learn
  R --> S
  K -.->|"check applicability"| S
  S -->|"unknown mechanism"| I
  I --> V
  V --> P
  S -->|"proved known path"| P
  P --> G
  G -.->|"verified result"| C
  classDef work fill:#eef4ff,stroke:#6889ba,color:#17365b,stroke-width:1.3px
  classDef decision fill:#fff4df,stroke:#b78c36,color:#65470d,stroke-width:1.5px
  classDef proof fill:#e9f5ef,stroke:#689b81,color:#224e39,stroke-width:1.3px
  classDef learn fill:#f1edf9,stroke:#9580b9,color:#534172,stroke-width:1.3px
  classDef store fill:#f5f7fa,stroke:#98a6b7,color:#34445a,stroke-width:1.2px
  classDef owner fill:#24486b,stroke:#24486b,color:#ffffff,stroke-width:1.4px
  click R href "support-module.html" "The existing desk root retains the customer case."
  click S href "stage-solution-take.html" "Use a compatible skill or checked answer; otherwise investigate."
  click I href "stage-investigation.html" "Transfers, pricing, printing, access, health or master data; family expertise is owned knowledge."
  click K href "../50-agents/agents-memory.html" "Multi-year/cargo invariants and prior mechanisms are hypotheses until checked."
  click V href "stage-investigation.html" "Receives the evidence and required assertions, not the investigator transcript."
  click P href "stage-solution-take.html" "Actor, target, complete family scope, expected result and reversal."
  click G href "../gating.html" "Auditor and executor have separate responsibilities; effects include forms A, B and E."
  click C href "stage-precipitation.html" "Record actual outcome and propose improvements; no automatic write authority."

The agent graph separates reasoning, independent verification and deterministic execution. A known solution avoids rediscovery, not current scope or proof.

Standing rules on the edges [F: the PC 9951 run]: after two failed attempts at an unknown write contract, stop and ask the owning agent; a sub-agent's convenient "missing/inaccessible" that contradicts established evidence is re-asked with the how, not believed. Isolation is provisioning — the verifier's scope contains no author transcript (Agents § 0.2).

P Investigators are profiled by symptom, not by system (Stage Investigation § 2): a customer reports a symptom and never a system. System knowledge lives in the connectors/* and configuration/* domains, which every investigator reads and none owns. The six are six independent build tracks: one prompt skeleton — the nine mechanics as phases (Components — Support § 4) — and a domain and an eval corpus each.

Profiles in full — what each boots from, writes, may use, is denied: Components — Support § 3.

P Model route — EU-resident models only (SG-9; Agents § 0.3). Every profile in this tree reads the customer's personal data, so none may be routed to a non-EU model; the route is part of the profile, and non-EU model calls are a metric with target 0 (D111).

0.1 Its branch of the memory tree

support/
├─ methodologies/AGENTS.md   the inherited v1 discipline catalog — the nine mechanics as articles behind the phases
├─ investigators/<symptom>/AGENTS.md  one named node per investigator
└─ experience/AGENTS.md      the past-case index (Agents Memory § 5) — read by every module, written only here

0.2 Skills and tools

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 Module § 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 verifier, 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 Components — Support § 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 write executor under a grant, past the write auditor (Gating § 6). What each connector operation does, and what it does on a timeout: Components — Support § 6.

1. The stages

flowchart TB
  S["S3 Select the solution"]:::work
  I["S2 Investigate
and verify mechanism"]:::work
  G["S4 Confirm the packet"]:::decision
  A["S5 Platform action"]:::work
  E["External or customer action"]:::store
  V["S6 Whole-scope proof"]:::proof
  X["S7 Reversal or
due restoration"]:::decision
  D["Deliver actual result"]:::proof
  L["S8 Retain and improve"]:::learn
  S -.->|"investigate if needed"| I
  I -->|"mechanism established"| S
  S --> G
  G -->|"platform owns action"| A
  G -->|"person owns action"| E
  A --> V
  E -->|"response is evidence"| V
  V -.->|"failure or restore due"| X
  V -->|"all obligations pass"| D
  D -.->|"queued learning"| L
  classDef work fill:#eef4ff,stroke:#6889ba,color:#17365b,stroke-width:1.3px
  classDef decision fill:#fff4df,stroke:#b78c36,color:#65470d,stroke-width:1.5px
  classDef proof fill:#e9f5ef,stroke:#689b81,color:#224e39,stroke-width:1.3px
  classDef learn fill:#f1edf9,stroke:#9580b9,color:#534172,stroke-width:1.3px
  classDef store fill:#f5f7fa,stroke:#98a6b7,color:#34445a,stroke-width:1.2px
  classDef owner fill:#24486b,stroke:#24486b,color:#ffffff,stroke-width:1.4px
  click S href "stage-solution-take.html" "Answer, skill, repair, combination or a different module."
  click I href "stage-investigation.html" "Only when a current compatible solution is not established."
  click G href "../gating.html" "The reviewed plan and every applicable effect permission."
  click A href "stage-application-and-verification.html" "Execute exact granted operations; retain call and effect identities."
  click E href "../case-protocol.html" "Send the scoped instruction, wait, then verify the returned evidence."
  click V href "stage-application-and-verification.html" "All required family members, layers and customer surfaces."
  click X href "stage-application-and-verification.html" "H7 on committed compensation; unknown effects must be reconciled first."
  click D href "support-module.html" "A script, answer and operational repair have distinct completion rules."
  click L href "stage-precipitation.html" "Queue before resolution; confirmed knowledge changes the next request."

Writes are one possible path. External reports, partial family repairs and pending restoration cannot be mistaken for a completed operational request.

P Investigation is entered from the take, not before it (decision Vladimir, 03.09.2026 — D83). A case whose answer already exists — an existing skill covers the operation, or memory and the experience index answer it — goes S1 → S3 and never enters S2. A case whose answer does not exist leaves S3 by the no ready solution edge; S2 works the databases, stored code, or both until the mechanism is established and the isolated verifier agrees; the take is then made on evidence. Why it matters beyond the picture: an unconditional investigation stage makes every known question pay for a re-derivation it does not need, which is the opposite of what precipitation (SG-3) exists to achieve.

P Stage ids name the stage documents, not a running order (D83). S2 is the investigation document whether a case enters it first, later, or never.

P S4 confirmation is gate H3 on the solution packet — the packet is presented as the plan at H2 (S3) and confirmed at H3 (S4); Stage Solution Take § 3, Gating § 1 (D102).

P Where the working stages end. S6 is the signed result the desk's closure reads — the customer's symptom re-checked on the customer's surface (Stage Application and Verification § 2, § 4); closure itself is the desk's and the customer's (D49). S8 runs after the workflow: it does not wait for the customer's closure (Stage Precipitation), and its consolidation pass runs on schedule (Stage Precipitation § 6). The states are those of Gating § 1b (D148).

2. Sample case — the working part

The print case of Support Module § 4, from the moment the route sends it here. S3: the precedents are close but not this product's template — no ready solution. S2: the printing investigator runs invocation-first (did the print engine run at all), then the config trace; the verifier, given the evidence and no transcript, confirms: a template-config cell, not code. Back at S3: combination — fix the cell now, and since this is the second identical manual fix, propose the configuration-gap escalation. S4: the human confirms both on one packet. S5: the 5-step fix; the replay shows the document renders. S6: the customer's exact print action re-verified — the signed result. The escalation and the verified result return to the root, which raises the Hd and sends the reply. S8, after the workflow and without waiting for the customer's confirmation: experience entry + checklist extension — which re-runs the module's eval set.

The typical cases F. The sample above is one walk; the recurring shapes of this module's work — 24 of them, counted over 345 analysed tickets on 07.09.2026, with the multi-year 4704 family (18–22 tickets) and the cargo 110x family (33) among the top five — are on Typical cases, together with the verdict on the ten Case Studies (four typical as written, three recurring in another form, three architecture tests) and the eight challenges the real cases raise against this page: writes are a 42 % ending and „proposed" has no case state; INSIS writes split into grant-side DML and Bulstrad-IT operations; the customer is sometimes the executor; family repair needs an invariant, not a replayed query; the two product families need named investigator sub-domains; recurrence should count the trigger; the temporary configuration cell needs a boundary rule; the OTRS mail stream carries whole shapes.

3. Evaluation

Replay corpus: resolved cases (ticket + evidence snapshot in; mechanism + fix shape as reference), graded by the isolated verifier profile on mechanism match, fix safety, and what the candidate flagged as missing; seeded from the v1 corpus (509 analyses, frozen baseline 31.08.2026; 56 KIs); re-runs when support/* domains, methodologies, or model routes change.

Challenges

• P Effort classes are inferred, not measured. The ledger replaces them after the first month; until then the catalogue ranks, it does not budget.
• P Bus-factor flags are proposals. The team names the holders per shape once; that list is the argument for the order of building.
• C The HDesk and mail streams — counted 02.09.2026 (Challenge Rounds § R2 § 1) F: hdesk/ is the OTRS queue "Ablera", the customer's product-change and CR queue — 39 of its 52 tickets are Configuration-module intake, not support; the OTRS support stream reaches the workspace as 30 notification mail threads in emails/. Corrected "tickets asked": VIN / registration corrections 16 → 29 (moves into build group 1), sync compare 32 → 42, ИП office setup 31 → 35, pricing check 21 → 27, configuration change 32 → 74. P Two rules follow: the HDesk connector's intake is the queue, and the notification mail is a duplicate channel deduped on the OTRS number; a case opened from the "Ablera" queue is classified at the desk's S1 as a configuration request by default and handed over (D143 supersedes the channel default of D59). C kept: re-count on a full read-only export of the queue before the first eval set.