Deterministic evidence, measured in public
WardTrace

The Garcia File: one claim, five checks.

One remote-monitoring bill for one synthetic patient. Five things must be true for that bill to be clean. Scroll, and each check runs in order. Four pass. One fails, and one of the passes hides the strangest fact in the file. The result is not a score. It is two typed contradictions and a tamper-evident evidence bundle you can verify in your own browser.

The claim arrives

A routine bill, on its face.

Claim CLM-RPM-00049

CPT code
?
CPT 99454: the monthly device-supply code for remote monitoring. It pays for the device and its daily readings.
99454
Date of service
?
The day this month of monitoring was billed.
2024-07-20
Billed
?
What the provider asked the plan to pay.
$150.00
Paid
?
What the plan actually paid.
$120.00
Provider
?
The billing clinician. The name is synthetic-generator output, not a real person.
Melinda Gonzalez (synthetic)
Family Medicine, ME · NPI 12f07fd604
Patient
?
A demo alias. Mrs. Garcia is not a real patient, and there is no PHI anywhere in this system.
Mrs. Garcia (synthetic) · ID P-007741

One month of remote monitoring. A device sends readings from home. A clinician bills for the month. Most of these claims are clean.

For this bill to be clean, five things must be true.

  1. Physician order. A doctor ordered the monitoring.
  2. Patient consent. The patient agreed, on the record.
  3. Device serial. The readings came from her registered device.
  4. Readings ≥ 16 of 30 days. Enough days of data. Medicare requires 16.
  5. Physician review. A doctor actually looked at the results.
Case notes: how this case was chosen
  • All identities are synthetic. Provider and patient names come from the synthetic generator; the patient is shown under the demo alias 'Mrs. Garcia (synthetic)'.
  • Honest gap vs the demo-runbook target profile: no claim in this corpus combines a readings shortfall (<16 of 30 days) with clean order/consent/physician components — encounters that miss the readings floor also miss order, consent, and review by construction. This case is the closest real claim: device contradiction present, readings at exactly the CMS 16-day minimum (PASS, bare floor).
  • The readings calendar is derived from the reading-level telemetry table, which spans a fixed 30-day observation window (2024-06-01 to 2024-06-30) not aligned to the encounter date of service; the encounter-level record reports 16 transmission days. Both numbers are shown verbatim — the stream/record disagreement is part of the device-integrity finding.
  • No order-document record (order date, referenced serial) exists in this corpus; order and consent are per-encounter attestation flags, shown as such.

Corpus: synthetic · 521,997 claims · 2,000 providers · rules version 2026-07-22-w4-sparse-referral

Order Consent Device Days Review

Check 1 of 5 · Physician order

The order is real. PASS

An active physician order for remote monitoring is on file for this encounter.

This one is clean. First green mark.

Source record
source rpm_encounters
has_order true
Order Consent Device Days Review

Check 2 of 5 · Patient consent

The consent is sealed. PASS

Patient consent to remote monitoring is on file for this encounter.

Consent was sealed when the monitoring began, and the sealing method is patent filed.

Sealed consent leaf: source record
source rpm_encounters
has_consent_leaf true
note In this synthetic corpus, RPM consent is a per-encounter attestation; leaf-level consent documents exist only for surgical claims.
Order Consent Device Days Review device_signature_index

Check 3 of 5 · Device serial

The device does not match. FAIL

The encounter record registered device serial DEV-000049.

The readings say otherwise. All 60 readings that month came from serial SIMFLEET-N1-SERIAL.

And that serial is not hers alone. It appears in 33 patients’ streams, billed by 33 different providers.

rule device_signature_index

This rule indexes device signatures across every claim in the system. It fires when one signature shows up under unrelated billing providers.

All 60 readings were transmitted by device serial SIMFLEET-N1-SERIAL, which does not match serial DEV-000049 on the encounter record — and the transmitting serial also appears in 32 other patients' streams.

First red mark, and a contradiction chip goes into the dossier.

Source record
source rpm_encounters + rpm_telemetry
serial_on_encounter_record DEV-000049
serials_on_readings SIMFLEET-N1-SERIAL
reading_count 60
device_model_on_readings VitalStream-W3
other_patients_sharing_reading_serial 32
other_billing_providers_sharing_reading_serial 32
Order Consent Device Days Review device_signature_index telemetry_liveness

Check 4 of 5 · Readings ≥ 16 of 30 days

