☰ Contents
AISA v2.0 / Technical documentation / Stage S8 — Precipitation

Stage S8 — Precipitation

F verified factP decided planC open challenge

Purpose

This is the stage that exists because of a named v1 pain point: recurring and long-running investigations are not being turned into skills or durable memories, so the next occurrence costs the same one to two hours that a skill or a memory entry would cut to minutes (stated 31.08.2026).

Precipitation is the case paying for itself. It is mandatory, it is recorded, and nothing is a legitimate outcome — provided it is justified.

What runs this stage

Agents support.curator — the only profile that confirms proposals into shared memory
Isolated sub-agents
Memory domains owns support/experience; reads and proposes to support/methodologies, owned by support.resolution. The owner alone activates shared revisions (Modules).
Skills it runs skill creation goes through governance (Agent Framework § 6); the catalogue itself is 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).

Inputs → Outputs

In: the case after S6 verification — closure is the customer's (D49) and precipitation does not wait for it — its papers, its mechanism, what was reused, what was missing, and the budget it used. Out: a precipitation decision in the ledger, plus the mandatory experience entry and at most one optional result: a skill, an article, an index line, or a justified nothing.

0. The approach — why v1's memory does not fire, and what changes

F v1 does precipitate: 548 memory files, 509 analyses (frozen baseline 31.08.2026), 56 known issues and living checklists exist (Baseline § 2). What fails is retrieval and application: the 20.05.2026 audit found four error families recurring after their rule already existed, and cached knowledge that is 10–60× cheaper than rediscovery going unused (write-time discipline, measurement). The pain is therefore not "we do not write things down"; it is that what is written down is flat, retrieved by grep on one-line descriptions, and has to happen to be read at the moment it matters.

P The approach, in the order it pays back (decision 02.09.2026):

# Move What it fixes Where it is specified
1 Mechanics, not memories. Anything that must always happen becomes a pipeline phase with a required output — the nine investigation mechanics, the closing walk reconciled like a plan, the assertion form the "rule existed, was not applied" family: a phase cannot be forgotten, a memory file can Stage Investigation § 1, § 3 below
2 Retrieval at the moment of need, not at boot. Triage queries the experience index with the symptom signature before investigation starts and returns precedents as hypotheses; the investigator reads outward from its own node on demand knowledge present but never consulted Stage Classification § 5, Agents Memory § 2
3 Skills over articles for anything executable. A diagnostic query pack, a compare checklist, a master-data operation is a tool the agent calls, with assertions — not prose it must remember to follow the "checklist halted silently" family Agents Memory and Skills, Agent Framework § 6.6
4 Measure the firing rate, and let it decide. Migration of a domain is accepted only when the held-out triage hit-rate beats grep; consolidation passes are judged the same way; the retrieval mechanism (grep vs vector) is chosen by that number rebuilding a corpus that does not fire Agents Memory § 7.2
5 Refine on use, not on writing. The 3 / 7 / 20 ladder revisits a skill or article when it has actually been used, with more evidence entries written once and never revisited § 2 below
6 Governance for memory. Proposed → active → retired, provenance on every write, version pinning per case, dependency-scoped eval re-runs an article that quietly misleads every later case Agents Memory § 7.4b

P The one number that says whether this worked is the triage hit-rate on held-out v1 cases (Agents Memory § 7.2) — and it was measured on the v1 corpus on 02.09.2026, before any platform existed: 30 held-out resolved tickets, each presented as it arrived, against what the current memory/ offers a grep. The result is the baseline to beat — a cited precedent in the top five for 3 of 30 (10 %), 98 % of the 150 possible slots noise, and 7 tickets returning nothing (Measurements § TB). The target is ≥ 50 % top-5 hit-rate per domain before acceptance (D111, Metrics).

1. The decision

P Every closing case records an experience entry always, plus at most one of:

Outcome When Produces
Skill the investigation shape will recur and is mechanizable — a diagnostic query pack, a repeated master-data operation, a check sequence a skill, published through governance (Agent Framework § 6.6)
Article a pattern worth recalling: a mechanism, a trap, a rule of the running system a memory article in the owning domain, under the writing practice
Index line the domain's AGENTS.md one-liner needs updating so the thing is findable an index change in the same edit
Nothing the case taught nothing new the justification, recorded — not silence

