Support Root
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 request root. 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 & Manipulation 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. Classification produces one identified request with its source, scope and clocks. The route selects the work or communication outcome: the same case's Data & Manipulation work; a Configuration subcase accepted at Hd; a Development subcase accepted at Hd; Assessment & Offers for effort assessment and a customer-approved proposal (Core Development is an offer type); 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 root selects work from the classified request at H2; Data work then enters S3 Solution Take · closure. The working stages S2–S8 are the Data & Manipulation Module.
Agents in this module
P Open an agent below for its function, input/output brief, task context, methods and restrictions. These descriptions are generated from the same catalogue as the module agent subpage. The memory domains listed later are knowledge stores, not additional agents.
Task contract. Start only when the selected work and prerequisites are ready. Pin the profile, request/plan and source revisions; provide the original objective, relevant evidence, decisions, uncertainties and dependencies. The agent proposes a plan to its immediate parent, waits for that confirmation before dependent work, and returns a result or a precise question. Parent confirmation does not replace an effect gate. Runtime and context contract.
Support root · support.root
Carry the original request in one persistent Support task: triage it — request type, contract class, severity or priority, the SLA clocks and the scope — then route it, delegate the selected work, hold its waits and own its closure.
| Agent contract | Detail |
|---|---|
| Input | Original normalised arrival and attachments; current case revision, tenant and actor scope Current contract/calendar policy, live case registry and reviewed routing precedents Accepted stage/subcase results, unresolved questions, current obligations and customer conversation |
| Output | S1 route packet: intended outcome, correctable classification, urgency/clocks, evidence and missing information Route checkpoint: selected Data or Assessment work, accepted Configuration/Development subcase, or explicit wait with owner and trigger Confirmed child plans, human decision packets, joined outcome and scoped closure |
| Task instructions | Classify first, then decide the route using the same case brief and task. S1 and route are checkpoints, not separate compulsory agents. Retain the original request, evidence references, classification rationale, decisions, unknowns, target revisions and obligations as versioned case papers. Use support.triage only for a bounded ambiguous classification or contract question; read its evidence and retain responsibility for the decision. Only the controlling root presents unresolved human authority. Consult another owner when its knowledge is needed and reconcile the returned evidence into the same case. |
| Memory | support platform platform/experience |
| Restrictions | One scoped task instance per selected responsibility; a reused profile never shares another case transcript, grants or mutable task state. Boot from the own domain index, task request, pinned profile and confirmed parent plan. Select relevant articles, skills, tools and helpers on demand. No direct estate writes. Data work stays in this Support case; Configuration/Source are accepted subcases. Only the controlling root raises unresolved questions to the human. Core Development is an offer type within Assessment & Offers. Offer acceptance returns the commercial disposition; it creates no implementation or deployment authority. Insufficient information to start, missing authority or an incident that cannot wait goes to the Clarification agent under H6; the case waits with actor, trigger and age and resumes at Stage 1. |
| Runtime access | case.read / papers / task state experience.query (strategy-selected) runtime.validate-contract Consult a domain owner for judgment; spawn selected module/stage tasks; confirm child plans; present unresolved human decisions |
| Context continuity | One root task per case. Persist S1 and route checkpoint results against the current case/plan revision; do not spawn another root or discard conversation when the checkpoint changes. |
| May consult | platform/experience — What did this customer already accept; is this arrival a duplicate, a precedent or genuinely new? configuration/ipal — When the classification turns on a technical distinction: is this product behaviour configured or coded? |
| Eval set | support.routing |
Methods. support.skill.classification, common.skill.experience, common.skill.communication, support.skill.channel-access, common.effect-applier.
Selected method segments. classification strategy; current case/tenant and version filters Clarify intent and missing scope; draft questions or closure for the shared communicator. Sending stays separately gated.
Classification adviser — Stage 1 sub-agent, when asked · support.triage
Answer one bounded classification question from Stage 1 — request type, contract class and severity or priority, scope — with the evidence for and against; return a recommendation and the remaining uncertainty. An internal sub-agent call of the root, like Stage 3's call to Stage 2: it never owns the case, its clocks or the route.
| Agent contract | Detail |
|---|---|
| Input | Root case brief and original evidence relevant to the ambiguity Current contract/calendar policy, candidate classifications and the precise question to settle |
| Output | Route packet: request scope, type, correctable severity/class, clocks, missing information and candidate precedents Core Development classification when requested work is outside customer Development, with the request forwarded for offer/delivery communication only |
| Task instructions | Return evidence for and against the candidate classifications; never take over the original conversation, clocks or route. No task is created for straightforward classification the root can perform with its classification method. |
| Memory | support support/experience |
| Restrictions | One scoped task instance per selected responsibility; a reused profile never shares another case transcript, grants or mutable task state. Boot from the own domain index, task request, pinned profile and confirmed parent plan. Select relevant articles, skills, tools and helpers on demand. No estate connectors or root-cause investigation; precedence hints remain hypotheses. |
| Runtime access | case.read / papers / task state experience.query (strategy-selected) |
| Eval set | support.triage |
Methods. support.skill.classification, common.skill.experience.
Selected method segments. classification strategy; current case/tenant and version filters
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. S1 classification and the route are phases of that same root task. A classification adviser is optional for an ambiguous question; the common communicator handles selected messages. Connector intake is software, not another agent. The dashed edges are what the desk does with a case once it knows what it is.
flowchart TB I["Connector intake
poll or push; no LLM"]:::store R["support.root
S1 classification then route"]:::owner T["Optional classification adviser"]:::work D["Embedded data graph
same support.root"]:::work C["configuration.root"]:::work S["source.root"]:::work O["commercial.coordinator
assessment and offer"]:::work W["Wait with actor,
trigger and age"]:::store V["common.communicator
scoped message and result"]:::proof L["common.experience-curator
reviewed experience"]:::learn I --> R R -.->|"bounded ambiguity"| T T -.->|"recommendation"| R R --> D R -->|"Hd"| C R -->|"Hd"| S R --> O R -.->|"wait"| W W -.->|"trigger fires"| R D --> V C --> V S --> V O -->|"proposal outcome"| 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 "../intake.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 "root-agents-and-skills.html#cap-support-triage" "Optional advice; root owns classification and routing." 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 O href "../45-commercial/assessment-and-offers.html" "Clarification, effort assessment, offer, customer decision and communication; Core is an offer type." 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 and route are the same root's sequential decisions on the current case brief and any scoped consult evidence, at gate H2 (Gating § 1, D147); the work is the receiving module's. The root uses coordination, applicability and consult skills, with no direct estate-write connector or estate-execution skill. It returns plans, gate requests and messages.
P Data & Manipulation 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: Root agents and methods. The platform profiles the desk draws on (platform.intake, the effect applier, the effect applier): 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 & Manipulation 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 & Manipulation 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 root selects the applicable classification and communication methods. The table below preserves the historic evidence; dedup is connector software, not a skill. Hours are estimates over the mined archive of 03.09.2026 — the method and its caveats are stated with the catalogue in Data & Manipulation Module § 0.2, over the runs of Measurements § TM; the shape catalogue of the working stages is Data & Manipulation 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 & Manipulation 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 · Support root | 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 · Support root | 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["S1 classification
same root task"]:::work G["Choose the route
H2"]:::decision D["Data & Manipulation"]:::work C["Configuration"]:::work S["Development"]:::work O["Assessment and Offers"]:::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 --> O G -.->|"wait"| W W -.->|"trigger fires"| G D --> V C --> V S --> V O -->|"proposal outcome"| 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 "../intake.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 "support-module.html#stage-support-route" "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 O href "../45-commercial/assessment-and-offers.html" "Clarification, effort assessment, offer, customer decision and communication; Core is an offer type." 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 Data solution-take document: it checks applicability after the root selects Data work, and owns that working packet. 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 & Manipulation 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 root reads the classified request: Data & Manipulation, Configuration, customer-specific Development, Assessment & Offers, or waiting? Data S3 checks solution applicability only after Data work is selected. Decided at gate H2 on the current route packet (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 & Manipulation — 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 & Manipulation — memory answer at S3, and the case never enters S2; S2 only if unknown — and then it precipitates |
| Data correction | Data & Manipulation — S2 for the evidence → the skill or the fix packet → the 5-step write |
| Access / accounts | Data & Manipulation — the access investigator + the account skills |
| Master data (vehicle, BSO, agent) | Data & Manipulation — 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 customer-specific code | Customer-specific development module (Hd) |
| Defect or bounded extension to shared code | Assessment & Offers — Core Development offer type; assess effort, craft terms, obtain the customer decision and communicate it; no code pipeline |
| 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) |
| Anything else — core product development, a new release, a contract or SLA matter | Assessment & Offers — everything that is not Data & Manipulation, Configuration or customer-specific development is assessed and offered; nothing is implemented by it |
| 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 validator 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 & Manipulation under the same root (Data & Manipulation Module § 2 carries the working part: investigation, validator, 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, Development, Core Development or Data & Manipulation — 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 & Manipulation Module § 3.
P Root definitions are on Root agents and methods; Data & Manipulation definitions are on its module subpage. Intake is the separate connector poll/push mechanism.