Stage S3 — Solution Take

P Stage correspondence. route The route; S3 Solution take; S4 Confirmation. 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.

Purpose

P This stage is reached after the Support root selects Data & Manipulation work (Support Root § 1, D83), and it asks two questions in order. First: is there a ready solution — does an existing skill cover the operation, does memory or the experience index answer it? If not, the case goes to S2 investigation over the databases and stored code and returns here with a verified mechanism. Only then is the second question answerable.

P The initial desk route is owned by support.root before this stage. S3 owns the Data working-plan decision: whether current evidence supports a known solution or requires S2. If the mechanism changes the required module or scope, S3 returns that finding to the root for a revised route/handover; it cannot recruit or authorise another module on its own.

The second question: with the mechanism known, what is not yet decided is the kind of thing that will fix it — and that decision is where support organizations quietly go wrong. A data fix applied for the third time to the same recurring cause is not a fix; it is a subscription. A code change proposed where a configuration cell would do is expensive and slow. An answer given from memory where the mechanism has actually changed is a retraction waiting to happen.

This stage makes the choice explicit, by kind, before anything is applied — and puts it in front of the human as one decision rather than a sequence of small ones.

Inputs → Outputs

In: the classified case with its precedent and memory hits; when the case came through S2, the verified mechanism and its evidence. Out: the solution packet — the chosen kind, what will change, the expected result, the revert path, and the predicted delivery time in minutes (the case's budget from here on — D135; tokens, turns and sessions are caps, not budget) — presented at gate H2 and confirmed at H3. Draft contract: solution-packet.schema.json (Contracts § 2, D139).

What runs this stage

Every stage also uses support.root — the only profile that reaches the human — and, where it writes, the shared skill common.effect-applier (Gating).

0. Experience first, investigation when needed

P The analytical task has three possible results: applicable experience, insufficient evidence, or contradicted experience. It retrieves only compatible active memory, skill and tool versions; compares the current target, lifecycle, environment, consumer version and failure discriminator; and records candidate references, checks run and rejected matches in a case paper. No match, a stale premise, or a failed precondition returns needs_investigation to the root. An answer is not accepted merely because a ticket has a similar title.

P S2 starts from the actual symptom and current evidence when no reliable pattern exists. It keeps the rejected matches as labelled hypotheses, performs the applicable investigation mechanics, and returns an independently checked mechanism to S3. A known pattern still requires fresh scope and proof. SD-1598's missing register row, a stale PDF and an uncreated renewal are different mechanisms with different remedies (case walkthrough).

P Every stage task gets the pinned profile, parent plan, input papers, memory index, permitted skill/tool versions and completion assertions. It returns a typed result with evidence references to its parent. Stage roles and tool responsibilities are listed in Stage agents and tools; they do not add screens or change the module stages.

1. The five kinds — and three step types

P Which kind is chosen is governed by how often this has been seen (decision 01.09.2026), on the same fix-signature counter as the precipitation ladder:

F The v1 rule this implements: a second identical manual fix means a configuration gap (rule). The platform counts identical fixes across cases, so a third quiet repair cannot happen the way it did in v1 — the difference is that the count now surfaces a proposal rather than blocking the repair.

2. Handovers

P A handover recruits the Configuration or Customer-specific development module as a sub-case inside the same case, after human confirmation (gate Hd). The receiving module runs its own stages and its own gates; the result returns to the support case, which owns the customer-facing closure. The customer sees one case throughout.

P The handover scope is itself a deliverable: what the receiving module is being asked to do, what evidence it inherits, and what "done" means for the support case — not a forwarded ticket. Its shape is the handover packet of Agents § 5 (D142; draft contract in Contracts § 2): request → accepted-or-rejected response → completion, the same paper in all four directions.

P Sub-case ordering is the support root's (G-12). A handover scope names the sub-cases it depends on (a configuration fix that must land before the code fix), and the support root sequences their H5 gates; a sub-case cannot deploy before the one it depends on has verified.

3. What the human is asked

P One decision packet, not a conversation:

P S4 confirmation is gate H3 on this packet — H2 presents it as the plan, H3 confirms the final statement, counts and revert (Gating § 1, D102).

• the mechanism, one sentence, layer named, with the validator's independent agreement;
• the chosen kind and why the alternatives were rejected;
• the exact change — fix SQL with expected row counts, or the skill invocation, or the handover scope, or the drafted answer;
• the revert path, and whether any step is irreversible (Failure and Recovery § 2);
• the replay: which query or which customer-facing action will demonstrate the fix worked;
• what remains uncertain.

P Where the fix is a database change, the packet is the input to the write protocol — approval is given before the write opens, against the shown statement and its expected counts, never in the middle of an open transaction (Failure and Recovery § 1).

P A new operation's first instances carry a draft shape; the person's decisions train it (D112).

4. Not every request is a fix

F The contract is authoritative over the technical judgement, and both directions matter:

• Improper use, a new feature, or work outside § 1.6.1 is a CR, not a defect — however easy it would be to do (Non-Goals N-7).
• INSIS code changes are always CRs to the customer; they are never proposed as direct fixes.
• A workaround that exists downgrades severity (§ 1.5.3) and changes what the case owes and when.

P The rejection is as much a deliverable as the fix: the packet says which contract clause places the request outside standard support, and what the customer's route is instead.

Challenges

• P Counting "identical fixes" across cases: the signature is mechanism id + object class (the layer-named mechanism the validator agreed, plus what was touched — policy, annex, account, factor), with table and column as attributes; table-plus-column alone misses UI-driven fixes and over-merges state flips (Case Studies G-7). F Validated on three v1 families (Measurements § RE § 7): a signature of system · table · op · columns_core (variant columns apart) · selector · discriminator groups KI-030 at its second ticket (five weeks before the root cause was written) and KI-017 only with the variant split, and splits KI-043 — one mechanism with two fix shapes — so a second key, the consumer code path that exposes the symptom, joins such families; the KI id, once assigned, is the family key. F No DML or correction log exists on QA IPAL to join a signature to (0 triggers, no statement audit); the platform writes the signature at apply time, and SRD_INTEGR.DBTOOLS$MCP_LOG (1,559 AISA statements since 10.09.2025) is the only back-fill source for v1's families (Measurements § DB § 7).
• P Memory staleness: the check that a remembered answer is still true, cheaply. Entries carry their observed environment and version, but the re-verification query is per domain and mostly unwritten.