Evidence & Provenance

Data Verification Policy

The source hierarchy, status model, measurement conditions, review workflow, and correction process used for AIFlasher technical data.

Effective
11 Jul 2026
Version
1.0
Owner
Vidarbha Phonefix
Status
Published
Verified and working data remain separate

New or incomplete records belong in the working database until source, conditions, applicability, and reviewer status are established.

01

Verification status model

How AIFlasher labels evidence maturity.

Verified
Reviewed against strong source evidence and confirmed under documented conditions.
Cross-checked
Supported by more than one independent source or measurement set.
Needs review
Useful provisional information that requires expert or bench confirmation.
Unverified
Not suitable for operational repair decisions.
Deprecated
Retained for history but superseded or no longer recommended.
02

Source hierarchy

Preferred evidence types for technical records.

  1. Manufacturer datasheet or official service documentation
  2. Model-specific schematic or board view used lawfully
  3. Known-good measurement with documented conditions
  4. Tool log, oscilloscope trace, or programmer result
  5. Bench photo or repeatable repair case
  6. Community report requiring independent confirmation
03

Measurement conditions

Minimum context required for reusable values.

A measurement record should identify model, board revision, power state, battery/USB state, probe orientation, measurement point, tool mode, reference ground, temperature where relevant, tolerance, and source.

A value without its measurement conditions must not be presented as a universal specification.

04

Required provenance fields

Metadata attached to rules and records.

verification_status
Verified, cross-checked, needs review, unverified, or deprecated.
source_type
Datasheet, schematic, board view, known-good measurement, tool log, bench photo, or repair case.
tool_origin
Instrument or software that produced the evidence.
evidence_notes
Conditions, caveats, conflicts, and reviewer observations.
last_reviewed_at
Date of the most recent technical review.
05

Review workflow

How new technical content should enter the verified database.

  1. Submit evidence into the working database.
  2. Validate schema and model applicability.
  3. Cross-check source identity and measurement conditions.
  4. Compare against independent evidence or known-good hardware.
  5. Assign review status and reviewer notes.
  6. Promote to the verified database only after approval.
06

Conflicting evidence

How disagreement is represented.

Conflicting readings are not silently averaged or discarded. The record should identify the conflicting source, hardware revision, measurement condition, and reason the evidence may differ.

Rules affected by unresolved conflicts should remain marked needs review.

07

Corrections and withdrawal

How records are updated safely.

Correction requests should include the record or rule ID, device and board revision, evidence source, measurement conditions, and proposed correction. Unsafe or unsupported records may be withdrawn immediately while review continues.