
Insurance fails when one date pretends to be five
A mental-health Session may happen on Tuesday. The Claim may arrive on Wednesday. An insurer may ask for evidence on Thursday, decide it on Monday, issue remittance a week later and move the money after that. Flatten those facts into one updated date and the history becomes impossible to reproduce.
That is not an accounting detail. It affects Claims operations, complaints, reconciliation, actuarial development and any review that asks what an Organization knew at a particular cutoff.
Two times for every fact
The Heyrafiki timeline records business time and knowledge time separately. The first says when the underlying Care, decision or money fact became effective. The second says when the system received and recorded it. The Claim valuation API applies both clocks to an explicit cutoff, so a backdated adjustment first received on 2 August cannot change the view produced for 31 July.
Heyrafiki carries both clocks through the mental-health insurance evidence chain, from delivered Care and policy version to Claim decision, remittance and observed settlement. The public API, Assurance Graph and adversarial benchmark make that chain independently reproducible.
The same history can answer an operations question, an actuarial cutoff and a regulatory review without creating three competing versions of the Claim. That is the practical advantage of preserving when a fact happened and when it became known.
Five failures the benchmark catches
The benchmark covers the public API, accountable controls, Claim and settlement identities, and the valuation timeline. Each adversarial case changes one fact and must fail for a specific reason.
- Duplicate event. Rejected, because one business fact cannot appear twice under the same identity.
- Out-of-order knowledge. Rejected, because the system cannot silently rearrange what it knew and when.
- Future knowledge. Rejected, because a valuation cannot use an event recorded after its cutoff.
- Unbalanced adjudication. Rejected, because billed amount must equal payer liability, patient responsibility and adjustment.
- Settlement above liability. Rejected, because observed movement cannot exceed the adjudicated payer amount without a separately governed correction.
What an insurer or regulator can inspect
The Assurance Graph links each public API operation to a named control, responsible owner, published authority source and executable evidence. A reviewer can move from policy version to Claim decision, from remittance advice to independent settlement evidence, and from a public statement to the test that supports it.
The graph keeps each authority boundary explicit across IRA Claims and market-conduct guidance, DHA certification and Health Information Exchange material, CPB licensing authority and government API access. Reviewers can see which source governs each control and where Heyrafiki enforces it.
What the evidence can support next
Once the history is reproducible, researchers can ask sharper questions. Which reporting delays are operational rather than clinical? How do authorization rules change access and outstanding liability? Which aggregate Benefit signals improve network planning without exposing a Person's Care? Those questions need declared cohorts, baselines, approved data, error analysis and expert review.
The benchmark is open to insurer, government, actuarial, research and engineering teams. Each contributed scenario carries declared inputs, an authority boundary, expected outputs, an adversarial case and one repeatable command any reviewer can run.
Insurers, regulators, actuaries and researchers can extend the open benchmark with their operating assumptions and review every result against the same reproducible standard.




