Deterministic text rules

Encode stable log-signature rules, evidence gaps, and safe investigation steps in a versioned rule set.

PHASE 1 · PRE-1.0PYTHON 3.11+EDIT ON GITHUB ↗

Rule-set document

yaml

apiVersion: lumis.dev/v1
kind: DiagnosisRuleSet
metadata:
  name: customer-pipeline-rules
spec:
  rules:
    - id: missing-customer-id
      name: missing-customer-id
      version: "1"
      priority: 100
      all_contains: ["KeyError", "customer_id"]
      classification: schema_change
      severity: medium
      summary: A required customer identifier was unavailable.
      root_cause_hypothesis: The upstream schema may have changed.
      confidence: 0.65
      missing_evidence: [current input schema, previous successful schema]
      recommended_next_steps:
        - Compare the current and previous successful schemas.
      suggested_playbook: investigate_schema_contract

A DiagnosisRuleSet holds ordered text rules for the common case where the incident signal is one log string. Each rule carries its own identity, calibration, and safe next steps.

Rule fields

Field	Meaning
id	Required stable machine-readable identity used in explanations and evidence references.
name	Human-readable rule name retained in reports.
version	Project-controlled rule revision; change it when the rule's meaning changes.
priority	Higher values run first; equal priorities retain configured order.
all_contains	Every text fragment must occur case-insensitively in the supplied log.
classification / severity	Project-defined failure category and low/medium/high/critical severity.
summary / root_cause_hypothesis	Observed failure class and its explicitly uncertain possible cause.
confidence	Human-authored calibration of the hypothesis given this signature.
missing_evidence	Context needed to strengthen, contradict, or reject the hypothesis.
recommended_next_steps	Safe investigation work; never automatically executed.
suggested_playbook	Candidate playbook name; never execution authority.

Ordering and explanation

Rules run by descending priority and then file order. A successful match exposes rule ID, version, priority, matched terms, and evidence IDs through diagnose_text_with_explanation, so every result can be explained and reproduced.

When to use structured rules instead

all_contains matching is deliberately simple. When your incidents carry structured fields—schema diff counts, component types, labels, numeric thresholds—or when a rule should only win with certain evidence present, migrate the project to structured DiagnosisRule documents. A project uses one engine at a time; the structured-rules page includes the migration checklist.