Support Module
P Stage correspondence. closure Closure. These are the same stage identities used by the product overview and case walkthrough. A checkpoint or nested task conversation stays inside its owning stage.
The root module. Every request enters here, and leaves classified, identified and routed. The desk is one module and it owns every case: it classifies the request against the contract, identifies what kind of work it is, and either holds it in a waiting state or hands it to the module whose work it is — Configuration, Development, or its own Data and information stages. Whichever module works it, the case, its clocks and its closure stay here, so the customer hears one voice (decision Vladimir, 04.09.2026 — D143).
P The flow at every presentation level. Intake and classification produces one identified request with its source, scope and clocks. The route selects one of four outcomes: the same case's Data and Information work; a Configuration subcase accepted at Hd; a Development subcase accepted at Hd; or Waiting with its actor, trigger and age. These are alternative branches. The chosen work returns its required proof to Closure, where the reply is delivered through H5-send and the customer accepts the result. The walkthrough expands that chosen branch inside the same journey. The desk owns whether/who and the customer result; the selected stages own how.
Stages here: intake · S1 Classification · the route — the first question of S3 Solution Take, decided at gate H2 (D147) · closure. The working stages S2–S8 are the Data and Information Module.
0. The agents
P The tree. support.root is the only profile that reaches the human and the only one that opens a sub-case in another module. Below it: the triage agent (S1), the communicator (every customer-visible send), and the connector agents that own the channels. The dashed edges are what the desk does with a case once it knows what it is.
flowchart TB I["platform.intake
channel adapters"]:::store R["support.root"]:::owner T["support.triage"]:::work G["support.resolution
route proposal"]:::work D["Embedded data graph
same support.root"]:::work C["configuration.root"]:::work S["source.root"]:::work W["Wait with actor,
trigger and age"]:::store V["support.communicator
verified result and reply"]:::proof L["support.curator
experience index"]:::learn I --> R R --> T T --> G G --> D G -->|"Hd"| C G -->|"Hd"| S G -.->|"wait"| W W -.->|"trigger fires"| G D --> V C --> V S --> V V -.->|"after result"| 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 I href "stage-classification.html" "Normalise and deduplicate the same source request; intake opens automatically." click R href "../case-protocol.html" "The Support root owns the objective, clocks and customer result." click T href "stage-classification.html" "Classify, retrieve compatible experience, then verify applicability." click G href "stage-solution-take.html" "A data answer/repair, Configuration, Development or an explicit wait." click D href "data-and-information-module.html" "The same Support root; a new data.root does not exist." click C href "../20-configuration/configuration-module.html" "Hd recruits scoped configuration work and retains parent closure." click S href "../30-source/source-module.html" "Hd recruits a bounded code change, with actual lineage and target proof." click W href "../case-journeys.html" "External action, customer response or release trigger; no worker held." click V href "stage-application-and-verification.html" "Verify the whole requested result; gated communication precedes customer closure." click L href "stage-precipitation.html" "Actual outcome and independent reuse; publication and authority remain separate."
The root coordinates; specialists do the work. Any route returns proof to the same customer case, and each module contributes experience.
P Who decides what. The root owns whether and who; a stage owns how (Agents § 5b). The classification is triage's; the route is the root's decision on the packet the take prepares, at gate H2 (Gating § 1, D147); the work is the receiving module's. The root holds no write connector and no skill: everything it decides is a plan, a gate or a message.
P Data and information runs under the same root (D144). A case whose kind is a data correction or an answer does not change module: the root instantiates the working stages S2–S8 the way the configuration root instantiates its stage subset (Configuration Module § 1, "a case may run a subset"), so the two modules share the case, its clocks and its closure, and the profile and memory names stay support.* and support/. A configuration or code kind is a handover (Hd): a sub-case inside the same case, with the receiving module's own stages and gates, accepted or rejected with a reason, never hanging (Agents § 5, D142).
P Waiting is a route, not a gap (D147). A request that can wait moves to a waiting state that names three things. Its trigger: a step only the customer can perform — the customer-question step type of Stage Solution Take § 1; a step only an external owner can perform — the external-owner step (SG-13); or a deferred wish the customer agrees waits for a later release, recorded as a CR candidate or a Development extension with the release it waits for. Its clock treatment: the customer's turn is Pending, and Pending pauses both clocks (clocks.pause_states, Whitelabel Catalogue § 1; Stage Classification § 3). Its age, visible in the held view exactly as approved-but-unapplied writes are (PG-20; Stage Application and Verification). The case re-enters the route at H2 when the trigger fires — the customer answers, the external owner returns the evidence, the release lands. Waiting is a decision at the route, never a status an agent sets for itself. C Which pause state a deferred wish maps to — the customer's turn, or a clock of its own — is a contract question the support contract does not answer; until it is decided a deferred wish is recorded as Pending with its release named. F The v1 evidence for making waiting explicit is the age nobody could see: a held write backlog sat at 39 of 51 issues for twelve weeks across seven refresh-only runs (backlog). Beside it, 148 resolved tickets sit in Pending with no resolution date (Measurements § TM-3) — Pending is the customer's turn, so those are resolved cases waiting on the customer rather than a waiting route; what they show is the same missing age.
P Intake. platform.intake normalises the arrival, stamps the origin key, dedups, resolves the customer and checks the initiation right (Agents § 5c) — and opens the case on support.root. Naming the owning module is no longer intake's decision: it is this module's S1 and route, taken on a classified case rather than on a channel default (D143, narrowing D93). A case started in place by an operator on Configuration or Development is the exception: the operator is the classifier. The channels are the plug-in's — the ticket system, the mailboxes, the help desk, and a request started in place on the client surface, whose message box is a door of that surface and not a separate channel (UI § 5b; Whitelabel Catalogue § 2; D51, D97, D98).
Profiles in full — what each boots from, writes, may use, is denied: Components — Support § 3. The platform profiles the desk draws on (platform.intake, the write executor, the write auditor): Agents § 1.
0.1 Its branch of the memory tree
support/
├─ AGENTS.md request types, the contract classification, the routing table (§ 2), the waiting rules
├─ methodologies/ the inherited v1 discipline catalog — worked by the Data and information stages; owned by support.resolution
└─ experience/ the past-case index (Agents Memory § 5) — read by every module, written only by the curator
| Domain | Owning profile | Contents | Seeds |
|---|---|---|---|
support/ |
support.root |
request types and their routes; the contract's sections, severities and clocks; the waiting rules; the register rules for customer-visible text | the support contract [F: cited per clause]; the reply rules; closure via Pending; the config-toggle vs CR rule |
support/experience — read here, owned by the curator |
the curator (Data and Information Module § 0.1) | past-case entries, the symptom-signature lookup | 509 analyses (frozen baseline 31.08.2026), 56 KIs, checklists |
0.2 Skills and tools
The desk's own skills are the ones every ticket passes through. Hours are estimates over the mined archive of 03.09.2026 — the method and its caveats are stated with the catalogue in Data and Information Module § 0.2, over the runs of Measurements § TM; the shape catalogue of the working stages is Data and Information Module § 0.2.
| Skill | Stage | Tickets asked / analyses used | Hours now → with skill | v1 seed | Bus factor | What it does (inputs → actions → verification) |
|---|---|---|---|---|---|---|
| Jira conversation — BG customer reply, internal note, tag, transition via Pending | closure · communicator | 330 / 330 (a phase of every ticket) | 638 → 422 | aisa-jira CLI, reply rules, closure via Pending |
low — four people with two or more tickets, lead share 60 % [F: Data and Information Module § 0.2] | analysis result → drafted BG public reply + technical internal note + AISA tag → gated send → transition → verify comment ids and status |
| Contract classification | S1 · triage | every ticket | — | /classify-ticket [F: v1 skill] |
— | request → §1 Standard Sev 1–4 or §2 Personalizations P1–3, the workaround downgrade (§1.5.3), the two clocks started |
| Precedent lookup | S1 · triage | every ticket | — | grep over the v1 MEMORY.md one-liners, measured at 3 of 30 on held-out tickets [F: Measurements § TB] |
— | symptom signature → the past-case index → precedents returned as hypotheses, never as a verdict |
| Dedup on the origin key | intake | every arrival | — | the HDesk↔Jira mirror handling F: [backlog] | — | channel + external id, reporter, referenced object, symptom signature → the open case it attaches to, naming the controller, or a new case (PG-20) |
Tools. The channel connectors — jira, mail, hdesk, the client surface — read at intake and send through the gate at closure; a dedup query on CASES. No database connector at the desk: the desk classifies and routes, it does not investigate.
1. The stages
flowchart TB I["Authorised arrival"]:::store R["A durable request"]:::owner T["Triage and precedents"]:::work G["Choose the route
H2"]:::decision D["Data and information"]:::work C["Configuration"]:::work S["Development"]:::work W["Wait with actor,
trigger and age"]:::store V["Join required proof
send and accept"]:::proof L["Queue learning
from every module"]:::learn I --> R R --> T T --> G G --> D G -->|"Hd"| C G -->|"Hd"| S G -.->|"wait"| W W -.->|"trigger fires"| G D --> V C --> V S --> V V -.->|"after result"| 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 I href "stage-classification.html" "Normalise and deduplicate the same source request; intake opens automatically." click R href "../case-protocol.html" "The Support root owns the objective, clocks and customer result." click T href "stage-classification.html" "Classify, retrieve compatible experience, then verify applicability." click G href "stage-solution-take.html" "A data answer/repair, Configuration, Development or an explicit wait." click D href "data-and-information-module.html" "The same Support root; a new data.root does not exist." click C href "../20-configuration/configuration-module.html" "Hd recruits scoped configuration work and retains parent closure." click S href "../30-source/source-module.html" "Hd recruits a bounded code change, with actual lineage and target proof." click W href "../case-journeys.html" "External action, customer response or release trigger; no worker held." click V href "stage-application-and-verification.html" "Verify the whole requested result; gated communication precedes customer closure." click L href "stage-precipitation.html" "Actual outcome and independent reuse; publication and authority remain separate."
A request can wait without failing or consuming a worker. The root joins the delivered result; queued learning continues independently of the customer's closure.
P Stage ids name the stage documents, not a running order (D83). S1 is the classification document; S3 is the solution-take document, whose first question is the route and whose packet belongs to the working stages. The diagram draws the four states of Gating § 1b (D148): the route is a gate; the closure is a person deciding on a signed result — S6's re-check is the signed result, the send is H5-send, the customer's confirmation completes the case (D49); precipitation runs after the workflow, on the Data and information side.
| Stage | What happens |
|---|---|
| intake | channel-normalized arrival (connector agents own the channel mechanics); origin key stamped; dedup; the customer resolved and the initiation right checked (Agents § 5c); the case opens on support.root |
| S1 classification | request type + contract classification (§1 Standard Sev 1–4 / §2 Personalizations, workaround downgrade) with SLA clocks started F: [contract]; experience-index lookup — "has this been seen" answers in seconds |
| the route | the first question of S3: is there a ready solution, is the fix configuration, is it code, can it wait? Decided at gate H2 on the packet the take prepares (Gating § 1, D147) — a person while the type is learning, policy once the shape is proven (Gating § 9) |
| waiting | the trigger, the clock treatment and the age recorded (§ 0); the case re-enters the route at H2 when the trigger fires — the customer answers, the external owner returns the evidence, the release lands |
| closure | the four conditions of resolved; S6's re-check is the signed result; the BG reply through the gate (H5-send); the platform moves the ticket to Pending (= resolved); the customer's confirmation completes it (D49) |
2. Routing by request type
| Request type | Route |
|---|---|
| Incident ("X is broken") | Data and information — S3 first: the take asks whether a ready solution exists. Usually none does, so the case leaves by the no ready solution edge to S2 with the symptom's domain investigator and returns to the take on the verified mechanism (D83) |
| Question / how-to | Data and information — memory answer at S3, and the case never enters S2; S2 only if unknown — and then it precipitates |
| Data correction | Data and information — S2 for the evidence → the skill or the fix packet → the 5-step write |
| Access / accounts | Data and information — the access investigator + the account skills |
| Master data (vehicle, BSO, agent) | Data and information — a ready solution: the matching skill at S3, no S2 F: v1 skills as seeds, e.g. [add-car] |
| Configuration change request | config-toggle vs CR classification F: [rule] → Configuration module (Hd), or the CR path |
| Defect needing code | Development module (Hd) |
| A step only the customer can perform (a business decision, a missing document) | waiting — the customer-question step type (Stage Solution Take § 1); Pending pauses both clocks; age visible |
| A step only an external owner can perform (Bulstrad IT, a BI template author) | waiting — the external-owner step with its request record (SG-13); age visible |
| A wish the customer agrees waits for a later release | waiting — a deferred wish, recorded as a CR candidate or a Development extension with the release it waits for; re-enters the route when the release lands (D147) |
| Out of contract / CR candidate | the CR/commercial path — capability ≠ approval (Non-Goals N-7) |
3. What this module asks of the others, and what they ask of it
P Two mechanisms, defined once in Agents § 5: a consult returns knowledge and costs a read; a handover (Hd) returns a changed system and costs a gate.
What Support asks:
| It asks | Of | When | What it does with the answer |
|---|---|---|---|
| "What state is this insurance product actually in?" | Configuration — configuration/ipal, configuration/abacus |
S2 investigation, whenever the symptom is a product's behaviour | separates the product is configured wrongly from the code is wrong, which is the fork the whole route turns on |
| "Can this be priced the way the customer expects?" | Configuration — configuration/abacus |
pricing symptoms | a rating answer, labelled evidence, that the verifier can re-derive |
| "What has gone wrong in this service before?" | Development — source/<repository> |
S2, when the mechanism is in code | the repository's own knowledge instead of a guess from the outside |
| "Re-configure this" | Configuration — Hd | at the route, kind configuration | a sub-case with its own stages; this case keeps the customer's closure |
| "Fix this code" | Development — Hd | at the route, kind development | as above; the two may run at once as a combination |
What is asked of Support:
| Asked | By | What answers it |
|---|---|---|
| "Has a product of this shape failed before, and how?" | Configuration, before a stage plan | support/experience plus the symptom domain's mechanics — the articles alone are not the answer (Agents Memory § 6) |
| "What has gone wrong in this seam, this service, this product?" | Development, at planning | the same, sized as a blast radius rather than as a fix |
P Support is the estate's memory of what breaks, and that is why both other modules consult it rather than keeping their own failure lists. The agent that worked the case writes the case-local entry and files it as a proposal; the domain's curator promotes it into shared storage (Agents Memory § 6) — one place to ask, one place to correct when an article turns out to be wrong.
4. Sample case
HelpDesk ticket: a policy will not print. Intake: origin key stamped, no open duplicate, the reporter's organisation may start a support request. S1: incident, §1, clocks started; the experience index surfaces two print precedents + the print recipe. The route (H2): the precedents are close but not this product's template — no ready solution, nothing says configuration or code yet, and nothing can wait: the case goes to Data and information under the same root (Data and Information Module § 2 carries the working part: investigation, verifier, the packet, the 5-step fix, the re-check). The take comes back a combination: fix the cell now, and — since this is the second identical manual fix — the configuration-gap escalation, which the route raises as an Hd to Configuration. Closure: the customer's exact print action re-verified is the signed result; BG reply gated and sent; the platform moves the ticket to Pending (= resolved); the customer's confirmation completes it (D49). Precipitation runs after the workflow, without waiting for that confirmation.
5. Evaluation
The desk's corpus: resolved cases (ticket in; the analyses' own type, severity and outcome as reference), graded on the type and severity chosen, the route taken — waiting, configuration, code, or data and information — and the drafted reply against the sent one; seeded from the v1 corpus (509 analyses, frozen baseline 31.08.2026; 322 with a contract classification); re-runs when support/ or the model route changes. The working stages' corpus is Data and Information Module § 3.