Data & Manipulation Module

Support’s working stages for corrections and answers. 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.

P The flow at every presentation level. Solution take (S3) first checks whether a ready skill, memory or combination applies. If it does not, Investigation (S2) establishes the mechanism and returns its evidence to the same take. Confirmation (S4) accepts the solution packet at H3. Application (S5) executes permitted steps or coordinates an assigned external action; Verification (S6) checks the complete requested result on the customer's surface. Reversal / restoration (S7) handles a problem or a required temporary restore. The result returns to Support's closure. Precipitation (S8) reviews knowledge, skills and tools after the result, without waiting for customer closure; S6 and S7 are Data's two marked stages, and the same asynchronous workflow serves the other three lanes' marked stages through the same shared curator (Stage Precipitation). These are Support's working stages inside the same case; the walkthrough expands them between the route and closure.

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, Validation, Reversal · S8 Precipitation.

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.

Full recurring-operation inventory — investigation, methods and automation candidates.

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 validator given the evidence and neither the transcript nor the reasoning — the direct countermeasure to v1's three retraction cycles; a solution analyst, independent packet reviewer, application coordinator, independent result validator and recovery planner; the platform's effect applier as the only writer and its auditor as a mandatory independent checker; a curator that promotes experience while each domain owner confirms its own knowledge.

flowchart TB
  R["Support root
one request and closure"]:::owner
  A["S3 Solution take
support.resolution"]:::work
  I["S2 Domain investigator
plus isolated mechanism validator"]:::work
  C["S4 Confirmation
support.solution_validator"]:::proof
  E["S5 Application
support.application"]:::work
  V["S6 Validation
support.result_validator"]:::proof
  B["S7 Reversal / restoration
support.recovery"]:::work
  L["S8 Precipitation
curator and domain owners"]:::learn
  T["Skills and runnable tools
scoped reads or granted effects"]:::store
  R --> A
  A -->|"missing or contradicted pattern"| I
  I -->|"verified mechanism"| A
  A -->|"current applicability proved"| C
  C -->|"root obtains H3"| E
  E -->|"actual result or external receipt"| V
  V -->|"failed proof or required restore"| B
  B -->|"new evidence"| V
  V -->|"requested outcome proved"| R
  V -.->|"queue after result"| L
  T -.->|"bounded operations"| A
  T -.->|"auditor and executor enforce effects"| E
  L -.->|"reviewed experience for next request"| A
  classDef owner fill:#24486b,stroke:#24486b,color:#fff
  classDef work fill:#eef4ff,stroke:#6889ba,color:#17365b
  classDef proof fill:#e9f5ef,stroke:#689b81,color:#224e39
  classDef learn fill:#f1edf9,stroke:#9580b9,color:#534172
  classDef store fill:#f5f7fa,stroke:#98a6b7,color:#34445a
  click R href "support-module.html" "Owns routing, authority questions and customer closure."
  click A href "stage-solution-take.html" "Check compatible experience against current state before reuse."
  click I href "stage-investigation.html" "Establish a mechanism from evidence; a similar symptom is not proof."
  click C href "stage-solution-take.html" "Independent packet review does not answer the human gate."
  click E href "stage-application-and-verification.html" "Coordinate approved effects or assigned external actions."
  click V href "stage-application-and-verification.html" "Test the whole requested outcome on current evidence."
  click B href "stage-application-and-verification.html" "Compare the original journal and current state before compensation."
  click L href "stage-precipitation.html" "Propose memory, methods and tested automation for reuse."
  click T href "../50-agents/stage-agents-and-tools.html" "See the reviewed agent, skill and tool responsibilities for every stage."

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 validator'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 (Data & Manipulation components § 4) — and a domain and an eval corpus each.

Profiles in full — what each boots from, writes, may use, is denied: Data & Manipulation components § 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 Agents, methods and executable helpers

P Full definitions live on Agents and methods. Shared definitions are referenced from Common agents and methods. Each method owns its optional executable helpers; runtime/connector operations are not extra skills.

Recurring operational evidence supplies the source cases and measured shape catalogue.

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 validator 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 Root § 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 validator, 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.

P Each of the 24 has a journey. DC-01 … DC-24 are traced through the platform as designed — the screen the person sees, the endpoint request and what it stores, the agent initialisation and task prompts, the gate, the execution, the reversal, what is retained and how the next occurrence starts — in the interactive case walkthrough, case by case from Typical cases. Case journeys states the rules those journeys obey; Case Protocol states the service boundaries. Both are design specifications with explicit falsifying variants, not recorded runs.

3. Evaluation

Replay corpus: resolved cases (ticket + evidence snapshot in; mechanism + fix shape as reference), graded by the isolated validator 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.