OmniRecon
Governed reconciliation for systems that disagree
Can software reconcile conflicting records across systems while keeping model-driven decisions bounded, auditable and subject to policy?
THE PROBLEM
What is actually going wrong
A billing analyst or revenue accountant must reconcile usage, billing and rate-card exports that describe the same customer and month with different identifiers, dates and field names.
The manual process involves pulling exports, reconciling identities, aggregating usage, building a comparison sheet, triaging the flagged list, investigating each survivor, then deciding and acting. The steps that require judgement and chasing information consume most of the elapsed time.
The cost is not only under-billing. A charge for something never delivered creates a refund liability and trust problem, while the reasoning behind a correction often disappears into a Slack thread or cell comment.
WHAT I DID ABOUT IT
I built
A reconciliation platform that turns source records into immutable, provenance-stamped facts, matches what can be matched deterministically, and opens a case only for the residue.
An agent can investigate a case through scoped read tools and propose a resolution. A separate policy engine decides whether that action is automatic, needs human approval or is denied.
A correction is checked on the next ingestion pass rather than assumed to have worked. The case and event log retain the evidence, decision and outcome.
TRY IT YOURSELF
Demo
Demo in progress
No public interactive demo yet. The in-progress local demo drives one synthetic case through detection, investigation, approval, execution and self-reconciliation.
Want to see it sooner? Ask me.BEFORE AND AFTER
What changed
Before
20 to 50 hours per month- Pull the usage export
- Pull the billing export
- Reconcile identities by hand
- Aggregate usage to the invoice grain
- Build the comparison sheet
- Triage flagged rows
- Investigate each survivor
- Decide and act
After
Not measured- Ingest source records as facts
- Resolve entities and match deterministically
- Settle correspondences within tolerance
- Open cases for unresolved residue
- Investigate, propose and apply policy
- Verify any correction on the next ingestion
Exports and mapping tabsProvenance-stamped facts
Spreadsheet lookupsDeterministic correspondence rules
Flagged rowsCases with evidence and policy state
Usually uncheckedSelf-reconciliation on next ingestion
ARCHITECTURE
How does it work?
Source systems
Usage metering, billing and rate-card records describe the same customer activity from different perspectives.
Scoped connectors
MCP connectors expose narrow reads and separately gated writes, then normalise records at the boundary.
Fact store
DETERMINISTICImmutable facts retain source provenance and version history so matching can work from a stable record.
Matcher
DETERMINISTICTable-driven correspondence rules and tolerances settle what they can without a model.
Case workflow
Only unresolved residue reaches an agent, which investigates through scoped read tools and proposes a resolution.
Policy and verification
DETERMINISTICA pure policy function gates the proposed action, while a later ingestion verifies that an executed correction actually landed.
The split is deliberate: models investigate ambiguity, while matching, authorisation and arithmetic remain outside the model.
BUSINESS IMPACT
What could this mean for a real business?
- POTENTIAL
The system could concentrate human investigation on disagreements that deterministic rules cannot settle, rather than on every flagged row.
- POTENTIAL
A correction could remain visible and verifiable instead of becoming an unrecorded decision in a spreadsheet or Slack thread.
Observed means measured in a real engagement. Estimated is reasoned from the work but not measured. Potential is what the approach makes possible. Nothing here is dressed up as more than it is.
WHAT FAILED
What didn't work
NOT DOCUMENTED
No failed approaches have been documented for this experiment yet.
CODE
See the implementation
The source code remains private while OmniRecon is in progress. The architecture, design decisions and local demo flow are documented in the project repository.
SHARE AND ENJOY
Share and enjoy
Tell me what's going on. I'll come back within a business day, and if I'm not the right person for it I'll say so.