The readings were perfect. That was the problem. PASS

  1. 2024-06-01: 2 readings
  2. 2024-06-02: 2 readings
  3. 2024-06-03: 2 readings
  4. 2024-06-04: 2 readings
  5. 2024-06-05: 2 readings
  6. 2024-06-06: 2 readings
  7. 2024-06-07: 2 readings
  8. 2024-06-08: 2 readings
  9. 2024-06-09: 2 readings
  10. 2024-06-10: 2 readings
  11. 2024-06-11: 2 readings
  12. 2024-06-12: 2 readings
  13. 2024-06-13: 2 readings
  14. 2024-06-14: 2 readings
  15. 2024-06-15: 2 readings
  16. 2024-06-16: 2 readings
  17. 2024-06-17: 2 readings
  18. 2024-06-18: 2 readings
  19. 2024-06-19: 2 readings
  20. 2024-06-20: 2 readings
  21. 2024-06-21: 2 readings
  22. 2024-06-22: 2 readings
  23. 2024-06-23: 2 readings
  24. 2024-06-24: 2 readings
  25. 2024-06-25: 2 readings
  26. 2024-06-26: 2 readings
  27. 2024-06-27: 2 readings
  28. 2024-06-28: 2 readings
  29. 2024-06-29: 2 readings
  30. 2024-06-30: 2 readings

30 of 30 days. Medicare requires 16.

Now look at the rhythm. 2 readings a day. Every reading exactly 12 hours apart, for a month. People are not that regular. Machines are.

A second chip is minted: telemetry_liveness, liveness not established.

The encounter record reports 16 of 30 days transmitted — exactly the CMS minimum of 16. The reading-level stream shows transmissions on all 30 days at a fixed 12-hour cadence from the mismatched serial, which feeds the device contradiction above.

One more wrinkle, shown exactly as recorded: the encounter record reports 16 days transmitted, while the telemetry stream shows 30. The disagreement is part of the finding.

Source record
source rpm_encounters + rpm_telemetry
days_reported_on_encounter_record 16
days_required_cms 16
days_observed_in_telemetry 30
Order Consent Device Days Review device_signature_index telemetry_liveness

Check 5 of 5 · Physician review

The review happened. PASS

A review note exists and the reviewing physician has a treating relationship with the patient.

The honest parts get credit. Three checks passed because they were actually clean. The readings check passed the count, and its cadence became evidence anyway.

Final scorecard: four green, one red. Two contradiction chips.

Source record
source rpm_encounters
has_review_note true
has_treating_relationship true
Order Consent Device Days Review device_signature_index telemetry_liveness

The verdict

No score. Two typed contradictions.

The system does not produce a number between 0 and 100. It produces findings you can check, each one citing its rule and its source records.

rule telemetry_liveness

typed contradiction: liveness_not_established

failing signal classes: device_fingerprint, physiologic, serial_provenance, timing_entropy

source records · encounter: CLM-RPM-00049 · telemetry_readings: CLM-RPM-00049-R0000 .. CLM-RPM-00049-R0059

harm severity 6 · recommended action ESCALATE

rule device_signature_index

typed contradiction: shared_device_signature_across_billing_entities

matched set: 17 streams across 16 billing entities

source records · encounter: CLM-RPM-00049 · signature_index: device_signature_index (no raw readings retained)

harm severity 7 · recommended action ESCALATE

Recommended action on both: ESCALATE. A human decides. Never an auto-denial.

Order Consent Device Days Review device_signature_index telemetry_liveness

The bundle assembles

The case file becomes a chain.

Everything above is packed into an evidence bundle: 7 entries, in a fixed order. Each entry is hashed together with the hash before it. The first entry starts from sixty-four zeros.

  1. 0 claim 000000000000 9ff1e1d7367e
  2. 1 flag 9ff1e1d7367e 2ee8cd7b882f
  3. 2 flag 2ee8cd7b882f 06f1b4b91208
  4. 3 methodology 06f1b4b91208 04ec1ef9111a
  5. 4 gap_list 04ec1ef9111a 5f2c727d85d8
  6. 5 reproducibility 5f2c727d85d8 028241925c68
  7. 6 anchor 028241925c68 7b370f0c3f5d

Each entry’s second hash becomes the next entry’s first. Change one byte anywhere and every hash after it changes too.

Order Consent Device Days Review device_signature_index telemetry_liveness

Verify it yourself

Do not take our word for it.

This is the real bundle for this claim, not a mockup. Open the entries. Verify the chain. Then break it and watch it fail.

BND-CLM-RPM-00049-7b370f0c3f5d

claim CLM-RPM-00049 · schema 1.2.0 · anchor MOCK · genesis 000000000000..

  1. 0claim0000000000009ff1e1d7367e
  2. 1flag9ff1e1d7367e2ee8cd7b882f
  3. 2flag2ee8cd7b882f06f1b4b91208
  4. 3methodology06f1b4b9120804ec1ef9111a
  5. 4gap_list04ec1ef9111a5f2c727d85d8
  6. 5reproducibility5f2c727d85d8028241925c68
  7. 6anchor028241925c687b370f0c3f5d

