Deterministic-first reasoning
Make known incident behavior reproducible and explainable before introducing probabilistic reasoning.
Why deterministic first
Known signatures should not require a remote model, variable output, or an opaque prompt. Most operational failures a team sees are ones it has seen before; those deserve an answer that is versioned, ordered, testable, and owned alongside the systems it describes. Deterministic rules also give the optional model path a clean boundary: models only see the cases the rules could not explain.
Evaluation contract
- Rules sort by descending priority; equal priorities retain declared configuration order.
- Legacy rules match when every all_contains term occurs case-insensitively in the supplied log text.
- Structured rules combine all, any, and not condition groups over typed incident fields.
- Structured candidates rank by priority, then specificity, then stable input order—ties never resolve randomly.
- Every match exposes rule ID, rule version, priority, matched conditions or terms, and evidence IDs.
- No match returns an honest unknown diagnosis rather than fabricating a cause.
Explanations you can test
The structured engine returns an explanation for every candidate—matched conditions, failed conditions, missing required evidence, and the selection reason for the winner. The CLI's rules test command evaluates a rule against a JSON fixture and emits machine-readable output, so rule behavior can be asserted in CI exactly like any other code.
Where models fit
A model is an optional escalation path for unknown cases. ModelUsePolicy bounds input characters, output tokens, tool calls, timeout, and prompt version. The gateway returns a schema-validated DiagnosisResult plus invocation metadata—provider, model, prompt version, and sizes—so model use stays auditable. Malformed output falls back to the deterministic unknown result.