Data & Manipulation — implementation components
Purpose
Support Root — the root module: intake, classification, the route, closure — and the Data & Manipulation 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 & Manipulation Module § 0.2, where the catalogue lives since D145).
1. The map
flowchart TB C["Arrival, solution
execution obligations"]:::store A["Triage, resolution
domain investigators"]:::work S["Family invariants
and repair skills"]:::work G["Auditor, gates and grants"]:::decision X["Connector execution"]:::work P["Whole-family and
customer-surface proof"]:::proof M["Mechanism and
trigger experience"]:::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" "root classification; resolution; general or selected domain investigator; independent verification and shared communication/curation" 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 validator'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 |
P Stage agents and tools maps every root and Data & Manipulation stage to its agent task, method and runnable tool functions. Skills describe procedures; tools implement their repeatable segments as source and/or binaries. These are separately versioned capabilities.
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["Resolution and
domain investigator"]:::work K["Own index and
selected domain knowledge"]:::learn T["Mechanism and
family proof packet"]:::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" "root classification; resolution; general or selected domain investigator; independent verification and shared communication/curation" 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 validator 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 reference | Role |
|---|---|
| support.resolution | Experience and solution analyst |
| support.investigator.transfers | Transfer and family investigator |
| support.investigator.pricing | Pricing and installments investigator |
| support.investigator.printing | Print investigator |
| support.investigator.access | Access and provisioning investigator |
| support.investigator.health | Health investigator |
| support.investigator.master_data | Master data and blanks investigator |
| support.validator | Independent mechanism validator |
| support.solution_validator | Solution validator |
| support.application | Application coordinator |
| support.result_validator | Outcome validator |
| support.recovery | Recovery and restoration coordinator |
| support.investigator | Investigate an unresolved symptom |
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 general investigator and six symptom-domain profiles reuse one investigation skeleton. Select a known domain directly; use the general profile only until evidence identifies the domain. Operation variants extend the relevant procedure and evaluation corpus, not the number of permanent agents. The full operation inventory records the source basis.
4. Methods and executable helpers
P The module method subpage defines the procedures and their optional source/binary helpers. Runtime and connector operations are implementation mechanisms; they are not separately counted as learned skills or tools.
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 & Manipulation 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 & Manipulation 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; root classification and optional adviser | classification retrieval needs the current-case and reviewed-experience contracts |
| 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 validator · the communicator · skills group 1 | the validator is built against the three retraction cases and needs no investigator |
| 3 | the solution, confirmation, application, result-verification and recovery profiles; the curator; skills group 2 | resolution consumes the validator'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 validator'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.