Nexum - Evidence Before Action

Wealth-management AI that ships every recommendation with its receipts.

Comment

A financial recommendation is a claim, and a claim earns trust the way evidence does. A forecast, an allocation, a trade instruction: each one has to chain back to its basis, name who built it, and come out the same when anyone checks it again. That test is the one Nexum is built to pass.

What inspired this

I learned evidence discipline as a fraud examiner before I ever applied it to software. Fraud work teaches one lesson that never leaves: the confident story is the least reliable artifact in the room. What survives an audit is the chain. Which record, from which source, sealed by whom, reconciled against what. When the chain holds, the conclusion defends itself. When the chain breaks, the story is all that remains, and a story is exactly what an examiner refuses to accept.

Agentic AI arrived in finance speaking in the voice an examiner distrusts most: fluent, confident, and unaccompanied by receipts. A model recommends a portfolio change and offers, as its entire case, the fact that it said so. Decades in enterprise technology, from econometrics to agents, sharpened that unease into a precise distinction: a model that is right on average is a different achievement from a model whose specific output you can defend to an auditor, a regulator, or a client about to act on it. My doctoral research studies claim reliability in agentic AI, what makes a claim from an autonomous system trustworthy and what it takes to prove that rather than assert it. The research and the fraud work converge on one demand. A recommendation must arrive with its chain of custody.

Wealth management is where that demand bites hardest. An advisory team cannot recommend a portfolio change on the strength of a confidence score. A self-directed investor cannot inspect a black box and decide whether to trust it. Both need a recommendation that carries its own proof.

I built Nexum to answer that need directly, and I built it to answer a second question at the same time. If an AI system has to earn trust by showing its work, the software that builds that system should have to clear the same test. Everything below is the record of holding a coding agent to the evidentiary standard a fraud examiner would apply to it.

What it does

Nexum is one evidence engine behind two products: Nexum Fiducia, for advisory teams, and Nexum Prism, for self-directed investors. Every recommendation moves through the same ordered chain.

A forecast model produces a prediction, and a real SHAP explainer attributes it to the input features. SHAP is additive: the prediction decomposes into a baseline value \(\phi_0\) and one attribution \(\phi_i\) per feature,

$$ f(x) = \phi_0 + \sum_{i=1}^{M} \phi_i(x). $$

Nexum reconstructs that identity from the sealed artifact and tests it against a declared bound: an additivity residual no greater than \(10^{-5}\) in decimal-return units, one tenth of a basis point,

$$ \left| f(x) - \left(\phi_0 + \sum_{i=1}^{M} \phi_i(x)\right) \right| \le 10^{-5}. $$

That forecast feeds a constrained optimizer, a long-only mean-variance allocation with a declared risk-aversion coefficient \(\gamma\), an expected-return vector \(\mu\), and a covariance matrix \(\Sigma\). The classic form of that problem chooses weights \(w\) to solve

$$ \max_{w} \; \mu^{\top} w - \frac{\gamma}{2} w^{\top} \Sigma w, \qquad \text{subject to} \qquad \mathbf{1}^{\top} w = 1, \quad w \ge 0, $$

plus the asset, group, and return-floor bounds a mandate declares. The allocation keeps its own evidence separate from the forecast's SHAP values: constraint residuals, binding bounds, risk-aversion sensitivity, and one counterfactual solve per supplied constraint. A trade engine turns the allocation into exact fractional-share instructions, and a hash-linked bundle ties all three artifacts together. The whole bundle replays to identical bytes on demand, and every step signs into an audit chain that commits a recommendation only once an independent receipt confirms it landed in durable storage.

The product's own control document names the current release mode: authenticated read-only evaluation, mutations held off by explicit configuration rather than by a missing feature. That boundary is itself evidence. It states exactly what the system has proven and declines to claim the rest.

How I built it

OpenAI Codex built the production system inside the constraints I set. I own the architecture: the evidence chain, the fail-closed gates, the compatibility contract every consumer has to pass before it can act. Codex owns the plumbing that turned that architecture into a running, two-product deployment across four repositories: the evidence engine, a shared product backend, and a dedicated hardened application for each of the two products, Fiducia and Prism. It wrote the Fly infrastructure, the security hardening, the tenant-scoped history APIs, the encrypted backup and restore, the continuous monitoring, and the readiness gate that binds the audit trail and the reliability score to the same fail-closed check the recommendation engine already enforced on itself.

The number refused to sit still while I wrote this. It was nine merged pull requests the first time I counted them. Then I found the product-application repositories I had left out of my own count, and the true figure settled at forty-six across four repositories: ten in the evidence engine, twenty-three in the shared product backend, five in the Fiducia application, and eight in the Prism application. Every reading came from GitHub's own pull-request records, filtered to the branch prefix Codex names its own work with, rather than from a commit-message search, which undercounts once squash merges enter a history. The lesson repeated itself: even the count of the work needed its own verification.

The review ran in both directions, and that is the part I am proudest of. I reviewed every pull request before I merged it. The system reviewed Codex too. A six-check compatibility handshake gates every consumer of the engine, including the product backend Codex built: live health metadata, an authenticated principal, a versioned contract, a package-pinned manifest, an OpenAPI digest recomputed live and matched against that manifest, and an engine-version cross-check. A production acceptance verifier runs the full recommendation sequence, forces a real process restart, and confirms the recovered state before it calls a deployment accepted. The first production acceptance closed on receipts 9330c2e4 and 15f1c2c8, one before a forced restart and one after, on the same signed chain. Every pull request that touched a production path had to clear those gates before I merged it. My coding agent shipped the deployment. My evidence engine reviewed my coding agent.

The challenges

The hardest constraint turned out to be the simplest one. A signed audit chain has to stay strictly ordered, so the system runs one machine, one worker, always on. That single-writer topology follows directly from what a hash chain requires to stay a chain.

I lost my own product bearer keys the day I minted them, and it cost nothing: the system stores only credential digests, and rotation is the recovery path. Losing a key on day one proved the design correct.

The most expensive bug was also the easiest one to have avoided. A production deployment failed silently. An hour of remote debugging found nothing, and a one-minute local reproduction found the cause: the ASGI entrypoint needed a factory function rather than a bare application object. I reproduce locally first now, without exception.

The newest challenge arrived on the day I was finishing this submission. I ran two coding agents, Codex and a second assistant, against the same working directory at the same time, and their commits started colliding with each other rather than with the product. The fix was procedural: one agent now writes a task brief directly into the repository, the other executes it, and each stays out of a repository the other has claimed. It is a small rule, and it is the one that let this story get written on time.

What I learned

The lesson that generalizes past this one project is the one I set out looking for. Evidence discipline has to constrain the system while it is still being built, or the finished product only looks disciplined from the outside.

I asked Nexum's own recommendations to prove themselves before they could commit. I ended up asking the same of the pull requests that built Nexum, and of the essay you are reading right now, whose central number I re-verified and corrected, once I found the repositories I had left out of my own count, until it was finally true, because a stale figure in a story about evidence would have been its own kind of failure. Only a verified receipt commits. That rule spread past the product. By the end, it was the rule I was writing under too.

Built With

Share this project:

Updates