Provenance-Constrained Generation: The Architecture for AI in Audit-Required Work

Opening

I didn't set out to build an architectural pattern. I built JCoBee because I'd spent more than twenty years in M&A and knew what a silent formula bug costs. Three of those years were running acquisition strategy at Tyco, where the difference between a clean deal and a quiet disaster sometimes came down to whether someone caught a number that didn't trace back to source. I'd lived enough of that to know what I wanted. A system that made it structurally impossible for a number to appear in a memo without a verifiable path back to the document it came from.

The decisions I made about how to use AI in JCoBee were decisions about M&A specifically. Which numbers needed to be auditable. Which claims needed to trace to source documents. Which kinds of work were safe to let a language model do, and which were not. I wasn't claiming to invent anything. I was building the right system for a domain I understood.

Then someone in a completely different industry approached me about applying the same methodology to their problem. Not M&A. Not anything close to M&A. A space where unstructured input had to become structured analysis, where the analysis had to be defensible to a third party, and where the cost of a confidently wrong number was real. I sat down to think about whether the JCoBee architecture would fit, and realized it fit cleanly. Different inputs. Different domain. Different audience. Same three-layer pattern. AI at the edges, deterministic math in the middle, provenance binding the whole.

That's when I realized I hadn't built an M&A system. I'd built a worked example of an architectural pattern that applies anywhere AI meets a domain that requires defensible output. M&A was the first proof. The second industry was the moment the pattern became visible as a pattern. The architecture was always there. I just couldn't see it as transferable until someone outside my world asked for it.

This essay is the pattern, named and explained.

AI at the edges. Math in the middle. Provenance binding the whole.

I call it provenance-constrained generation. I think it's the correct architecture for any AI-enabled system in audit-required industries right now. Lending. Insurance underwriting. Clinical decision support. Pharmaceutical research. Audit. Tax. Regulated finance. And yes, mergers and acquisitions. Anywhere a numerical claim has to be defensible to a third party, anywhere a wrong number costs money or causes harm, anywhere an auditor or regulator or counterparty will eventually review the work.

The pattern will refine as the technology evolves. AI capabilities will keep changing. But for the current state of language models, given what they're genuinely good at and where their failure modes are catastrophic, this is the architecture. Not better models. Better architecture.

What follows is the case for that claim.

Why naive AI fails in audit-required work

The conversation about AI in regulated industries is dominated by stories of failure. A founder uses ChatGPT to value their company and gets a hallucinated multiple. A lawyer cites case law that doesn't exist. A clinician gets a confident treatment recommendation based on outdated training data. An analyst generates a financial model with a number that looks plausible but cannot be reconciled to any source.

These stories are real. They are also, usually, told as if AI itself is the problem. The framing is binary. AI is dangerous. Hire a human instead.

That framing misses what's actually happening.

The failure mode common to all of these stories is not that AI is broken. It's that AI is being asked to do work it is structurally bad at. Specifically, language models are being asked to produce numerical claims, factual citations, and value derivations as part of their generative output. They produce these claims in the same way they produce any other text. By predicting what a plausible response would look like given the context.

That is a fine mechanism for writing readable narrative. It is a catastrophic mechanism for producing numbers that have to be defensible.

The reason is mechanical, not philosophical. Language models do not retrieve numbers from a verified source. They generate numbers as part of a probability distribution over likely tokens. When a model produces “12x ARR” or “1.84x DSCR” or “$8.4M trailing EBITDA,” it is not reading those values from a ledger. It is producing the values that statistically fit the surrounding text. Sometimes those values happen to be correct. Sometimes they are wrong by orders of magnitude. The user has no way to tell the difference from the output alone.

This is the central problem of what I will call plausibility without traceability. The output looks defensible. It reads like a human analyst wrote it. But there is no chain of evidence connecting the output to source data. There is no way to ask, of any specific number in the output, where did this come from? The number was generated, not retrieved.

In casual contexts, this is acceptable. If a language model summarizes an article with a slightly wrong publication date, no one is harmed. If a chatbot recommends a restaurant that has since closed, the cost is mild inconvenience. The applications that have made consumer AI genuinely useful operate in contexts where confidently wrong outputs are tolerable.

Audit-required work is not those contexts.

In M&A, lending, insurance underwriting, clinical decision support, pharmaceutical research, audit, and tax, every numerical claim eventually faces a third party. A regulator. A counterparty. A court. A board. An investment committee. A clinician reviewing a recommendation before acting. The work has to be defensible not just at the moment of production but indefinitely afterward, against questioning from people whose job is to find errors.