content_hash 7b370f0c3f5d.. = the last entry hash. The same check runs as a gate on every build of this site.
Read the raw bundle JSON 
{"anchor_type":"MOCK","anchor_types":["MOCK"],"bundle_id":"BND-CLM-RPM-00049-7b370f0c3f5d","claim_id":"CLM-RPM-00049","content_hash":"7b370f0c3f5dbad6e5af2dfba7b5fc74dbdf7ec1a9c1225e006d3d6ff54e0bab","entries":[{"claim":{"charged":150.0,"claim_id":"CLM-RPM-00049","device_serial":"DEV-000049","dos":"2024-07-20","has_activation":true,"has_consent_leaf":true,"has_order":true,"has_review_note":true,"has_treating_relationship":true,"npi":"12f07fd604","paid":120.0,"patient_id":"P-007741","reading_days":16},"dataset_hash":"857f1926c36c4c947ae6340bd69c09e1504712dc8aa216ac6c89a139fedf2b43","entry_hash":"9ff1e1d7367e35fcb4d524afe9c9aeb0935e0c6b509842561524743094a43194","generated_at":"2026-07-09T00:00:00Z","prev_hash":"0000000000000000000000000000000000000000000000000000000000000000","rules_version":"2026-07-22-w4-sparse-referral","type":"claim"},{"entry_hash":"2ee8cd7b882f1e1d0d851b13fb89cc57b29680f6c5217e56c7f3fb66362c1ee4","flag":{"charged":150.0,"claim_id":"CLM-RPM-00049","confidence":1.0,"dos":"2024-07-20","evidence":"{'liveness': 'NOT_ESTABLISHED', 'failing_signal_classes': 'device_fingerprint,physiologic,serial_provenance,timing_entropy', 'signal_class_count': '4', 'composition_score': '0.9103', 'entropy_normalized': '-0.0000', 'value_sd': '0.2915', 'condition': 'chf', 'circadian_adjusted_persistence': '0.0769', 'fingerprint_patient_count': '22', 'device_fingerprint': '3bb89eaa69951f3b', 'n_readings': '60', 'recommended_action': 'ESCALATE', 'note': 'Liveness not established by composition of independent signal classes. Human review required \u2014 a genuinely regular patient routine is not fraud.'}","harm_severity":6,"npi":"12f07fd604","paid":120.0,"patient_id":"P-007741","primary_cpt":"99454","rule_name":"telemetry_liveness","severity":"TIER1"},"prev_hash":"9ff1e1d7367e35fcb4d524afe9c9aeb0935e0c6b509842561524743094a43194","type":"flag"},{"entry_hash":"06f1b4b912085262125038083832e87d1262bbca335852cf144da1ddbbc09381","flag":{"charged":150.0,"claim_id":"CLM-RPM-00049","confidence":1.0,"dos":"2024-07-20","evidence":"{'signature_hash': '7fbccfe959c0f005bf62e2ad445a9dab', 'matched_set_streams': '17', 'matched_set_billing_entities': '16', 'entropy_normalized': '-0.0000', 'circadian_adjusted_persistence': '0.0769', 'median_gap_hours': '12.00', 'raw_readings_retained': 'false', 'recommended_action': 'ESCALATE', 'note': 'One generator signature observed under multiple unrelated billing entities. Harm and priority elevated for every member of the matched set. Human review required.'}","harm_severity":7,"npi":"12f07fd604","paid":120.0,"patient_id":"P-007741","primary_cpt":"99454","rule_name":"device_signature_index","severity":"TIER1"},"prev_hash":"2ee8cd7b882f1e1d0d851b13fb89cc57b29680f6c5217e56c7f3fb66362c1ee4","type":"flag"},{"entry_hash":"04ec1ef9111aced28762081d2600fbeee6bfa30854d558bb4624f882e0a3164f","error_rate":"False-positive and false-negative rates on real-world data: pending pilot. No numeric field error rate is claimed.","method_validity":"Each flag entry above cites the deterministic rule that emitted it and its evidence fields; findings are typed contradictions, not scores.","prev_hash":"06f1b4b912085262125038083832e87d1262bbca335852cf144da1ddbbc09381","reliability_standard":{"bundle_schema_version":"1.2.0","code_commit":"538a0262750b4ccab3494ac1f29dd683ef6dc1f7","dataset_hash":"857f1926c36c4c947ae6340bd69c09e1504712dc8aa216ac6c89a139fedf2b43","rules_version":"2026-07-22-w4-sparse-referral"},"type":"methodology","validation_evidence":"All rule precision figures are measured against synthetic, by-construction ground truth (labeled archetype subsets). They are NOT field performance. A calibration pilot on real data is required before any field claim."},{"entry_hash":"5f2c727d85d8228aa2ff3013adb304749642db966cdb141a0a699f8e4abf90af","gaps":["Does not verify medical necessity of the underlying diagnosis or procedure.","Does not verify clinical accuracy of device readings or chart content.","Does not decide that fraud occurred; it documents typed contradictions on one claim for a human investigator, auditor, or court to weigh.","Does not verify events outside the ingested records (orders, consents, telemetry, notes, registries supplied to the engine)."],"prev_hash":"04ec1ef9111aced28762081d2600fbeee6bfa30854d558bb4624f882e0a3164f","type":"gap_list"},{"code_commit":"538a0262750b4ccab3494ac1f29dd683ef6dc1f7","dataset_hash":"857f1926c36c4c947ae6340bd69c09e1504712dc8aa216ac6c89a139fedf2b43","entry_hash":"028241925c68e73725d8c7e80527f2e67c400774a0891d31bfaa824ec06219c4","flag_hashes":["2daadcc3ce227b8f92a5bece88217db95c332bd3aa4e2e0c82894eb93de573f4","11cd3d34e7efe8ea094bf3db7abf194a680b667014eb9ae9d09b9845a8d2c77d"],"input_claim_hash":"6ba0a9085a0874a5814c921fa40f31fba4a4017f01d90274c4acddf23b95be0a","instructions":"Re-run build_evidence_bundle with identical claim_row, flags, dataset_hash, generated_at, code_commit and anchor='MOCK' for byte-identical output at this code commit.","prev_hash":"5f2c727d85d8228aa2ff3013adb304749642db966cdb141a0a699f8e4abf90af","rules_version":"2026-07-22-w4-sparse-referral","type":"reproducibility"},{"anchor_type":"MOCK","anchored_entry_hash":"028241925c68e73725d8c7e80527f2e67c400774a0891d31bfaa824ec06219c4","entry_hash":"7b370f0c3f5dbad6e5af2dfba7b5fc74dbdf7ec1a9c1225e006d3d6ff54e0bab","mock_token":"9a2a3937e763f8229c2abfb438ddeaf524f060d5119b4567cc162c86383c86b3","note":"Demo stub only. Production uses dual RFC-3161 TSA + OTS/Bitcoin anchors.","prev_hash":"028241925c68e73725d8c7e80527f2e67c400774a0891d31bfaa824ec06219c4","type":"anchor"}],"schema_version":"1.2.0"}

