Diagnosis-as-Code
Represent incident diagnosis as versioned, reviewable configuration and typed evidence—not opaque model output.
The operating model
Diagnosis-as-Code makes failure signatures, hypotheses, calibration, missing evidence, and investigation steps explicit. Project teams own these rules, keep them next to the systems they describe, and review changes to them like application code. Because evaluation is deterministic, the same incident and the same rules always produce the same diagnosis—which makes diagnoses testable in CI with fixtures.
- Normalize a bounded incident into a vendor-neutral contract.
- Collect typed evidence through bounded, redacted, failure-aware providers.
- Evaluate stable, versioned rules in deterministic priority order.
- Keep observed facts separate from causal hypotheses.
- Expose missing evidence and human-review requirements explicitly.
- Persist the report and truth state in inspectable local storage.
Confidence is not authority
Rule confidence is authored calibration: how strongly a known signature supports the configured hypothesis. A specific error plus a verified schema diff may justify higher confidence than a generic timeout string. Lumis SDK does not compute confidence, and confidence cannot authorize remediation. Start conservatively, list missing evidence, review confirmed outcomes, and bump the rule version when calibration changes.
Unknown stays honest
When no deterministic rule matches, the result remains unknown rather than fabricating a cause. Optional model reasoning runs only when policy is enabled and a gateway is explicitly injected—and its output is still an unconfirmed hypothesis that requires review. This is deliberate: a wrong-but-confident diagnosis is more dangerous than an honest unknown.
Two rule engines, one contract
The SDK ships a legacy text engine (ordered all_contains rules over a log string) and a structured engine (all/any/not conditions over typed incident fields with required evidence and ranked candidates). Both produce the same DiagnosisResult contract. A project migrates its complete rule collection from one engine to the other in a single step—mixing both formats in one project is rejected to avoid ambiguous cross-engine ordering.