Installed rules are evaluated against explicit evidence fields. The engine must return no match rather than inventing an unsupported diagnosis.
Engine overview
The deterministic rule-evaluation workflow.
AIFlasher evaluates structured case evidence against locally installed, versioned diagnostic rules. It does not infer a definitive hardware fault from a single current value.
Evidence intake
How technician observations become a case object.
The intake captures device context, platform, symptom, current pattern, power-button response, power source, battery state, and optional advanced evidence. Each reading is retained as a separate field with its own condition.
Peak current is not treated as stable current, and pre-prompt behaviour is not inferred from equal values.
Normalization and validation
How identifiers and measurements are prepared.
Part numbers can be normalised for comparison, while model and platform selections remain visible for technician confirmation. Numeric values are parsed as explicit units and invalid values are rejected.
Uploaded rule and model files must match supported schema versions before evaluation.
Rule matching
How candidate rules are selected.
Rules are filtered by platform, symptom, optional PMIC applicability, and their condition set. All conditions in a rule must pass. A rule can require numeric comparisons, bounded ranges, or categorical values.
More specific matches may be ranked above broader matches, but ranking does not transform author judgement into statistical probability.
Diagnostic output
What the technician receives.
The result presents matched evidence, possible blocked stage, likely causes, required confirmation tests, rule identifier, verification status, and limitations. Where no rule matches, the correct output is “no matching rule”.
Likelihood and confidence labels
Why displayed confidence is not a probability.
AUTHOR-ASSESSED
High, medium, and low labels describe the rule author’s assessment of diagnostic usefulness. They are not derived from a validated population of confirmed repairs unless a future record explicitly states otherwise.
Safety gates
Conditions that should stop or redirect a workflow.
Unsafe or incomplete evidence should lead to a confirmation test, warning, or stop condition. Examples include unidentified rails, excessive pre-prompt draw, incompatible power sources, missing board revision, or an unreviewed rule.
Known limitations
Current boundaries of the v0.x engine.
- Sparse device and PMIC coverage
- No automatic schematic interpretation
- No calibrated repair-outcome model
- Uploaded logs are not guaranteed to be fully parsed
- Board-specific voltage expectations require verified profiles