Components — Support module
Purpose
Support Module — the root module: intake, classification, the route, closure — and the Data and Information Module — its working stages S2–S8 (D143, D144) — say what the two do, and the five stage pages say how each stage works; both share the support.* profiles and the support/ memory branch inventoried here. This page says what has to be built: every component, its kind, what it consumes and produces, how it is proved done, and who can build it without waiting for anyone else. It is the phase-1 deliverable for this module and the work breakdown for phase 2 (Delivery § 1, Delivery § 1.4).
The six component kinds are defined once, in Components — Configuration § 0: agent · skill · projection · contract · connector operation · memory domain.
What makes this module's breakdown different from Configuration's. Configuration is a pipeline with five ordered stages and one artefact travelling through them; its components split by stage. Support is a routing organisation: one intake, a classification that decides the route, investigators profiled by symptom rather than by system, and a solution chosen by kind. Its components therefore split by symptom domain and by shape — and the largest single body of work is not an agent at all, it is the 35 catalogued ticket shapes that become skills (Data and Information Module § 0.2, where the catalogue lives since D145).
1. The map
flowchart TB C["Typed case contracts"]:::store A["Published agent profiles"]:::work S["Executable skills"]:::work G["Auditor, gates and grants"]:::decision X["Connector execution"]:::work P["Proof and delivery"]:::proof M["Experience and evaluation"]:::learn C -->|"validated input"| A A -->|"invoke"| S S -->|"effect proposal"| G G -->|"authorised operation"| X X -->|"recorded result"| P P -.->|"learn after result"| M M -.->|"published revision"| A 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 C href "../contracts.html" "Inputs, selected plan, obligations and signed result contracts are built first." click A href "data-and-information-module.html" "triage; resolution; six investigator domains; verifier, communicator and curator" click S href "../50-agents/agents-memory.html" "Deterministic procedures and assertions; no target permission is inherited from a skill." click G href "../gating.html" "Every applicable requirement is bound to the current proposal." click X href "../contracts/Connectors.Abstractions.cs.html" "Registered read operations and separately granted effects use their own recovery form." click P href "../case-protocol.html" "Verify the complete requested target and any external dependencies." click M href "../50-agents/agents-memory.html" "Record outcome; evaluate proposed knowledge or skill changes before reuse."
Support and data component responsibilities. The tables below enumerate each profile, skill and connector; this map shows their contracts and handoffs.
2. Contracts
| Component | What it fixes | Done test |
|---|---|---|
| The normalised arrival | what a connector hands the case whatever the channel: reporter, subject, body, referenced policy and object ids, attachments, arrival time, origin key (channel plus external id) | a HelpDesk ticket and its Jira mirror produce one case, not two (Stage Classification § 4). Draft normalised-arrival.schema.json (D139) |
| The solution packet | what the human decides on: the mechanism in one sentence with its layer named and the verifier's independent agreement, the chosen kind and the rejected alternatives, the exact change with expected row counts, the revert path and effect classes, the replay, what remains uncertain, the predicted minutes (D135) | a holder of the role can decide from the packet alone, without opening the transcript (Stage Solution Take § 3). Draft solution-packet.schema.json |
| The experience entry | symptom signature (customer phrase plus system error, verbatim) · systems and environment touched · mechanism found, layer named · fix shape · links · reusable artefacts; no personal data | a held-out case retrieves the entry that covers it (Agents Memory § 7.3). Draft experience-entry.schema.json |
| The handover packet | request → response → completion for Hd to Configuration or Development (Agents § 5, D142) | the receiving root plans from the packet alone; the support case owns closure. Draft handover-packet.schema.json |
3. Agents
P The graph — who spawns whom, which sub-agents are isolated, and where the write path runs. The table under it carries every profile in full; the platform-wide profiles these draw on are Agents § 1.
flowchart TB R["Support and data root"]:::owner P["Planning and specialist tasks"]:::work K["Own index and
selected domain knowledge"]:::learn T["Typed plan and result papers"]:::store V["Independent review"]:::proof G["Required decisions"]:::decision E["Execution coordinator"]:::work R -->|"assign bounded task"| P K -.->|"context"| P P -->|"propose and report"| T T -->|"independent evidence"| V V -.->|"verdict"| R T -->|"reviewable packet"| G G -->|"permit"| E 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 "data-and-information-module.html" "The root owns the bounded objective and confirms child plans." click P href "data-and-information-module.html" "triage; resolution; six investigator domains; verifier, communicator and curator" click K href "../50-agents/agents-memory.html" "Read compatible knowledge; consult its owner for judgement; write only in owned domains." click T href "../case-protocol.html" "Task text, evidence, scope and completed assertions remain durable." click V href "../50-agents/agents.html" "The verifier or reviewer receives scoped evidence without the author's transcript." click G href "../gating.html" "Root presents unresolved scope and permission decisions; it cannot invent authority." click E href "../50-agents/agent-runtime.html" "The deterministic handler applies only a current permitted packet."
Task ownership and review: a profile is reusable across cases. Each task has its own parent, inputs, evidence and restricted tool catalogue; the root remains responsible for the result.
P Model route — EU-resident models only (SG-9; Agents § 0.3). Every profile in the table below works 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).
| Agent | Owns, and its hardest judgement | In → Out | Memory (boots from → writes) | Tools (env scope) | Denied | Escalates | Eval set |
|---|---|---|---|---|---|---|---|
support.root |
the case, its gates, the four conditions of resolved, the handovers — when a case stops being support and becomes a configuration or code sub-case | normalised arrival or operator → case; stage results → gates H1 (classification), H2/H3 (solution packet), H5 (customer-facing environment), H5-send (customer-visible send), H7, Hd; closes with the four conditions | support/ |
none directly | write executors | the human | resolved cases → the same gate sequence and the same handover decisions |
support.triage |
S1: request type, contract position, severity, the two clocks, dedup, the precedent set — the type, before severity — it decides the route (Stage Classification § 2) | arrival → type, contract class, severity, SLA clock, dedup verdict, precedent set (as hypotheses) | support/experience → support/experience (proposals — confirmed by the curator) |
none (memory only); dedup query on CASES |
connectors | root | the mined tickets → type and severity, scored against the analyses' own classification |
support.investigator.transfers |
the largest symptom family: transfer and sync failures between the two policy administrations, cancellations, multi-year, ownership annexes — which side is wrong when both sides disagree with the customer | the classified case — symptom, systems, environment, contract classification — plus the precedent set from S1 → the mechanism in one sentence with its layer named, the evidence supporting it, what was ruled out and how, the open items that remain, and the isolated verifier's verdict (Stage Investigation); mechanism family: transfer and sync state and the mapping between the two policy administrations | support/investigators/transfers |
reads via connectors (oracle-ipal/oracle-insis read, kibana) and diagnostic skills |
write executors | root | resolved transfer cases → the mechanism, graded against the recorded one |
support.investigator.pricing |
premium, discounts, loadings, deductibles, commission — whether the applied value or the fed factor is wrong F: [applied LD ≠ fed factor] | the classified case — symptom, systems, environment, contract classification — plus the precedent set from S1 → the mechanism in one sentence with its layer named, the evidence supporting it, what was ruled out and how, the open items that remain, and the isolated verifier's verdict (Stage Investigation); mechanism family: the rating input versus the applied value | support/investigators/pricing |
reads via connectors (oracle-ipal/oracle-insis read, kibana) and diagnostic skills |
write executors | root | pricing cases |
support.investigator.printing |
document production and template configuration — invocation before configuration: did the engine run at all | the classified case — symptom, systems, environment, contract classification — plus the precedent set from S1 → the mechanism in one sentence with its layer named, the evidence supporting it, what was ruled out and how, the open items that remain, and the isolated verifier's verdict (Stage Investigation); mechanism family: invocation, template configuration and the print gates | support/investigators/printing |
reads via connectors (oracle-ipal/oracle-insis read, kibana) and diagnostic skills |
write executors | root | printing cases |
support.investigator.access |
accounts, roles, agent and office provisioning — which layer of the account chain is missing | the classified case — symptom, systems, environment, contract classification — plus the precedent set from S1 → the mechanism in one sentence with its layer named, the evidence supporting it, what was ruled out and how, the open items that remain, and the isolated verifier's verdict (Stage Investigation); mechanism family: the layer of the account chain that is missing | support/investigators/access |
reads via connectors (oracle-ipal/oracle-insis read, kibana) and diagnostic skills |
write executors | root | access cases |
support.investigator.health |
the health product family, its provider reports and enrolment — data that is special-category, so handle-substituted wherever the task does not need the individual (D33) | the classified case — symptom, systems, environment, contract classification — plus the precedent set from S1 → the mechanism in one sentence with its layer named, the evidence supporting it, what was ruled out and how, the open items that remain, and the isolated verifier's verdict (Stage Investigation); mechanism family: enrolment, provider reports and settlement in the health family | support/investigators/health |
reads via connectors (oracle-ipal/oracle-insis read, kibana) and diagnostic skills |
write executors | root | health cases |
support.investigator.master_data |
vehicles, blanks, nomenclatures — whether the value exists in all three nomenclatures | the classified case — symptom, systems, environment, contract classification — plus the precedent set from S1 → the mechanism in one sentence with its layer named, the evidence supporting it, what was ruled out and how, the open items that remain, and the isolated verifier's verdict (Stage Investigation); mechanism family: presence and agreement of a value across the three nomenclatures | support/investigators/master_data |
reads via connectors (oracle-ipal/oracle-insis read, kibana) and diagnostic skills |
write executors | root | master-data cases |
support.verifier isolated |
the independent mechanism, from the evidence alone — disagreement is not "the agents disagree" — it is what evidence separates these two mechanisms | evidence + symptom → independent mechanism → Verdict |
support/methodologies → none |
the same read connectors | author transcript and identity; evidence provenance retained | root (disagreement returns the case to S2 with the separating evidence) | the three retraction cases: the verifier must disagree with the retracted mechanism |
support.resolution |
S3–S7: the kind, the packet, the dry run, the execution after approval, the re-check, the standing revert — a first occurrence gets the correction; a repeat proposes the configuration or code path as well | classified case → ready solution? — if not, the case goes to S2 and returns with a verified mechanism → solution kind (skill / memory / configuration / the Development module (id source) / combination) + packet (statement, counts, revert, replay); after approval → runs the write executor; S6 re-check on the customer's surface |
support/methodologies → none |
dry-run via write executor; skill runner | direct writes | root; Hd for configuration/development kinds | packets → the kind chosen and the counts asserted |
support.communicator |
the customer-visible drafts and the gated sends — the register — what a customer reads, with no table name and no row count in it | packet + result → BG public reply, internal note, transition via Pending; re-identification request for names in the draft (audited) | support/ (register rules) → none |
jira comment (internal free; public gated), mail send (gated), transition (gated) | DB connectors | root | resolved cases → drafts graded against the sent replies |
support.curator |
S8: the precipitation decision, the closing walk, the scheduled consolidation — whether a shape has recurred enough to be mechanised, and whether an entry would help a stranger | case after S6 verification → mandatory experience entry plus at most one optional result (skill / article / index / nothing), closing walk reconciled; scheduled dreaming pass | support/experience → own; support/methodologies → proposal to support.resolution — the only profile that confirms proposals into them (Agents Memory § 2 rule 7) |
none | connectors | root; skills go through governance | closed cases → the decision the reviewer would have made |
P Investigators are profiled by symptom, not by system (Stage Investigation § 2): a customer reports a symptom and never a system, so shaping the agents the other way would make every case start with a routing argument. System knowledge lives in the connectors/* and configuration/* domains, which every investigator reads and none owns.
P The six investigators are six independent build tracks. They share one prompt skeleton — the nine mechanics as phases — and differ in their domain articles and their eval corpus. One author can carry two; six authors can work at once.
4. The nine mechanics — the module's load-bearing component
P The investigation methodology is a pipeline, not an article set. Each mechanic is a phase with a required output; a phase that produced nothing is recorded as ran, found nothing, which is evidence, and never as skipped, which is a gap (Stage Investigation § 1).
| # | Mechanic | Required output |
|---|---|---|
| 0 | cross-channel scan | the mailbox window, sibling tickets and the migration log, before any root cause |
| 1 | id decoding | every twelve-digit identifier resolved by prefix before it is used in a claim |
| 2 | invocation before configuration | log-row evidence that the thing ran at all, before asking why it is wrong |
| 3 | introspect first | column and object names read from the catalogue; a constraint proven by query, never assumed |
| 4 | peer baseline | judged against a same-lifecycle-state peer, never an end-state one |
| 5 | both-systems evidence | both policy administrations queried; the production/test cross-check where relevant |
| 6 | verify, don't guess | the named sub-cases of stop-and-confirm-before-inferring |
| 7 | intent restatement | the customer's request restated in system terms — object, state, operation — before a mechanism is sought |
| 8 | environment provenance | a claim about one environment cites only evidence whose origin is that environment |
Why this is a component and not guidance: these disciplines exist in v1 as memory files that must happen to fire, and the audit of 20.05.2026 measured four error families recurring after their rule already existed (Baseline § 5). Building them as phases is what converts a rule into a mechanism.
5. Skills — the 35 shapes, in four build groups
P The skills are the module's largest body of work and its clearest parallelism: each is a separate deliverable with its own inputs, connector calls and assertions, and each has a v1 seed to build from — the catalogue with its seeds is Data and Information Module § 0.2, and the rule that decides when a skill exists at all is Agents Memory and Skills § 9. The build order is by ticket volume first, then by the measured holder count.
| Group | Shapes | Why this order |
|---|---|---|
| 1 — the five largest | Jira conversation · retransfer and stuck transfer · policy sync compare and fix · print a document or fix a print template · vehicle identifier corrections | the most tickets; all five have v1 seeds, and they are the module's first eval sets. (“Print has the highest bus factor” was team judgement, superseded by the Internal-Tag measurement — print has four holders with ≥ 2 tickets, D115) |
| 2 — volume, shared knowledge | discount and loading fixes · user accounts · agent and office setup · instalment plans · duplicate-policy checks · rating checks · validation threshold changes · translations and labels · pricing factor values | high counts, knowledge already held by more than one person |
| 3 — high bus factor, low volume | multi-year repair · the three cargo shapes · currency corrections · process registration | low counts; the knowledge exists as articles today and must become executable before the holder is unavailable. “One or two holders” was team judgement, superseded by the Internal-Tag measurement (D115): MYR has three holders with ≥ 2 tickets, currency four, process registration three, and the cargo shapes two to three — the seven measured thin shapes are in Data and Information Module § 0.2 |
| 4 — the tail | everything else, on the 3 / 7 / 20 ladder | the platform counts occurrences and proposes the skill at the third (Stage Precipitation § 2) |
P Every skill in groups 1–3 carries the same five parts: the inputs it needs, the read set that establishes the current state, the classification of what it found, the write packet with expected counts, and the verification that re-reads the customer's surface. A skill that cannot state its expected counts is not ready to be published.
P Candidate 36 — reporting-cache refresh (Case Studies 10) enters the catalogue at its third occurrence (D23).
6. Connector operations
| Connector | Operations | Notes |
|---|---|---|
jira |
sweep by query, fetch, internal comment, public comment (gated), transition (gated), tag | closure runs through the customer; one internal note per ticket |
mail |
scan the shared mailbox, fetch a thread, send (gated) | the ignore-list is configuration |
hdesk |
read the queue, fetch a ticket and its articles, post (gated) | F the queue is the customer's product-change queue: 39 of its 52 cached tickets are configuration intake (Challenge Rounds § R2 § 1, D59). A case opened from it opens on support.root; S1 classifies it as a configuration request by default and the root hands it over at Hd (D143) |
oracle-ipal, oracle-insis |
read per environment; write shape A (apply, verify and replay inside one call) or shape B (a leased transaction) | production is the default environment for support (Stage Investigation § Facts) |
kibana |
trace by request identifier, policy or user | the evidence for mechanic 2 |
abacus gateway |
getRates replay |
shared with Configuration |
browser |
drive the customer's surface read-only; the UI actions that are not statements | a UI action is a write with its own record (Stage Application § 1) |
BI Publisher |
produce a document | the print family |
P Personal data is substituted at the connector boundary before any content reaches a model, and the connector exposes structural facets on a handle — length, prefix, checksum validity, equality with another handle — so an investigator can still find a malformed identifier without ever seeing the value (Trust and Data § 4).
7. Memory domains
| Domain | Owning profile | Holds | Built by |
|---|---|---|---|
support/methodologies |
support.resolution; others read/propose | the nine mechanics as articles, plus the disciplines that did not become mechanics | migration wave 3 |
support/experience |
the agent that worked the case writes the case-local proposal; the curator promotes it into shared storage | one entry per resolved case | wave 3, then every closing case |
support/ |
root | routing, request types, the register rules | new |
P The retrieval measurement is the acceptance test of this module's knowledge, not a file count. F The baseline to beat, measured 02.09.2026 on 30 held-out resolved tickets: a cited precedent in the top five for 3 of 30, 98 % of returned slots noise, 7 tickets returning nothing (Measurements § TB).
8. What can be built in parallel
| Wave | Components | Notes |
|---|---|---|
| 1 | the four contracts of § 2 — three of the module's own plus the shared handover packet; the nine mechanics as a phase set; the triage agent | triage cannot be evaluated before the experience entry shape exists |
| 2 — six tracks | one investigator per symptom domain, each with its domain articles and its eval corpus | the mechanics are shared; the domains are disjoint |
| 2 — beside them | the verifier · the communicator · skills group 1 | the verifier is built against the three retraction cases and needs no investigator |
| 3 | the resolution agent, the curator, skills group 2 | resolution consumes the verifier's verdict; the curator consumes closed cases |
| 4 | skills group 3, then the ladder | the tail arrives with real occurrence counts |
9. What this module does not build
- A customer self-service surface. This is the target state, built after the operator surface and the gate protocol (N-12); the ticket system stays the system of record (Non-Goals N-9, N-11).
- Fixes to code or configuration. Both are handovers to the other modules, inside the same case, after a human confirms.
- Steps only the customer's own staff can perform. An action in the incumbent system by the customer's IT, or a template change by its author, is a request record with expected evidence and an age — a step type, not a capability gap (Support SG-13).
Challenges
- P Which investigator leads a cross-system symptom is set on the first ten cases; until then the root picks by the customer's phrase and records the choice (Stage Investigation § 2).
- P The verifier's time and token budget per case is an estimate until the first ten cases measure it (Metrics § Spend envelope).
- P Symptom-signature extraction from Bulgarian free text is the open retrieval question, measured by the triage hit-rate.