A system that produces plausible-but-untraceable claims fails this test by construction. It does not matter how often it is correct. It matters that it cannot be verified. The first time a hallucinated number reaches an output that a regulator reviews, the system is dead. Not because the model was bad. Because the architecture was wrong.

This is the part of the conversation that gets skipped. The advisors warning founders about AI hallucinations are correct that consumer chatbots are dangerous in M&A. They are wrong about why. The danger isn't AI itself. The danger is AI deployed without architectural constraints that prevent it from producing untraceable claims. Different architecture. Same models. Different outcome.

That different architecture exists. It has been used in regulated industries for years. It just hasn't been named clearly enough for the broader market to recognize.

How regulated industries already solve this

Banking has known how to deploy automated systems safely for decades. Every credit decision is auditable. Every model used in underwriting goes through formal model risk management. The Federal Reserve publishes guidance (SR 11-7) on how banks must validate and govern the models they deploy. Decisions made by automated systems are traceable through the system back to the source data and the rules applied. When a regulator audits a bank, the bank can show, for any specific decision, exactly how it was made.

Pharmaceutical research operates the same way. Every claim in a clinical trial submission to the FDA must trace to source data through documented analytical procedures. The principle is called data provenance. It is enforced not by hope but by structural requirements built into the analysis pipeline. You cannot publish a result if you cannot show the chain of evidence back to the raw observations.

Financial audit is provenance-constrained by design. The entire profession exists because someone has to verify that the numbers in financial statements trace to underlying transactions. Generally Accepted Auditing Standards require a documented audit trail for every material assertion. The auditor doesn't trust the company's word that a number is correct. The auditor traces it.

Clinical decision support follows the same pattern. FDA-approved decision support tools must be transparent about their reasoning. A clinician using such a tool can see why it produced a recommendation. The tool cannot recommend a course of treatment without showing the evidence base.

In every one of these industries, sophisticated practitioners converged on the same architectural principle. Numerical claims have to be traceable. Reasoning has to be documented. Outputs have to be defensible to a third party who will arrive later, look at the work, and ask how each conclusion was reached.

This is not new thinking. It is how serious work has been done for as long as serious work has existed.

What is new is that AI capabilities have arrived in industries that have not yet figured out how to integrate AI into this existing discipline. The teams building consumer AI products didn't have to think about provenance because their use cases didn't require it. Now those tools are being adopted by users in industries where the requirement is non-negotiable, and the friction is becoming visible.

The friction is not AI's fault. It is what happens when a tool built for one set of constraints meets a domain with different constraints. The fix is not to make AI better at producing untraceable claims. The fix is to deploy AI inside an architecture that already meets the domain's requirements.

That architecture has a name now.

Provenance-constrained generation, defined

Provenance-constrained generation is an architectural pattern for deploying AI in work that requires defensible output. It has three layers and a binding mechanism.

Layer one. AI at the edges.

AI is allowed to operate at the boundaries of the system, where its strengths are useful and its failure modes are containable. Specifically, AI handles the conversion of unstructured input into structured data, and the conversion of structured analysis back into readable narrative. Both are tasks that benefit from language models' fluency with messy human-generated content. Neither task requires the model to produce numerical claims, derive values, or make factual assertions that have to be verified.

The ingestion edge takes documents, images, audio, or other unstructured inputs and converts them into structured records. The narrative edge takes structured analytical results and converts them into human-readable output. Both edges are constrained. The ingestion edge does not interpret the data. The narrative edge cannot reference values that haven't been verified through the deterministic layer. AI is doing work it is genuinely good at, and only that work.

Layer two. Deterministic math in the middle.

Every calculation, every score, every value derivation runs through reproducible deterministic logic. Not language models. Not probabilistic estimation. Math that produces the same answer every time given the same inputs. This is the load-bearing layer of the system, and AI does not touch it.

The specific implementation of the deterministic layer is the work of a domain expert. In M&A, the calculations are the ones that matter for valuation, financing, and deal structure. In lending, they are the ones that matter for credit risk, collateral coverage, and repayment behavior. In insurance, they are the ones that matter for actuarial risk and policy terms. The architectural point is that this layer exists, that it is reproducible, and that everything it produces can be traced back to the inputs that fed it.

Layer three. Cryptographic provenance binding the layers.

Every value in the system carries provenance back to its source. Every operator action becomes part of the verified chain. The mechanism is implementation-specific, but the architectural commitment is uniform. Nothing in the final output exists outside the chain.

This is what separates provenance-constrained generation from other approaches that try to make AI safer. Retrieval-augmented generation cites sources but cannot prevent the model from misquoting them. Chain-of-thought prompting shows the model's reasoning but doesn't bind the conclusions to verified data. Fine-tuning can reduce hallucination rates but cannot eliminate them. All of these are mitigation techniques. None of them are architectural guarantees.

