Skip to main content
Reconify monitors what should happen after money moves. A successful payment might need to credit a wallet, fulfill an order, or trigger another expected outcome, and Reconify compares the evidence your systems report against that expected sequence.

​
The model at a glance

Six concepts carry the whole model, and one diagram connects them: A flow defining stages and deadlines, an operation grouping events into immutable evidence, and the evaluation that produces either an OK result or an issue. Two of those pieces carry more detail than one row holds. A stage is one expected step: it names the event that starts the expectation, the event that completes it, and the service-level agreement between them. A target is one currency-specific monitored entity, identified by organization, entity type, entity ID, and currency. A wallet target retains its observed position, expected snapshot, difference, confidence, transactions, pending operations, and issues. An order target uses the canonical payment amount, and without an expected amount its difference reads as unavailable rather than zero.
The evidence timeline is the bridge between the public event record and the finding. It preserves what arrived, when it occurred, and which expected stage it satisfied or missed.

​
Three identities on one event

Every event carries a reference and an entity_id, and they answer different questions.
Reconify reads wlt_48291 as a wallet because payment_to_wallet has the entity type wallet, which is why no separate entity-type field exists. Events that share a reference are evaluated together, and their flow and participant identities have to agree with the flow’s rules. An optional third identity, correlation_id, links evidence that belongs to the same cross-service transaction but arrived under different references. It is investigation metadata: it never merges operations and never changes evaluation. See Correlation IDs. An optional causation_id points to one earlier event; it does not follow sequence. See Causation IDs.

​
Example: a payment succeeded, but the wallet was not credited

Consider one payment_to_wallet operation:
The payment starts and succeeds, and that success activates the next expectation: wallet.credited within five minutes.
The events remain available as evidence, and the issue names exactly what is missing. A credit that arrives later resolves the issue without erasing the breach:
Evaluation runs on each event’s occurred_at, not on the order in which events arrive, so late and out-of-order delivery reconstructs the operation without changing the original evidence.

​
Supported flows

Reconify owns four flow definitions, each with its own expected event path and deadlines.
Stage deadlines run on business time, which means the clock starts at the predecessor event’s occurred_at. A predecessor delivered after its business deadline breaches on arrival, and evidence that follows resolves the issue as resolved_late while the breach stays part of the history.

​
How evidence becomes a finding

The path from your request to a finding runs in five steps:
  1. Your system sends an event with a flow, type, reference, entity ID, and event time.
  2. Reconify stores it as immutable evidence.
  3. Events sharing a reference reconstruct an operation, ordered by occurred_at with the event ID as the tie-breaker for equal timestamps.
  4. The evaluator compares that operation against the flow’s stages and deadlines.
  5. Evidence that satisfies the flow leaves the operation OK. Evidence that is missing, late, mismatched, failed, or conflicting produces a finding for investigation.
A downstream event that arrives without its predecessor is kept as evidence and raises a data_quality issue, which is a signal about your producer rather than a breached operation.
An accepted ingestion result means Reconify stored the event for processing. It says nothing about whether the operation passed evaluation.

Send events

Submit event batches and handle every item result safely.

Operations

How evidence, deadlines, and late arrivals shape an operation.