Dilsher Singh

Problem

Every financed asset on Dualmint comes with provenance documents that state, in legal language, the yield an investor is promised. Payouts were checked against values in our database, not against what those documents actually committed to.

Constraints

• The documents are PDFs in a dozen layouts, some scanned and some inconsistent with themselves.
• A model can misread a number or invent one, and a payout check built on a wrong number is worse than no check at all.

Design

• I grouped the 1,342 documents into 12 templates by fingerprinting their layout, so the model extracts once per template plus two spot-checks, not once per document. The whole build cost about US$8 in API calls.
• Every extracted value must come with a page and a quote. Code checks that the quote exists on that page and contains the value, and rejects anything that fails. Output is validated against a schema before it goes anywhere.
• When a document states two different values for the same term, neither the model nor the code picks one. The field stays empty and every mention goes to a person.
• An admin reviews and confirms each template's terms in a review screen. Confirmed terms are never edited in place; a changed document goes back through intake as new provenance. Ingest is idempotent, so re-running the pipeline never creates duplicates.
• On every monthly yield deposit, the TypeScript backend compares the payout with the confirmed terms and reports the result, match or not.

Evals

I labelled gold answers for all 12 templates and checked them field by field. The first run scored 90%, and most of the mismatches turned out to be mistakes in my own labels, not the model. After fixing the labels and narrowing one over-broad rule, the pipeline reached 99% field accuracy on the human-verified eval set.

Result

Shipped to production in late October 2026. All 12 templates are confirmed, and the first payouts it checked all matched the confirmed terms.

Limits

The 99% figure holds for these 12 templates. Quote verification proves a quote exists, not that it is the right clause, which is why a person confirms every template before any payout is checked against it. The model never decides a money value.

Problem

Investors are paid from the revenue operators earn with financed machines. Every cycle has to pay out on time, and no cycle can pay out on bad data.

Constraints

• Revenue is reported by three independent sources: IoT telemetry, bank data and operator reports. They can disagree.
• A payout is money. Once it has gone out, it cannot be clawed back casually.

Design

• Three-way reconciliation gates every payout. Nothing is paid until telemetry, bank data and operator reports agree.
• A daily idempotent job replays the previous 24 hours of settlement events against the ingested records and emails an audit report.
• The job sorts discrepancies into three classes and fixes only the actionable one automatically.
• It never lowers a balance automatically, because that would destroy authoritative data. It logs the case and a human decides.
• Corrupted records are repaired by replaying the event log, with the pre-repair state verified first.

Result

• 13,800+ payout cycles over 18 consecutive months, 100% on time.
• Zero ledger-to-settlement discrepancies since April 2025.
• 13 corrupted records repaired by event-log replay, with zero balances changed.

Problem

Coding agents can produce a lot of code quickly. The goal was to get that speed without lowering the quality bar on systems that move money.

Constraints

• It had to work for the whole team, not for one person.
• It could not weaken review. Every change still has to be understood by a human before it merges.

Design

• Work starts as a PRD and is broken into scoped backlog issues, so an agent always has a clear, bounded task.
• Each repository carries its own agent scaffolding, AGENTS.md and agent skills, describing how that codebase is built and checked.
• Agent-generated code passes the same gates as any other code: strict TypeScript, lint and pre-commit checks.
• Human review gating merges.
• This is an engineering process, not an AI product.

Result

• Adopted by all 5 engineers across 10 repositories.
• Merge gatekeeper on 435 of 592 client merges.

Problem

The marketplace carries revenue, and it was running on aging versions: Next.js 12, React 17 and web3.js.

Constraints

• Trading could not stop. Every step had to ship to the live platform without interrupting it.
• Three major upgrades in one combined release would have been hard to reason about and hard to reverse.

Design

• The work was staged as separate upgrades: Next.js 12 to 15, React 17 to 19, and web3.js to ethers v6.
• Each stage shipped on its own, so a regression could only come from the one change that had just landed.
• One upgrade was deliberately rolled back when shipping safety warranted it, then redone later. Waiting a cycle on an upgrade is cheap; interrupting a live market is not.

Result

• Next.js 12 → 15, React 17 → 19 and web3.js → ethers v6 on a live, revenue-carrying platform.