Provenance-constrained generation is an architectural guarantee. The narrative layer is structurally bounded by the provenance chain. It cannot reference values that haven't been verified through deterministic computation. The boundary is not enforced by hope or by human review. It is enforced by the architecture itself.

This is the move that solves the central problem from the previous section. The plausibility-without-traceability failure mode disappears because plausibility is no longer possible without traceability. Every number in the output has a verifiable path back to source. Every claim can be audited. Every output is defensible to a third party.

The model still hallucinates internally. Language models will continue to produce confidently wrong text in the parts of their operation where they are not constrained. That is a known property of how they work. But the hallucination cannot reach the user as an unverified numerical claim, because the architecture prevents it.

JCoBee as a worked example

JCoBee is one implementation of provenance-constrained generation, applied to mergers and acquisitions. It is not the only possible implementation, and it is not the only correct one. It is a worked example. The architectural pattern is what travels. The specific implementation is the domain work of building it.

The diagram below shows JCoBee's architecture at a glance.

The five components on the diagram correspond to the three architectural layers.

Document ingestion and AI structure extraction are the ingestion edge. Confidential information memoranda, bank statements, tax returns, trial balances, and other unstructured documents enter the system. The AI parser converts them into structured records. The parser does not interpret the data. It does not score it. It does not draw conclusions. It performs one task. Unstructured to structured.

The refinery core is the deterministic middle layer. The structured data from ingestion flows into the core, where JCoBee's algorithm scores each business along multiple dimensions calibrated to the failure modes that matter in M&A transactions. The specific dimensions, the calibration, and the scoring logic are the domain work of building JCoBee. The architectural point is that this layer is reproducible. The same inputs produce the same outputs every time. AI does not touch this layer.

The scenario stress-test sits alongside the core. An operator can adjust scenarios, stress assumptions, and explore sensitivities. Every operator action becomes part of the verified chain. The system records what was changed, by whom, and how it affected the downstream outputs. The audit trail captures human judgment as a first-class element of the system, rather than treating operator inputs as separate from or outside of the provenance.

AI narrative generation is the narrative edge. After the deterministic layer has produced a complete analysis, AI writes the readable memo. The narrative layer cannot reference any value that lacks verified provenance. If the analysis says revenue grew 18% year over year, that claim is bound to the specific source. If the analysis says EBITDA margin is 22.4%, that claim traces back through every transformation it underwent. The AI is doing what AI is good at, which is producing fluent, well-structured language. It is structurally prevented from doing what AI is bad at, which is producing untraceable claims.

The audit-traceable memo is the output. Every claim in the memo carries a hash. Every hash links back through the provenance chain to source data. A reader can verify any number in the memo by following the chain.

The lower band of the diagram traces the journey of a single value through the system. EBITDA extracted from the CIM. Add-backs normalized. SDE calculated. Operator-stressed scenario applied. Debt service computed. DSCR derived. Bound to the final memo claim. Each step is a verified node in the chain. A reader who wants to question the final DSCR claim can walk backward through the chain to see exactly how it was produced and which source documents fed it.

This is what the operating principle on the diagram refers to. Every number cited. Every citation hashed. Every hash traceable to source. That sentence is not marketing language. It is a description of what the architecture structurally guarantees.

The implementation work to build this is non-trivial. Calibrating the deterministic scoring to the actual failure modes of small-cap M&A transactions took twenty years of operator experience to inform. The provenance binding mechanism, the operator-input handling, the narrative-layer constraints — all of those are specific engineering choices that took real work. None of those choices are visible in the diagram, and they are not the point of this essay. The point is that the architecture exists, it has been built, and it works.

For a complementary view of how this architecture works at the outcome level in M&A, see AI in M&A: The Operating System for Modern Deal Intelligence.

Why this matters beyond M&A

The architectural pattern that JCoBee implements for M&A applies cleanly to a much wider set of industries.

Lending is the most obvious. Every credit decision is a numerical claim that has to be defensible. Every loan file faces eventual scrutiny, whether from internal audit, external regulators, the secondary market, or the borrower in a dispute. A lending implementation of provenance-constrained generation would put AI at the edges, parsing tax returns, bank statements, and supporting documents into structured records. It would put deterministic math in the middle, calculating debt service coverage, loan-to-value, debt-to-income, and the rest of the underwriting metrics. It would bind the layers with provenance so that every approved or declined application has a complete audit trail. The dimensions in the deterministic layer would be calibrated to the failure modes of lending, not M&A. The architecture would be the same.

