Stage S3 — Solution Take

Purpose

P This stage is reached directly from classification (Support Module § 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 That first question is the desk's route, decided at gate H2 on the packet this stage prepares (Gating § 1, D147). Its answers are the working stages under the same root, a handover (Hd) to Configuration or Development, or waiting — a step only the customer or an external owner can perform, or a wish deferred to a later release (Support Module § 1–2).

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 the platform's write_executor and write_auditor (Gating).

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 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 verifier'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 verifier 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.