Financial correctness
Implemented exact integer money, an immutable double-entry ledger, and deterministic reconciliation with explicit unmatched and ineligible outcomes.
Vigil / Flow
Find the financial records that do not agree.
A financial reconciliation system that traces processor and bank evidence through exact-money accounting, deterministic matching, and operational investigation.
Financial reconciliation / independent engineering project
TypeScriptPostgreSQLNext.jsExact moneyDurable workers
Who it is for
Financial operations teams investigating payment, processor, settlement and bank records. This independent system demonstrates that workflow with synthetic data.
The problem it solves
A successful payment job is not proof that the money reconciles. Processor records, settlements and bank observations can disagree, arrive twice, or lack independent completeness evidence. Operators need an explanation that preserves those distinctions.
What I personally built
Exact-money accounting, deterministic reconciliation, recoverable workers, and the read-only investigation interface.
Recoverable processing
Built ingestion and durable worker paths around stable identities, transactional intent, retries and retained failures so processing history remains inspectable.
Operational evidence
Built a read-only Next.js investigation surface over approved PostgreSQL reads, separating financial state, operational case status and current allocation proof.
How the product works
6 inspectable stepsCaptured from the local production build against a disposable PostgreSQL database. All financial records are synthetic. The deployment is ephemeral and the operations screens are read-only; availability is not promised.
Choose a detail step to use zoom and dimming.
Source Completeness is UNKNOWN. Successful ingestion alone does not establish independent account-period closure.
Guided inspection
Step 1 of 6
Read financial assurance
The dashboard separates financial assurance, structural integrity, operational cases and terminal work. The intentionally imperfect dataset keeps failed and unknown checks visible.
Authentic application captures. These controls explore screenshot evidence; they do not operate the app. Use Zoom to evidence, dim the surroundings, or open the full-resolution image. The text transcript below works without JavaScript.
Read every walkthrough step as text
1. Read financial assurance
The dashboard separates financial assurance, structural integrity, operational cases and terminal work. The intentionally imperfect dataset keeps failed and unknown checks visible.
Source Completeness is UNKNOWN. Successful ingestion alone does not establish independent account-period closure.
Inspect corresponding screenshot (opens in a new tab)2. Inspect reconciliation results
Run summaries preserve processor and bank populations separately. The anomalous run contains matched, unmatched and ineligible items instead of presenting a misleading all-green summary.
Frozen outcomes are historical; the CURRENT PROOF column is a separate statement about present allocations.
Inspect corresponding screenshot (opens in a new tab)3. Trace settlement evidence
A completed run retains its rule version, time window, currency, member counts and population hash. The next section links the decision to processor provenance.
RULE VERSION and CURRENCY make the matching context explicit. The full population contains 12 processor items and 10 bank items; COMPLETED does not mean every item matched.
Inspect corresponding screenshot (opens in a new tab)4. Check completeness controls
Inspect completeness and assurance controls alongside reconciliation. Missing independent evidence remains visible instead of being inferred from successful processing.
A healthy worker does not prove complete financial records. Unknown controls stay unknown.
Inspect corresponding screenshot (opens in a new tab)5. Investigate exceptions
The exception queue exposes classification, assignment and linked runs. Accepting a risk can close the operational case while the missing bank movement remains financially unreconciled.
The accepted-risk case is RESOLVED / ACCEPTED RISK and still UNRECONCILED. Its PHP amount is a case value, not an extra amount to add to total exposure.
Inspect corresponding screenshot (opens in a new tab)6. Inspect retained failures
The demo provisioner deliberately introduces transient and poison work. Retaining these states makes recovery needs visible without treating worker success as financial reconciliation.
Failures here are deliberately injected demo scenarios. The screenshot does not establish production resilience or an uptime guarantee.
Inspect corresponding screenshot (opens in a new tab)
Investigate a synthetic reconciliation
Local Vigil / Flow production build; disposable PostgreSQL and synthetic financial inputs. The real pipeline prepares reconciliation before recording; the UI is read-only.
Recording transcript
- Read the financial overview and distinguish FAIL, PASS and UNKNOWN.
- Review completed reconciliation runs, matched records and unresolved populations.
- Open the anomalous run and inspect settlement and bank evidence.
- Review operational exceptions, independent completeness controls and processing workers.
Read the Phase 5D capture and verification report
Inspect the mobile captures (390 × 844)
Difficult engineering decisions
Separate closure from correctness
A resolved exception does not make a missing bank movement reconciled. Historical outcomes, current allocation proof and case status are separate statements.
Preserve an honest unknown
Successful ingestion cannot establish independent source completeness. The controls retain UNKNOWN when account-period closure has no independent evidence.
Architecture behind the interface
Exact amounts across boundaries
Money uses bigint internally and integer strings at serialization boundaries. Currency stays explicit; the browser does not calculate authoritative financial truth.
libs/money/src/index.ts (opens in a new tab)Domain rules, PostgreSQL enforcement
The modular monolith separates financial domains from database adapters. Frozen reconciliation populations preserve historical outcomes while current proof is evaluated separately.
libs/reconciliation-domain/src/index.ts (opens in a new tab)Server-side operations reads
The operations app consumes a server-only read layer. Bounded, parameterized queries and explicit unavailable states avoid turning failed queries into healthy empty dashboards.
apps/ops/server/read.ts (opens in a new tab)Evidence, with boundaries
Read Phase 5 verification reportUpstream results below are attributed to their recorded checks. This portfolio change does not rerun every application suite.
Executed browser capture
Playwright loaded six real database-backed screens: overview, reconciliation, run detail, exceptions, controls and workers. No unhandled page errors were observed.
Executed correctness tests
All 15 unit-test targets, 5 boundary checks, 4 Stripe HTTP contract tests and 9 deployment/access tests passed. A further 87 PostgreSQL integration, browser and resilience tests passed locally. See the report for exact scope and commands.
Source-backed architecture
Pinned source links connect the money model, reconciliation domain and server-side operations reads to this capture revision. Local regression evidence covers the selected suites; it does not establish a live deployment or all repository gates.
What remains unverified
Working implementation and release readiness have different evidence requirements.
- The operations interface is investigation-first and read-only. Ingestion and reconciliation were performed through the existing local pipeline; the walkthrough does not simulate UI commands to run them.
- No standalone transaction inspection screen was found. The captured run detail provides settlement population and provenance evidence, rather than a fabricated transaction browser.
- No AWS or Stripe calls were made for this task. The upstream Phase 15 report records an ephemeral hosted demo and actual runtime teardown; it says the dashboard is intentionally offline. Local captures do not establish current availability, production readiness, compliance, scale or real-bank completeness.
- The operations, operations-browser, reconciliation, exceptions and resilience integration suites passed against disposable PostgreSQL. Other integration files and live deployment checks were not run; this is not the full repository release gate.
Follow the source
Open repository (opens in a new tab)Source links are pinned to the inspected revision. The Phase 5 report distinguishes retained captures, current source, prior test results and checks executed for this portfolio change.