Insurance underwriting follows the same pattern. AI at the edges parsing application data, claim histories, and supporting documentation. Deterministic math in the middle calculating actuarial risk, premium pricing, and coverage limits. Provenance binding so that every underwriting decision can be defended to a regulator, a reinsurer, or a court. Different dimensions calibrated to insurance failure modes. Same architecture.

Clinical decision support is more sensitive but the architecture still applies. AI at the edges parsing patient records, lab results, and imaging into structured form. Deterministic logic in the middle applying validated clinical algorithms. Provenance binding so that every recommendation can be traced back to the specific evidence and the specific guidelines that produced it. The dimensions are clinical rather than financial. The architecture is the same.

Pharmaceutical research, audit, tax preparation, regulatory compliance, environmental reporting, supply chain verification. The list is long. In every one of these domains, the same three-layer pattern applies. The implementation work is domain-specific. The architectural pattern is universal.

This is the reason the second industry approached me about applying the JCoBee methodology. The architecture transferred because the underlying problem is the same. AI strengths and weaknesses are constant. Audit-required domains share a common structural requirement. The pattern that solves the problem in one domain solves it in all of them.

I expect to see provenance-constrained generation systems built across most of the regulated economy over the next decade. Some of them will be built by teams that read this essay and recognize the pattern they had been groping toward without naming. Others will be built by teams that arrive at the architecture independently, the way I did, by building working systems and noticing what made them work. Either path is valid. The architecture is what matters, not who claims credit for naming it.

What I do think is worth saying clearly is that the conversation about AI in regulated industries should move past the binary framing. AI is neither inherently dangerous nor inherently transformative. It is a tool with specific strengths and specific failure modes, and the question for any serious deployment is whether the architecture is correct for the failure modes the domain cannot tolerate.

For audit-required work, provenance-constrained generation is the architecture.

What this means for builders, buyers, and operators

If you are building an AI system that has to produce defensible output, the implication is straightforward. AI does not get to operate in the load-bearing layer. The middle of your system has to be deterministic, reproducible, and audit-friendly. AI belongs at the edges, doing the work it is good at, structurally prevented from doing the work it is bad at. The provenance layer that binds them is not optional. It is the thing that makes the architecture work.

The criteria for evaluating an AI system in audit-required work are clear. Can every numerical claim in the output be traced back to source? Are the load-bearing calculations deterministic and reproducible? Is the AI structurally constrained from producing untraceable claims, or is it only mitigated through prompt engineering and human review? The first two are necessary. The third is what separates an architectural guarantee from a hopeful workaround.

If you are buying or specifying AI tools for use in regulated work, ask vendors these questions directly. Do not accept vague answers about model accuracy, fine-tuning, or guardrails. Ask whether the architecture structurally prevents the failure mode you cannot tolerate. If the answer is anything other than yes with a clear explanation of how, the architecture is wrong for your domain regardless of how good the demos look.

If you are an advisor or operator in a regulated industry, the implication is different. Your job is changing. The version of your role that warns clients away from AI is becoming obsolete. The version of your role that knows how to evaluate properly architected systems and guide clients toward the right ones is becoming dramatically more valuable. The advisors who learn this architecture first will be the most useful to their clients over the next decade. The advisors who continue to position AI as inherently dangerous will lose ground to peers who can articulate why some AI systems are safe to deploy and others are not.

This is the part of the conversation that should be happening in M&A, lending, insurance, healthcare, audit, and every other regulated domain right now. Not whether AI is dangerous. What architecture allows AI to be deployed safely, and what evaluation criteria distinguish properly architected systems from improperly architected ones.

Closing

Provenance-constrained generation is the architecture I think is correct for AI in audit-required work right now. AI at the edges. Deterministic math in the middle. Cryptographic provenance binding the whole.

I built one example of this architecture for M&A because that's the world I came from. The same architecture applies to lending, insurance, healthcare, audit, pharmaceutical research, and every other domain where numerical claims have to be defensible to a third party. The implementation work is domain-specific. The architectural pattern is universal.

The pattern will refine as AI capabilities evolve. Some of the work currently allocated to the deterministic layer may eventually be safe for AI to do as the technology improves. The narrative layer may become richer. The provenance mechanisms may become more standardized across the industry. But for the current state of language models, given what they're genuinely good at and where their failure modes are catastrophic, this is the architecture.

I am also not the only person building this way. Other teams are quietly arriving at similar architectures in their own industries. If you are evaluating tools for use in regulated work, the criteria above will help you distinguish the ones that have figured out the architecture from the ones that have not. The market is starting to reward correct architecture. The sooner buyers and operators can recognize what correct architecture looks like, the sooner the market will reward the teams building it.

Brad Detlor