3.8 KiB
Early diagnosis review v1
An investigation may request independent final evaluation before all hypothesis accounts become terminal. This is not acceptance of a cause or a coding task. The service performs no patch, SQL write or client automation.
Request and prerequisites
New investigation prompts (investigation_v2, investigation_project_v3) offer
next.kind = request_diagnosis, with reason and countercheck_refs.
The selected hypothesis must be strongly_supported, cite concrete nonempty
investigation evidence of its own, and cite an actual result from an alternative.
An alternative already rated supported/strongly_supported prevents a request.
The controller validates IDs and structure; whether the evidence establishes
causality and whether a negative result has sufficient coverage remain explicit
responsibilities of the independent final evaluator.
A request first becomes preparing. Outstanding results must be assessed before
review: the controller schedules their hypotheses, and permits defer (assessment
without closing the hypothesis) or a justified reject. No fresh research action
is launched while preparing. defer is not available during ordinary research.
All action reservations must be settled before entering BUILDING_DIAGNOSIS.
No account is artificially exhausted and no alternative is implicitly refuted.
The requested state includes the leading hypothesis, evidence, countercheck, reason and explicitly deferred alternatives. The existing confidence scheduler and its initial turn for each hypothesis remain in use outside preparation.
Independent decision and continuation
diagnosis_early_v1 evaluates every hypothesis, all evidence and remaining
uncertainty independently. Acceptance requires the requested hypothesis,
strongly_supported confidence, direct evidence for it, an adequate investigated
alternative countercheck and no other evaluation marked supported. Ordinary
final diagnosis validation remains mandatory. An accepted review creates the
normal diagnosis artifact; the existing separate Change Request and output
validators still decide whether a coding task can be issued. Missing coordinates
or other implementation prerequisites must remain explicit missing information.
An inconclusive review, insufficient confidence, competing support or exhausted invalid-response retries declines the request. The case returns to INVESTIGATING_HYPOTHESES in the same analysis revision. The immutable review reason is included in subsequent investigation context. No failure report or coding task is issued by this rejection. Account balances, assessed results, questions and evidence survive. The only reverse lifecycle transition is guarded by the persisted pending request and its declined review. It is not a general rewind.
Each review has its own context, calls and error namespace under
analysis/diagnosis/NNNN/early/NNNN/. Historical requests and prompts stay intact;
completed acceptance still uses the canonical diagnosis completion checkpoint.
A process restart reuses the persisted model call rather than requesting it again.
Pending old investigation prompts retain their original protocol. Existing loops
adopt early-review support at their next decision boundary.
Limits
[investigation].max_early_reviews = 3 is a configurable operational default,
frozen with the revision policy. Older policies without it use three. Reaching
the limit disables further early requests, not ordinary investigation or normal
final evaluation. A declined request also needs new evidence content before
another request; a fresh ID for identical content does not suffice.
This prevents repeated unchanged final evaluations. It is independent of per
hypothesis research budgets, token limits and provider retry configuration.
Confidence levels are qualitative ratings, not calibrated probabilities.