The mandatory experience entry is written case-locally by the agent that worked the case and filed as a proposal; the domain's curator promotes it into shared storage (D25/D56).

P The decision is an audit record, so precipitation rate and reuse hits are parsed rather than claimed (Metrics).

2. The recurrence ladder — 3 / 7 / 20 (a configuration default)

P Case journeys § 6 separates fix-shape occurrence, confirmed-trigger recurrence and clean execution. The existing mechanism/object signature drives this ladder; an evidenced trigger-family relation joins different repairs with one cause. Count canonical requests, not mirrors/subcases. The S8 job is keyed by request and verified result revision and durably queued at resolution. Later customer evidence or a contradiction creates an amended result/proposal while preserving earlier evidence. Closure and retries never silently double the count.

P Precipitation is not one event but a refinement ladder, driven by how often the same shape actually recurs (decision 01.09.2026); the three counts are a platform-policy value with the defaults below (Whitelabel Catalogue):

Occurrence What happens
1st–2nd experience entry only. Nothing is mechanised yet — a skill written after one sighting costs more than the investigation it replaced
3rd create the skill or the article. The shape has proven itself
7th first refinement pass. The agent revisits its own first version with four more cases of evidence and spends real time improving it — a version written from three examples will show it
20th second refinement pass. By now the shape is load-bearing and worth the cost of getting right

Why a ladder rather than a threshold: a created skill is not a finished skill. The v1 corpus is full of entries written once and never revisited, which is a large part of why it does not fire. Scheduling the improvement at a known occurrence count means refinement happens because the thing is used, not because someone remembered it.

P The counter is the same fix signature the solution take uses, so one count drives both ladders.

P The ladder governs creation, not correction (Case Studies G-14). New skills and new articles wait for the third sighting; a wrong existing claim is corrected on the evidence, immediately, as a new article version with a CORRECTION ledger record — the writing practice of § 4 wins over the ladder for corrections. SD-1627 wrote three files on a first sighting; under this rule it writes one experience entry and corrects the one article it contradicted.

3. The closing walk

P Closing runs the v1 step-10 propagation walk, and — the part v1 got wrong — the walk is reconciled like a plan: every item is marked done or explicitly skipped with a reason. A silently halted checklist is the measured v1 failure mode; what the audit of 20.05.2026 counted is four error families recurring after their rule already existed (Baseline § 5) F: [audit, propagation rule].

The walk covers: the known-issue register (a closed ticket does not close its KI — 56 are open, KNOWN_ISSUES.md) · the living checklists (e.g. the policy sync compare checklist, which is meant to be extended by the cases that use it) · the experience index · the domain articles · the eval sets.

4. Writing rules

P Writes go only into the agent's own domain; cross-domain findings are handed to the owning domain's agent with their evidence, as a request record (Agents Memory § 2).

F The writing practice, inherited: belief order running system → consuming code → memory; four kinds of wrong (wrong, stale, ambiguous, environment-specific) with four different treatments; fix the claim where it is made; guide, not diary — no dates, sessions or incidents in article bodies, provenance in metadata, values replaced by the regenerating query; record the pattern, never the incident; no customer PII (rule).

5. Feedback into evaluation

P A precipitated skill or article changes what the module knows, so it re-runs the affected eval sets (CR-4). This is the loop that keeps precipitation honest: an addition that degrades the module's golden corpus is not an improvement, and the platform finds that out at publish time rather than on the next real case.

6. Consolidation — the dreaming pass

P On a schedule, separate from case closing — and this is where curation lives (decision 01.09.2026). The experiencing agent writes the entry while it still holds the context; the dreaming pass is what later catches the entry that only makes sense to someone who was there, and rewrites it for a reader who was not.

The pass: merge duplicates, re-read entries against the would this help a stranger test, prune what the running system has outgrown, resolve or explicitly mark contradictions, refresh each node's AGENTS.md one-liners, and run any 7th/20th refinement passes the ladder (§ 2) has fallen due. New nodes only when the § 2 gate is met — recurring content, a distinct owning profile, and a retrieval need the parent index cannot serve (Agents Memory § 5).

Challenges