DRIFT Verification Lab · Datasheet Requirements, Implementation, and Fault Testing

Recorded evidence replay. Everything on this page is read from DRIFT's recorded report files. The page does not run Python or call Bob.

AI can write a sensor driver in minutes. How do we check it against the datasheet?

An engineer reviews page-cited requirements from the manufacturer's datasheet. IBM Bob builds the driver, a deterministic virtual sensor and the fault tests. Plain Python checks the runs against independent answers and records their bus transactions. Cited steps link back to the approved facts.

Open the workbench Read the code and evidence
DETAIL A TI TMP117 · temperature result register 0x00 · recorded run baseline_25c 0C 80 0x0C80 = 3200 steps × 1/128 °C = 25.0 °C 1 3 4 APPROVED REVIEWED · 2026-09-26 2
    Detail A. Drawn from recorded evidence: the bytes are from trace step 19 of the baseline_25c run, and the notes quote the approved TMP117 contract.
    Illustrative artwork: layered datasheet pages, colored signal paths and a sensor package
    Illustrative artwork. Recorded runs and measurements appear in the workbench.

    AI can write a driver in minutes. Checking it against the datasheet is the hard part.

    Every chip ships with a datasheet: dozens of pages of registers, bit fields, byte order, timing and calibration. Turning it into a driver is careful manual translation, usually done before the board exists. AI assistants can produce that code rapidly; teams still need to verify the behavior against the source.

    Today

    Translate by hand, find out on hardware

    Mistakes in byte order, timing or calibration surface on a physical bench, where they are slow to reproduce and hard to explain.

    With AI assistants

    Generated code still needs checking

    A generated driver can compile and look right while misreading the sensor. Reviewers need more than the code and the model's confidence.

    With DRIFT

    Behavior checked against reviewed facts

    Approved facts, independent expectations, a deterministic virtual sensor and a trace whose fact-tagged steps link to cited source pages.

    Who it is for

    • Firmware engineers bringing up a new sensor before boards arrive.
    • Hardware startups without a dedicated validation team.
    • Teams adopting AI assistants who need an audit trail for generated code.
    • Reviewers who need to show why a driver can be trusted.

    Where it goes

    Roadmap · not built
    1. Parts without drivers. Apply the same contract-first method to new or obscure chips.
    2. A virtual bench in CI. Replay every recorded scenario on every commit.
    3. Hardware in the loop. Compare the virtual trace with a real bus capture.
    4. Shared contracts. Reviewed, page-cited facts that teams can reuse across projects.

    How it works

    DEFDriver: the code that lets a processor talk to a chip over a bus.
    DEFVirtual sensor: a deterministic Python model of the chip's selected registers and conversion timing, with an integer microsecond clock. Ordinary code, not an AI imitating a sensor.
    WHYWhy not just ask for a driver? DRIFT returns code plus reviewed sources, independent expectations and reproducible failing cases that show when the code is wrong.
    1. 1
      EngineerChoose a narrow profileOne real sensor, one address, one mode.
    2. 2
      IBM BobDraft cited factsClaims from the vendor PDF, each with page and section.
    3. 3
      EngineerApprove by nameHashes bind the approved content to the exact PDF revision.
    4. 4
      IBM BobImplement and generateDriver, virtual sensor, faults, runner, reports, generator.
    5. 5
      PythonExecute and checkIndependent literal answers decide pass or fail.
    6. 6
      IBM BobDiagnose and repairReports tie each failure to its bytes. Expectations stayed fixed for the recorded repair.

    Recorded runs

    Each entry is one recorded run. Step through the bus transactions; steps tagged with source facts show those citations; other steps say when no fact reference was recorded. Injected faults are marked in orange where they occurred.

    Diagnosis and repair

    A seeded defective driver reads the right bytes in the wrong order. Because the report records the bytes, the cause is visible rather than guessed. Bob patched a separate copy against the same fixed expectations; the original stays broken on purpose as a negative control.

    The actual patch

    repair_diff.patch
    Expectations unchanged: tests/oracles/tmp117_vectors.json

    A defect the checks found on their own

    Separately from the seeded defect, Bob's first TMP117 virtual device lost the finished temperature when a configuration read cleared the ready flag. Integration tests caught it. Bob corrected the model; the independent temperature expectations did not change.

    Approved 2026-09-27 · 3 of 3 recorded cases observed

    Second sensor: Bosch BME280

    The TMP117 hands back a finished temperature. The BME280 does not: the driver must read six calibration bytes stored little-endian and signed, assemble a 20-bit raw reading, and run Bosch's integer compensation formula. Different byte order, different conversion semantics, same workflow.

    Carried over unchanged

    • Register bus and virtual clock interfaces
    • Contract format and human approval
    • Fault injection and report format
    • This workbench

    New for this sensor

    • 13 cited facts from the Bosch datasheet
    • Calibration read and compensation decoder
    • Forced-mode virtual sensor, 4,000 µs conversion
    • Device-specific runner, template and generator output

    Evidence and limits

    Counts marked "from reports" are computed live from the evidence files on this page. Supplementary checks are software results from an independent review snapshot, kept separate from the test suite.

    FIGUREMEANINGSTAMP

    Evidence files

      Limits

      • Two reviewed, device-specific profiles; BME280 is temperature-only forced mode.
      • Software verification against virtual sensors. No electrical waveform model.
      • No physical hardware validation and no measured hardware accuracy.
      • No arbitrary-PDF ingestion; every contract needs a human review.
      • This site replays recorded Python evidence. No measured time savings.
      • Mature drivers exist for both parts; they were chosen because correct behavior is knowable.