☰ Contents
AISA v2.0 / Technical documentation / Stage S2 — Investigation

Stage S2 — Investigation

F verified factP decided planC open challenge

Purpose

P The stage is entered from S3, not before it (Support Module § 1, D83): a case reaches investigation because the take found no ready solution — no skill covers the operation and memory does not answer it. What it then works is the databases, stored code, or both.

A request says what the customer sees. Investigation establishes what the system does — the mechanism, named at its layer, supported by evidence that survives someone else re-deriving it. This is the stage where v1's quality actually lives, and also where v1's worst failures happened: three full retraction cycles (SD-1627, SD-1636, SD-1651), each from pattern-matching a past ticket into a confident root cause without verifying the mechanism (Baseline § 5).

The stage's job is therefore not "find an explanation". It is produce a mechanism that an isolated verifier, given the evidence and none of the reasoning, arrives at independently.

Inputs → Outputs

In: the classified case — symptom, systems, environment, contract classification, and whatever the experience index surfaced at S1. Out: the mechanism (one sentence, layer named), the evidence supporting it, what was ruled out and how, and the open items that remain — feeding the solution take.

What runs this stage
Agents support.investigator.<domain> — transfers · pricing · printing · access · health · master data
Isolated sub-agents support.verifier, which is given the evidence and neither the transcript nor the author's identity
Memory domains reads / proposes to support/methodologies — the canonical owner is support.resolution; other profiles file proposals to it (D56) — plus the investigator's own domain articles and the connectors/* and configuration/* domains, which every investigator reads and none owns (Agents Memory)
Skills it runs the read and diagnostic shapes of the catalogue, grouped by symptom family (Agents Memory and Skills)
Its branch of the graph Data and Information Module § 0 — the working stages' tree, memory branch and skills · the component list is Components — Support

Every stage also uses support.root — the only profile that reaches the human — and the platform's write_executor and write_auditor (Gating).

P Investigators read through connectors (oracle-ipal read, oracle-insis read, kibana) and diagnostic skills; they hold no write executor.

1. The methodologies are mechanics, not advice

Why: v1's disciplines exist as memory files that must happen to fire, and the audit of 20.05.2026 measured them failing at author time — four families recurring after their rule already existed F: [write-time discipline]. The fix is not a better-written rule. It is making the discipline a phase the pipeline runs, whose output is a required field.

Order Mechanic What it produces v1 source
0 Cross-channel scan mailbox ±2 h, sibling tickets, tmp/, MIGR_LOG — before any root cause file
1 Id decoding every 12-digit id resolved by prefix before it is used in a claim file
2 Invocation before configuration log-row evidence that the thing ran at all, before asking why it is wrong; a failed probe is not a finding file
3 Introspect first column and object names read from the catalogue, never guessed — v1's ORA-00904 loops; constraints proven by query, not assumed from the catalogue (a uniqueness that the schema does not declare is verified with a count — SD-1729) file
4 Peer baseline judged against a same-lifecycle-state peer, never an end-state one file
5 Both-systems evidence IPAL and INSIS both queried; PROD/TEST cross-check where relevant file
6 Verify, don't guess 25 named sub-cases of stop-and-confirm-before-inferring file
7 Intent restatement the customer's request restated in system terms — object, state, operation — before any mechanism is sought; where two readings exist („предложение" versus „полица", SD-1636) both are written and the clarifying question is a gated send, not an operator guess file, Case Studies G-8
8 Environment provenance a claim about environment X cites only envelopes whose origin is X; a TEST row read as PROD (SD-1721) is a provenance failure the verifier rejects, not a finding Case Studies G-9, rule

P Each mechanic is a phase with a required output. A phase that produced nothing is recorded as ran, found nothing — which is evidence — and never as skipped, which is a gap. The v1 failure mode was checklists that halted silently mid-walk F: [audit].

2. Domain investigators

P Investigators are profiled by symptom, not by system (decision 01.09.2026) — transfers and sync, pricing, printing, access, health, master data — each booting from its own memory domain (Agents). The reason is that a customer reports a symptom and never a system; shaping the agents the other way would make every case start with a routing argument.

P System knowledge is therefore not duplicated across investigators: it lives in the connectors/* and configuration/* domains, which every investigator reads but none owns. P The lead is two-phase (Challenge Rounds § R2 § 6): a provisional lead at S1 by symptom vocabulary (transfers → printing → pricing → access → master data → health — a configuration value), so no case starts with a routing argument; then a hypothesis checkpoint after mechanics 0–2 or at 20 % of the investigation budget, where the lead emits mechanism_hypothesis {layer, system, domain, confidence} as a required output — if the domain differs, the root reassigns the lead once (plan revision, reason hypothesis_reassignment), the first investigator becomes a consult; a second disagreement is a DeadEnd → H6, never ping-pong. P Measured on the first ten cross-system cases: reassignments ≤ 2/10 keep the precedence, 3–5 rewrite it from the observed final leads, > 5 drop the provisional lead for a triage hypothesis; spend before reassignment < 15 % of the case. An investigator consults another domain's agent laterally on mechanism questions; a lateral consult is evidence, never authority (Architecture § 2).

F Standing rule on the edges: a sub-agent's convenient "missing" or "inaccessible" that contradicts established evidence is re-asked with the how, not believed (the PC 9951 run).

3. The isolated verifier

P Before any mechanism is published — to the customer, to a Jira comment, or into memory — the verifier re-derives it. The verifier's profile denies it the author's transcript and identity; evidence provenance is retained; it receives the evidence and the symptom, and produces its own mechanism (Agents § 0.2).

Why: this is the direct countermeasure to the three retraction cycles. Author and verifier being the same context is the proven failure mode (Baseline § 7).

P The verifier is tiered (SG-10; Case Studies G-3). Mandatory before a mechanism reaches the customer or memory, and for the first three cases of a new shape; sampled (one in N for skill runs and memory answers on known shapes; N is a platform-policy value, default 5, tuned from the ledger — Whitelabel Catalogue), where a full re-derivation would double a thirty-minute ticket. The sampling decision is a ledger record, so the verifier's coverage is a metric.

4. When to stop

P Investigation ends in one of three states, all legitimate:

  1. Mechanism found — verified, layer named → solution take.
  2. Mechanism not found, containment known — the symptom's trigger and a workaround are established. Under the contract a workaround downgrades severity (§ 1.5.3) F: [contract]; the case continues at the lower severity.
  3. Dead end — gate H6. What was checked, what it cost, and what would be needed to go further.

P The report names the level reached and never implies a higher one (Architecture CR-3). "Likely" and "verified" are different words with different consequences.

Facts to hold F

Challenges

PreviousStage S1 — ClassificationNextStage S3 — Solution Take