In late 2024, we set out to build one product: a contingency-priced agent that read a finance team's vendor portfolio and recovered the money they were quietly forfeiting.
The pitch was simple. Every enterprise sits on a vendor archive — contracts, amendments, SOWs, invoices, performance reports, the email thread where the credit cap was renegotiated. Almost none of it is read in concert. SLA credits get forfeited. Rebates get unclaimed. Auto-renewals get rubber-stamped at a 7% escalation no one bothered to negotiate down. We thought we could turn that archive into recovered cash, and bill against the recovery itself.
We were right. The first anchor client recovered $1.4M in the first ninety days — every dollar of it from clauses that were already in force. None of which any installed system had flagged. None of which were exotic. The hard part wasn't reading any one document; it was reconciling Section 8.4(b) of an MSA against three amendments, two side letters, and the invoice from last Tuesday, at portfolio scale.
That's a data problem. And the data layer we built to solve it turned out to be the actual product.
§ I · The wedgeWhy AllCaps had to exist first.
Selling a data platform into a category that doesn't think of itself as having a data problem is a hard pitch. "Buy our vendor data layer so your AI applications can answer better" is an architecture conversation. Architecture conversations close slowly.
So we sold money back to the people who were owed it. AllCaps charged a percentage of recovery — no recovery, no fee. The customer ran a payback calculation on a napkin. Engineering took ninety days. The data layer ran underneath, doing the actual work, but nobody bought it. They bought the recovered cash.
This was the right shape for two reasons. First, contingency pricing forced us to be honest about depth — if our extractions were wrong, our citations missing, or our supersession logic flawed, we ate the cost. Second, the application produced an artifact procurement and finance already knew how to handle: a claim package, ready to file. The depth proved itself in dollars.
The data layer ran underneath, doing the actual work — but nobody bought it. They bought the cash. — Working note, late 2024
§ II · The pivot inside the productWhy every new application looked like a copy.
By the third AllCaps engagement, a pattern was undeniable. Customers would ask, mid-deployment, "can you also do renewals?" Or "can you watch for change-of-control across our vendor list?" Or "the CFO needs a copilot, not just a recovery agent — can you build that?"
The honest answer was: yes, in a week, because the data layer is already there. Each new application was a thin shell around the same underlying graph — contracts, amendments, invoices, performance reports, with clause-level supersession, cross-document reconciliation, runtime access controls, and provenance. The hard work was done. The applications were just different projections.
Around the same time, prospects who didn't want a managed service started showing up. They had their own AI teams. They wanted to build their own vendor-aware copilots. They were happy to license a data layer — they didn't want our application on top.
And every one of those teams was building the same thing in the basement: connectors to SharePoint and the ERP, extractors that ran the wrong way on amendments, a vector store that lost the link to the source page, a janky access-control layer bolted onto the side. Every team was rebuilding the floor. Several of them, with the same vendors, in the same companies, in parallel.
§ III · The decisionProductize the floor.
In mid-2025 we made the call. The data layer would graduate to its own product, with its own brand, its own API, its own pricing. AllCaps would remain — a first-class application on top, running in production, generating the kind of feedback only contingency-pricing creates. But d8m.io would be the platform.
This decision was easier to make than to execute. The work was unglamorous: tease apart the application logic from the platform primitives, write the public API spec, build the governance model so that procurement could see one view, finance another, and compliance a third — without the application code knowing the difference. Add the receipts.
The receipts mattered. Every response had to cite. Document, clause, page, excerpt. Every extracted field had to carry a confidence score. Every access decision had to surface in an _access block. Hallucination had to be treated as a bug, not a feature.
This is the work that makes d8m boring to describe and useful in practice. It does not announce itself. It just makes the question "what SLA credits are we owed from Orbital Cloud this quarter?" return $84,200, with three citations, against a real portfolio.
§ IV · TodayOne platform, several applications.
d8m.io is the platform. AllCaps is the application on top — production proof that the depth works on real contracts, against real money, every day. The next four applications were already in motion before we shipped the public API. Renewals. Risk and change-of-control. A finance copilot. A sourcing agent. Each from a different team, each independent of the others, each sharing the floor.
This is the shape we wanted. A platform proven by a wedge. A wedge that keeps running in production and keeps the platform honest. And a growing list of applications — ours and others — that get to start from a floor that's already been laid.
If you're building one of those applications, we'd like to talk. If you're a CFO who recognizes the AllCaps pitch, we'd like to talk too. Both conversations route through the same form. The depth is the same.