Download garcia_bundle.json. Chain verification recomputes each entry hash from the entry’s bytes plus the hash before it. One changed byte breaks every link after it. The buttons above run that math in your browser with WebCrypto, and the same module runs as a gate on every build of this site.

Order Consent Device Days Review device_signature_index telemetry_liveness

The gap list

What this bundle does not verify.

The bundle carries its own limits, in its own words. This is the gap list entry, verbatim:

  • Does not verify medical necessity of the underlying diagnosis or procedure.
  • Does not verify clinical accuracy of device readings or chart content.
  • Does not decide that fraud occurred; it documents typed contradictions on one claim for a human investigator, auditor, or court to weigh.
  • Does not verify events outside the ingested records (orders, consents, telemetry, notes, registries supplied to the engine).

That honesty is a design goal. A record that names its own limits is a record built to face scrutiny in court. Courts decide what to admit case by case, and we do not promise outcomes.

Order Consent Device Days Review device_signature_index telemetry_liveness

The anchor

The last entry is a timestamp. Ours says MOCK.

anchor_type MOCK

anchored entry hash 028241925c68.. · mock token 9a2a3937e763..

note, verbatim: “Demo stub only. Production uses dual RFC-3161 TSA + OTS/Bitcoin anchors.”

In this public demo the anchor is a deterministic MOCK label, and we tell you that. In production the same field carries OpenTimestamps and RFC-3161 confirmations. A mock is never presented as a real timestamp.

Order Consent Device Days Review device_signature_index telemetry_liveness

The scale

One case, told slowly. The system does this every time.

You just read one claim’s story, end to end. The engine writes one of these per billed encounter. In testing it scanned 521,997 synthetic claims with 28 rules.

Book a 20-minute walkthrough

Is this AI?

No. These are deterministic rules with measured precision. Every finding cites the rule and the record that produced it. The result is reproducible byte for byte.

What about real data?

Precision is measured on labeled synthetic data today. On your data we run a calibration pilot first and report your numbers. We will not quote synthetic precision as field performance.

Do you deny claims?

Never automatically. A suspicious claim routes to human review. The system escalates. It does not auto-deny.