Interas Research

Diagnosis

Diagnosis and Evidence Assembly

Step 8 of the pipeline is the sole AI call. It receives a bounded evidence file and returns a structured diagnosis. The design keeps the AI constrained, auditable, and safe to fail.


Bounded evidence assembly

Before any AI call is made, step 8 assembles an evidence file for the problem class being diagnosed. This file is bounded: it contains only the information relevant to that class of finding — a representative sample of the affected records, the detected field patterns, and the structural description of the divergence. The AI receives only this file.

The AI has no access to the full dataset. It has no access to the evaluation answer key. It cannot reach out to other systems. The bounded evidence file is the AI's complete view of the problem.

This constraint is intentional. It keeps the call's context predictable, auditable, and reproducible. The same evidence file, presented to the same model, will produce the same category of response — which means diagnosis behavior can be tested with injected fakes rather than live AI calls.

One call per problem class

The pipeline does not call AI once per finding or once per record. It calls AI once per distinct problem class — the clusters produced by step 6. If 9,834 findings collapse into 4 problem classes, the system makes 4 AI calls, regardless of how many records are in the dataset. This is the cost-control mechanism: AI spend scales with problem complexity, not data volume.

Fixed taxonomy, fixed action menu

The AI is asked to select from a fixed set of cause categories and a fixed set of fix actions. It does not generate free text that is then parsed; it responds within a constrained structure. This makes the output machine-readable by construction and eliminates a class of failures where a well-formed natural-language response cannot be mapped to an actionable result.

The taxonomy and action menu are defined at system configuration time and do not change between runs. This stability is what makes the AI's output gradeable: the evaluation harness knows the valid output space and can measure accuracy against it.

Safe degradation

Diagnosis never halts the pipeline. If the AI call fails, times out, or returns a result that does not conform to the expected structure, the step degrades gracefully: it assigns the "unknown" cause category, selects a conservative default fix action, and marks the diagnosis as degraded. The degradation is reported loudly — it is visible in the case record and reflected in the workspace's AI-status chip.

A degraded diagnosis is not a silent failure. It is an explicit, auditable outcome that an operator can act on. The pipeline continues to step 9 and step 10 regardless.

Honest AI-status reporting

The workspace reports the observed diagnosis fallback rate — how often diagnosis actually degraded in the most recent run — not the configured intent. If the system is configured to prefer diagnosis but AI calls are failing in practice, the status chip reflects the observed reality, not the configuration.

This matters because configuration and behavior can diverge: a network problem, a model change, or a context-length issue can cause degradation without changing any configuration value. Reporting observed behavior rather than configured intent surfaces those divergences when they happen.

The rule miner: authoring-time only

Control Desk includes an AI rule miner that can generate candidate detection rules from pasted policy or documentation text. This is a second use of AI in the system, but it is strictly separate from the runtime pipeline. The rule miner runs at authoring time only — when an operator is composing new detection rules — and its output enters the same governance intake flow (validate, preview, approve, activate) as any manually authored rule.

The rule miner is never part of a detection run. It never executes automatically. It never activates rules on its own. Every candidate rule it produces must cite the passage it was derived from, and every candidate must pass through the approve-then-activate two-step before it affects any future detection run. See Governance for the full intake model.


For how diagnosis results are graded and how recall is separated from AI precision, see Evaluation. For the full pipeline context in which diagnosis sits, see Pipeline.