DEV Community: DEVALAND

Why a Scan Is Not a Document

DEVALAND — Tue, 04 Aug 2026 03:31:52 +0000

In the previous piece I argued that a PDF keeps where the glyphs sit and throws away what they meant. A scan is a harder case, because a scan does not even have glyphs. It has pixels. Everything else is reconstructed by software that is guessing, and the guessing is much better than it used to be, which is exactly what makes it dangerous.

More than twenty years of setting scientific books taught me what a table actually is. It is not a picture of rows and columns. It is a grid of relationships: this number belongs to this row label and this column header, and it means nothing at all detached from either. Publishers rebuild tables by hand when they come in as images, and they do it because there is no honest shortcut.

That is the whole argument of this post. OCR converts pixels into characters. It does not convert a page back into a document.

OCR errors are not random, and that is the problem

If OCR failed noisily, this would be a solved problem. You would see garbage, you would know.

It does not fail that way. It fails toward plausibility. A 6 becomes an 8. A 1 becomes a 7. A 5 becomes an S. A comma becomes a full stop, which in a European financial document turns 1.234 into 1,234 or the reverse. The engine is choosing the most likely character given the shape, and the most likely character is almost always a real one.

In prose, this is survivable. You read a sentence with one wrong letter and your brain corrects it without stopping. That is why OCR feels so accurate: you are testing it on text where you are the error correction.

In a table of figures there is no such redundancy. Every digit is load-bearing. Nothing in the surrounding context tells you that a margin should be 6.2 rather than 8.2. The wrong number is exactly as readable as the right one, carries the same confidence, and looks equally like a fact.

Where scanned tables actually break

Four failure modes, and I have seen all four in real documents.

Column drift. A value lands one column to the left or right of where it belongs. Revenue for 2024 is now sitting under 2023. The total still adds up, because the same numbers are present, just attributed to the wrong period. Nothing looks wrong until someone builds a growth rate from it.

Tables that continue across pages. In a printed book this is handled by repeating the header and adding a continuation rule. OCR sees two separate blobs on two separate pages, and unless something explicitly stitches them, half the table silently disappears or becomes its own orphan table with no headers at all.

Merged and spanning cells. A header that spans three columns, or a row label that covers two rows, is a relationship expressed purely through geometry. Flatten it and the relationship is gone. The value that belonged to all three sub-columns now belongs to one of them, or to none.

Rule lines read as characters. A thin vertical rule becomes a 1 or a pipe. A horizontal rule becomes a row of dashes or underscores that the parser treats as content. This one is easy to spot when you look and impossible to spot when you do not.

The confidence score will not save you

Most OCR engines return a confidence value, and it is tempting to gate on it. Below some threshold, flag; above it, trust.

It does not work, for the same reason it does not work in retrieval. The confidence is per-character and it measures how sure the engine is about the shape it saw, not whether the resulting document makes sense. A crisp, clean, high-confidence 8 that was actually a 6 scores beautifully. A slightly smudged but correctly read digit scores worse. The score is orthogonal to the thing you care about.

I measured a version of this problem in a different context and published the result: retrieval similarity scores could not separate answerable questions from unanswerable ones, because the two populations overlapped. The lesson is the same here. Anything computed before you have the answer cannot tell you whether the answer is right. The check has to happen afterwards, against the source.

What to do instead

The habit is the same one that governs everything else I build. Treat the scan as evidence of a document, not as the document.

Keep the page image, always. If a figure is ever questioned, the answer is not a log line, it is the picture of the page it came from. This is the scanned-document version of a citation.

Rebuild tables as tables, and keep them that way through the entire pipeline. A table flattened into prose has lost the row-to-column relationship, which was the only reason the table existed.

Require every number to be findable in the source. Not paraphrased, not approximately present. Findable. If it cannot be located verbatim on the page it claims to come from, it does not get repeated.

Say the input was a scan. Put it in the output where the reader sees it, not in a log nobody opens. A brief built from clean born-digital PDFs and a brief built from a photocopied fax deserve different levels of trust, and the reader is entitled to know which one they are holding.

Never repair a number quietly. If something looks wrong, flag it and show the source. Correcting it invisibly means the next person inherits your guess as a fact.

Why this matters outside publishing

Publishers already know all of this. They budget for it, they employ people who rebuild tables by hand, and they treat a scanned manuscript as a cost rather than a convenience.

The people who get hurt are the ones who assume a PDF is a PDF. An acquirer reading management accounts that were scanned from a printout. A lender working from a photographed set of statements. Anyone whose most important number arrived as an image of a number.

The document you were sent and the document your software read are not always the same document. With a born-digital file, the gap is small. With a scan, it can be a decision made on a digit that was never there.

Cite the source or cut the claim. And when the source was a photograph of a page, say so out loud.

What 70 Scientific Books Taught Me About Why AI Misreads a PDF

DEVALAND — Tue, 04 Aug 2026 03:31:47 +0000

My name is printed in the front matter of more than seventy scientific volumes, and I have spent more than twenty years turning manuscripts into typeset pages. I now build AI systems that read documents for a living. Those two facts sound unrelated. They are the same problem seen from opposite ends, and the first one explains most of what goes wrong in the second.

Here is the short version. A document that has been typeset is not a bag of words. It is a structure, and almost all of that structure is thrown away the moment it becomes a PDF. When an AI reads that PDF, it is not reading the document. It is reading the shadow the document left on a page.

What a typesetter actually does

Setting a scientific book is not decoration. It is the act of encoding meaning into position.

A running head tells you which chapter you are in without reading a word. A float, a table or figure that moves to wherever it fits, carries a caption precisely because it has been separated from the paragraph that referred to it. Front matter is a defined sequence: half title, title, copyright, dedication, contents, preface. A displayed equation is numbered because something later will point back at it. A footnote sits at the bottom of a page and a citation sits in a bibliography, and those are different objects doing different jobs.

None of that is styling. Every one of those decisions is semantic. The compositor's craft is knowing that a two-line gap and a smaller point size mean this is an aside, not the argument, and that a reader will absorb that without ever being told.

In LaTeX, the source knows all of this explicitly. There is a \chapter, a \caption, a \label, a \cite. The structure is not implied by how it looks. The structure is written down, and the appearance is derived from it.

What the PDF keeps

The PDF keeps the appearance and discards the source.

A PDF is a set of instructions for placing glyphs at coordinates. Put this character at this x and y, in this font, at this size. That is essentially all it is. The fact that a particular run of glyphs was a chapter title, and another was a caption, and a third was a footnote, is not recorded anywhere. It is inferable by a human because humans read layout fluently. It is not stated.

So when a system ingests that PDF, it has to reconstruct, by guesswork, everything the compositor originally knew for certain. Is this larger text a heading or an emphasised sentence? Does this two-column page read left column then right, or across? Is this number a footnote marker or an exponent? Does this table have a header row, or is the first row just bold?

Every one of those guesses is a place where a document quietly becomes a different document.

The failures I see, and why they are structural

Three show up constantly, and none of them is a model problem.

Reading order. Two-column layouts are the classic. Extraction that follows the coordinate stream rather than the column flow will interleave the two columns line by line. The output is grammatical, fluent nonsense. Nothing errors. The text is all there. It is simply in an order that never existed.

Orphaned captions and floats. Because a float moves, a table can be printed pages away from the sentence that discusses it. Flatten that and the table arrives with no context, or worse, glued to whatever paragraph happened to be adjacent on the page. A figure that supports one claim gets silently attached to another.

Footnotes folded into the body. A footnote is a qualification, very often the exact qualification that limits the claim above it. Merge it into the running text and you get a sentence that asserts something the author deliberately hedged.

I want to be precise about the point. These are not hallucinations. The model is faithfully reporting what it was given. It was given a scrambled document.

Scans are a different problem again

Everything above assumes a born-digital PDF, where the glyphs are real characters. A scan is worse, because there are no characters at all, only pixels, and OCR has to invent the text before anything can read it.

OCR is very good now. It is not good at deciding that this block is a table and this one is a paragraph, and it has no idea that page 14 is a continuation of the table on page 13. In practice, tables are where scanned documents do the most damage, because a number lifted out of a misread table looks exactly as authoritative as a number lifted out of a correct one.

This is why "just OCR it" is not a plan. OCR converts pixels to characters. It does not convert a page back into a document.

What I do about it

The habit that came out of typesetting, and that I now build into software, is this: treat structure as evidence, and treat its absence as a fact worth recording.

Concretely, in the systems I build for reading commercial and financial documents:

Reconstruct reading order deliberately rather than trusting the coordinate stream. Column detection first, then flow.

Keep tables as tables through the whole pipeline. A table flattened into prose has lost the relationship between a row label and its value, and that relationship is usually the entire point of the table.

Carry the location with the content. Every extracted claim keeps the page it came from, so a reader can go and look. This is the same discipline as a citation in a bibliography, and it exists for the same reason.

Cut what cannot be traced. If a figure cannot be tied back to a specific place in a source document, it does not get repeated. It gets flagged. A missing number is an inconvenience. A confident wrong number is a decision made on fiction.

Say when the input was poor. If a document arrived as a low-quality scan, that belongs in the output, not buried in a log. The reader is entitled to know how much to trust what they are looking at.

The part that transfers

Typesetting taught me that most of what a document means is carried by how it is arranged, and that this arrangement is invisible until you try to reproduce it mechanically. More than twenty years of putting structure into pages turns out to be unusually good preparation for the problem of getting structure back out of them.

The people who feel this most sharply are not publishers. They are anyone who has to make a decision from a hundred-page document that arrived as a PDF: an acquirer reading a data room, a lender reading management accounts, an analyst reading a filing. The document they were sent and the document their software read are not always the same document, and nothing in the process tells them so.

That gap is the whole reason I build the way I do. Cite the source or cut the claim, and when the source itself was damaged in transit, say that out loud.

Intelligent Document Processing: A Practical Guide

DEVALAND — Mon, 03 Aug 2026 14:00:06 +0000

Intelligent document processing (IDP) is the practice of turning messy documents (PDFs, scans, emails, spreadsheets) into structured, validated data that flows into your systems without a human retyping it. In 2026 the useful version pairs classic OCR with language models for extraction and reasoning, then wraps both in validation and human review so the output is trustworthy. This guide covers the real pipeline, where LLMs earn their keep, where they hallucinate, and how to start small on one document type.

What IDP actually is now (beyond old OCR)

Old OCR answered one question: what characters are on this page. That was useful and still is, but it left you with a wall of text and a person to read it. IDP answers the harder question: what does this document mean, and which specific fields do I need out of it.

The shift is that extraction is no longer just pattern matching on fixed templates. A modern pipeline can read an invoice it has never seen before, a lab report in an unfamiliar layout, or a 120 page information memorandum, and pull the fields you asked for. That flexibility is what makes IDP worth doing. It is also what makes it dangerous if you skip validation, because a system that can read anything can also confidently invent things.

The real pipeline, stage by stage

A working IDP system is not one model. It is a short assembly line, and most of the reliability lives in the boring stages, not the clever one.

Ingest any format. Documents arrive as native PDFs, scanned images, photos from a phone, email attachments, Excel files, and the occasional Word doc. Stage one normalizes all of it and detects the document type so the right rules apply downstream.

OCR and layout. Scanned and image based pages go through OCR that preserves layout: tables, columns, headers, and where each value sits on the page. Position matters, because knowing that a number lived in the total row of a table is what lets you trust it later.

Extract structured fields. This is where a language model shines. You define the exact fields you want (invoice number, net amount, counterparty, effective date) and the model returns them as structured data, even across layouts it has never seen.

Validate. Every extracted value gets checked against rules: types, ranges, cross totals that must add up, dates that must be plausible, references that must exist. Anything that fails validation is flagged, not silently passed on.

Route into systems. Clean, validated records go where they belong: your accounting tool, your database, a CRM, a review queue. Low confidence or failed items go to a human instead of into your books.

Stage	Job	Main risk if skipped
Ingest	Normalize formats, detect type	Wrong rules applied to wrong doc
OCR and layout	Read text, keep structure	Values read out of context
Extract	Pull the fields you defined	Missing or malformed data
Validate	Catch impossible values	Silent errors reach systems
Route	Send clean data onward, flag the rest	No accountability, no audit trail

Where LLMs help, and where they hallucinate

Language models are very good at reading unfamiliar layouts, handling synonyms (net, subtotal, amount due), summarizing dense sections, and answering questions about a document. For extraction across varied formats, they remove months of brittle template work.

They are bad at three things that matter here. They fill gaps: when a field is missing, a model would rather guess a plausible value than say it is absent. They misattribute: they can pull the right number from the wrong row or the wrong entity. And they drift on arithmetic: totals and derived figures are not safe just because they look right.

The fix is not a better prompt. It is architecture. The rule I build to is simple: cite the source or cut the claim. Every extracted value should carry a pointer back to where it came from (page, table, coordinates), and anything the system cannot ground gets marked unknown rather than invented. That single discipline is the difference between a demo and something you can put near real money.

Why citation and human review are non-negotiable for regulated work

If you process financial statements, contracts, clinical or diagnostic documents, or anything a regulator or an auditor might question, you need to answer one question at any time: where did this number come from. A summary cannot answer that. A cited value can, because it points back to the exact line on the exact page.

Human in the loop is not a failure of automation, it is the design. The goal is to automate the 80 percent that is clean and route the ambiguous 20 percent to a person with the source shown next to the extracted value, so a review takes seconds instead of a full manual re-read. You get most of the speed and keep all of the accountability. This is exactly the muscle behind Deal OS, which ingests 100 page CIMs, runs OCR and extraction, and returns cited findings under a verify-not-summarize rule so a buyer can trust what they read.

Build versus off-the-shelf IDP tools

Off-the-shelf IDP platforms are a reasonable starting point when your documents are high volume and standard (think generic invoices or receipts) and you are happy to live inside their templates, their data model, and their per-page pricing.

A bespoke build wins when your documents are non-standard, when the fields you care about are specific to your business, when the data has to land inside systems you already run, or when confidentiality means you cannot ship sensitive files to a third party. Roll-ups, multi-entity groups, diagnostics companies, and M&A acquirers usually fall on the build side because their documents and their downstream systems are theirs alone.

A short, honest test: if a generic tool covers 90 percent of your case, buy it. If the last 10 percent is where all your risk and cost live, that 10 percent is the whole point, and it needs a build.

How to start: one document type, one scoped pilot

Do not try to process everything. Pick the single document type that costs you the most time or the most risk today: one invoice format, one contract type, one report. Define the exact fields you need out of it and what a validated record looks like. Then build the full pipeline for that one type, with citation and a review queue from day one.

That scoped pilot tells you the true accuracy on your real documents, your genuine exception rate, and the actual time saved, before you spend on a wide rollout. Once one type works end to end, adding the next is mostly configuration, not a new project.

This is how I work with founder-operators: a paid proof pilot from $2,500 over one to two weeks (credited to the full build), fixed-scope builds from $8,000 to $25,000, or fractional from $4,000 per month. Async intake, no calls.

If you run an ops-heavy business drowning in documents, see Custom AI & Python development for how these builds are scoped, read more on custom AI development for founders and AI automation for multi-entity founders, or look at AI Deal OS to see cited document intelligence in production. When you are ready, send the details through the async intake at /contact?service=ai-build and we can scope a pilot on your hardest document type.

A Driver's License Question Beat Every Real One: Why Retrieval Scores Cannot Gate a RAG System

DEVALAND — Thu, 30 Jul 2026 14:00:06 +0000

Most retrieval-augmented generation systems carry a comfortable assumption. If the retrieval score is high, the retrieved context is probably relevant and the answer is probably grounded. If the score is low, the system is out of its depth and should refuse. Set a threshold somewhere sensible, and you have a safety mechanism.

I built a small Romanian question-answering system, measured that assumption, and it did not survive contact with the data.

This piece is the measurement, the reason it breaks the standard design, and what I ended up gating on instead. The code is public and the result is reproducible in about a minute on a laptop: ro-cited-answers on GitHub.

What the system is

A question-answering demo over five documents on Romanian customs and EORI registration procedure, drawn from public information published by Poșta Română and the Romanian Customs Authority.

Everything runs locally. An open-weight 2B model on Ollama, an embedding model for retrieval, on a four-core VPS in the EU. No external API, no key, no data leaving the machine. The design rule is that an answer which cannot be traced to a source document is refused before anyone reads it.

I did not build it as a product. I built it because a parcel of mine was genuinely stuck in customs at BSI București, and the questions in the test suite are the ones a real person actually needed answered.

The measurement

The script scores seven legitimate questions and seven impostors against the corpus. Legitimate questions are about customs, EORI numbers, parcel returns. Impostors are about things the corpus knows nothing about.

If a retrieval score is a usable safety signal, the two populations should separate cleanly. Every real question should score above every impostor, and the gap between them is where you put the threshold.

They do not separate. They overlap.

	Question	Score
Lowest legitimate	"Cand am nevoie de cod EORI pentru un colet?"	0.697
Highest impostor	"Ce documente imi trebuie pentru un permis de conducere?"	0.773
Separation margin		-0.076

A question about driver's license paperwork scored higher against a Romanian customs corpus than every genuine customs question did.

The margin is negative. That is the whole finding. It is not that the threshold was badly tuned, or that a bit more calibration would fix it. When the populations overlap, there is no value you can pick that admits every real question and rejects every impostor. One threshold is too strict and loses real answers. Any looser one lets the driver's license question through.

Why this breaks the common design

A lot of RAG systems treat the retrieval score as the guardrail. Retrieve, check the similarity, and if it clears the bar, hand the context to the model and trust that grounding follows.

If the score cannot distinguish a question your corpus can answer from one it cannot, then that guardrail is decorative. It will fire on some things and feel like it is working, which is worse than not having it, because it produces confidence without producing safety.

Note what the impostor question does. It is in the same language, the same register, the same bureaucratic domain of official documents and required paperwork. Embeddings capture that similarity faithfully. They are doing their job. Asking a similarity score to also tell you whether a specific fact is present in a specific document is asking it a question it was never designed to answer.

So in this system the retrieval gate is deliberately not load-bearing. Its threshold is set from the measurement above, it catches the obviously unrelated case, and nothing important rests on it.

What to gate on instead: the answer, not the confidence

If you cannot trust a score computed before the answer exists, check the answer itself after it exists.

Four gates run in sequence, and an answer must clear all of them or it is refused, with the refusal logged.

Gate A, retrieval. The best-matching document must clear a similarity threshold. Deliberately weak, for the reason above.

Gate B, citation. Every source the model points at must resolve to a document that was actually retrieved. Catches invented citations.

Gate C, numbers. Every number in the answer must appear verbatim in a cited source. Numbers are where a hallucination does financial damage, and they are cheap to check exactly.

Gate D, grounding. Every substantive sentence must be attributable to one cited document, and the printed source list is rebuilt from the documents that actually carried a sentence.

Gate D is the load-bearing one, and the reason is worth stating plainly.

Gates that depend on the model cooperating with an instruction are brittle. You can tell a model to cite its sources in a particular format, and a large model will usually comply, and a 2B model frequently will not. Gate D does not ask the model for anything. It takes the answer as a finished artifact and checks it against the source text. It works the same whether the model cooperated, ignored the instruction, or never understood it.

That is the transferable idea here, and it is the same rule I run in production diligence work: cite the source or cut the claim. Check the output against the evidence, not the model against its instructions.

The same model, twice, minutes apart

Here is what the gates are actually for.

Ungrounded, asked what EORI means, the model answered that it is a "European Union Chamber of Commerce and Industry Number."

That is invented. EORI is not a chamber of commerce number. The answer is fluent, plausible, correctly shaped, and wrong, which is the exact failure mode that costs money in regulated work.

Grounded through the four gates, same weights, same machine, minutes later, it answered that EORI stands for Economic Operators Registration and Identification, that the number is assigned free of charge, and that the average processing time is 5 days with a maximum of 30. Then it printed the source document and the date that source was last checked.

Same model. Same hardware. The gates decided everything.

This is also why I am unconvinced by the framing that sovereign AI, by itself, gets you trustworthy AI. There is a serious argument in Europe about open weights, national compute, and models governed under national law, and it is worth winning. But sovereignty decides where the weights sit. It decides nothing about whether a particular answer is true. A model can be entirely sovereign and confidently wrong at the same time.

Three things that cost real time

A small model will not echo a string source id. Asked to cite a document by its identifier, the model answered the question correctly and signed it "SURSE: 1, 2." A gate demanding string ids threw away two correct answers. The fix was to number the fragments and map the number back to the real document in code, where it cannot be got wrong. If a gate can be enforced in code instead of in a prompt, enforce it in code.

Once citing is cheap, models pad their citations. With numbered fragments, the model answered a parcel-return question correctly from the right document, then also cited an unrelated one. The answer was trustworthy and the citation list was noise, which is precisely backwards for a system whose entire value proposition is traceability. Citations are no longer taken on the model's word. Each sentence is attributed to its best-matching cited document, the printed list is rebuilt from what actually carried a sentence, and padding is stripped and logged.

Morphology is not ungroundedness. Romanian inflects heavily. Exact word matching scored a verbatim quote at exactly 0.5000 against a 0.50 threshold, which passed only because the comparison was written as less-than rather than less-than-or-equal. That is not a safety margin, that is luck. Prefix matching on content words lifted the same quote to 0.83, while a genuinely ungrounded sentence still scored 0.00.

Every decision, accepted or refused, is appended to an audit log with the retrieval scores, the gate that fired, and the per-sentence attribution. A refusal you cannot reconstruct afterward is just a different kind of unverifiable output.

What this does not do

I would rather state the limits than have you find them.

It is slow. CPU-only inference on four shared cores runs at roughly 2 tokens per second. Fine for a demonstration, not fine for production traffic.

The grounding is lexical, not semantic. Gate D compares content words by a fixed-length prefix, so it forgives Romanian inflection but not synonymy. A correct paraphrase sharing little vocabulary with its source would be refused. The system fails toward refusing, which is the right direction, but it is a real limitation and not a subtle one.

The corpus is five documents. The overlap finding in particular should be re-measured on a larger corpus before anyone treats it as a general result. I am reporting what I measured, not a law of nature.

A refusal is not an answer. Refusing well is the point, but a system that refuses everything is also useless. Of the four test cases, two must be refused and two must be answered, precisely to hold both sides honest.

None of this is legal advice, and the corpus is a demonstration fixture.

The part worth taking away

If you are building anything that answers questions from documents and the stakes are higher than trivia, the question to ask about your own system is simple. When it refuses, what is it actually checking?

If the answer is a retrieval score, go measure whether your in-corpus and out-of-corpus questions actually separate. Score a handful of real questions and a handful of plausible impostors from an adjacent domain and look at the two populations. It takes an afternoon. You may find, as I did, that the number you have been trusting cannot tell the two apart.

Then move the check to where it can be enforced: the finished answer, against the source text, in code.

That is the same discipline behind the diligence work we do, where a figure in a hundred-page deal document either traces to something real or it gets flagged rather than repeated. If you want to see it applied to acquisition documents instead of customs procedure, there is a cited sample brief with every claim tied to its source, no login required.

The repository is MIT licensed and the measurement script is the first thing worth running: github.com/MariusGithub13/ro-cited-answers.

AI on the Data, Human on the Judgment: Where AI Belongs in Diligence

DEVALAND — Mon, 27 Jul 2026 14:00:05 +0000

There is a simple test for whether AI belongs in your diligence process: does it do the reading, or does it do the deciding? Get that line right and AI is the best analyst you have ever had. Get it wrong and it is a confident intern who never says "I am not sure."

The right division of labour is old, it just has new tools. AI on the data. Human on the judgment.

What "AI on the data" actually means

The data work in diligence is enormous and mechanical: read a hundred-page CIM, pull every figure, find the customer schedule, match the number in the narrative to the number in the appendix, flag where they disagree, and trace each claim to the page it came from. This is exactly what machines are good at and humans are slow at. Done well, it turns a week of reading into an afternoon of reviewing, and it does not get tired on page 80.

The key constraint is citation. AI earns its place on the data only if every figure it reports is tied to a source line, and anything it cannot trace is dropped or flagged rather than filled in. The moment a model is allowed to invent a missing number, it stops being an analyst and becomes a liability, because a plausible wrong number reads exactly like a right one.

What must stay human

Judgment is the part that does not automate. Is this customer concentration a dealbreaker or a discount? Is this owner genuinely replaceable? Does this earn-out protect me or just delay the problem? Do I trust this seller? These are decisions shaped by experience, risk appetite, and things that are not in the data room at all. AI can lay the evidence in front of you, cited and reconciled. It cannot decide what the evidence means for your deal, and it should not try.

The failure mode is treating an AI summary as a conclusion. A clean paragraph feels like an answer. It is not. It is a starting point that still has to be checked and judged.

Where the line pays off

Job	Owner	Why
Read the data room, extract figures	AI	Volume and speed, no fatigue
Reconcile narrative vs schedule vs contract	AI	Mechanical cross-checking
Trace every claim to its source line	AI	Verifiable, not trusted
Decide what changes the price	Human	Judgment, risk appetite
Decide whether to walk	Human	Experience and context

How Deal OS draws the line

Deal OS is built on exactly this split. It reads the data room and produces a brief where every claim traces to its source page, and any figure it cannot verify is discarded rather than guessed. It flags contradictions with both sides cited. What it deliberately does not do is tell you whether to buy. It hands you cited evidence and reconciled numbers so your judgment is spent on the decision, not on the reading. See it on a synthetic deal in the sample brief, or run one of your own CIMs through it for a one-time $99 with the CIM Pass, credited to your first month if you continue.

Frequently asked questions

Can I trust an AI summary of a CIM? Not as a conclusion. Use it as a map: require a source quote for every figure that matters, and treat anything unsourced as a question rather than a fact.

What should AI never do in diligence? It should never fill a gap with an estimate, and it should never make the buy-or-walk decision. Its job is to surface and cite evidence, not to judge.

Does AI replace a quality-of-earnings provider? No. It accelerates the reading and cross-checking, but the judgment calls on normalisation, risk and price stay human.

See what a cited, contradiction-flagging brief looks like on a sample deal at Deal OS.

The Verification Gap: Why Translated Summaries Misprice Cross-Border European Deals

DEVALAND — Thu, 23 Jul 2026 14:00:06 +0000

In a cross-border deal, the risk is not that a number was translated. It is that nobody checked the translation against the original. A German footnote becomes a clean English sentence, an Italian working-capital note becomes a tidy summary, and the version that ends up pricing the deal is the one furthest from the source. The gap between the original document and the summary is where seven-figure mistakes live, and it is exactly the gap a busy buyer is least able to police.

Most cross-border buyers solve the easy half of this problem and skip the hard half. They get the documents translated, read the summary, and feel informed. The value is in the second step almost nobody takes: verifying the handful of numbers the decision rests on against the original-language line they came from.

Language access is the easy part

It is tempting to treat multilingual diligence as a translation problem. Get the German CIM read in German, the French contracts read in French, and the job feels done. But translation is the beginning, not the end. Once a figure is in English it still needs verifying against its source, and that is the step, under time pressure, that quietly disappears. A footnote gets paraphrased into confident English. A working-capital adjustment gets summarised in a way that is technically reasonable and subtly wrong. The summary reads clean. The error is invisible because the reader never returns to the original line.

Why cross-border deals make it worse

This is sharper in Europe than almost anywhere, because the deals are genuinely multilingual in a way many markets are not. A buyer might look at a German manufacturer one month and a French services business the next, each arriving in its own language, with its own accounting conventions and its own footnote culture. And the people one step removed from the documents, the investors and the investment committee, sit even further from the source language than the buyer does. They see the cleanest, most summarised, most translated version of all. The further you sit from the original document, the more confident and the less checkable the number in front of you becomes.

Which numbers actually deserve a second look

You cannot re-read every line of every data room in three languages, and trying to is its own failure: it burns the exclusivity window on figures that do not matter. The discipline is narrower. Verify the handful of numbers your decision actually rests on against the original-language document.

Figure	Why it moves the deal	Check it against
Customer concentration	Sets the risk discount on the multiple	The customer schedule, in the source language
Working-capital peg	Moves the price at closing	The original financial notes, not the summary
Revenue recognition	Changes whether earnings are real	The accounting policy note in its own language
Change-of-control terms	Can un-do the deal after close	The actual assignment clause in the contract

For those, the quote should stay in its original language, so you or someone you trust can check it. If a number cannot be traced back to a specific line, it is not a number yet. It is a question.

A worked example

Consider a manufacturer in a German-speaking country. The English summary of the financials, prepared by an adviser, described a customer concentration that looked acceptable. The original German footnote, read carefully, said something narrower and more alarming: one large customer relationship was contractually softer than the headline implied. The summary was not dishonest. It was a reasonable paraphrase that lost the single qualifier that mattered. A buyer who priced the deal on the English version would have underwritten a concentration risk they never saw, and the investment committee would have approved it without ever seeing the footnote. The reconciliation is what surfaces it.

How Deal OS closes the gap

This is the discipline behind the cited-brief approach in Deal OS. It turns a data room, including documents in other languages, into a brief where every claim traces back to the exact source line it came from, with the original-language passage preserved next to the English so the number can be checked rather than trusted. Where a summary and a source disagree, it flags the contradiction with both sides cited, rather than smoothing it into a clean sentence. You can see it run on a synthetic deal in the sample brief.

Pair this with the management meeting cross-check and the M&A due diligence checklist: the checklist tells you what to verify, the management meeting is where the spoken version drifts, and the verification gap is where the translated version drifts. All three are the same discipline. Treat every summary as a claim until it traces to a source.

Frequently asked questions

What is the verification gap in due diligence? It is the step that gets skipped after a document is translated: checking the English summary against the original-language source. The translating is done; the verifying is not, because the summary is faster to read than the source.

How do I verify a translated financial summary? Identify the few figures your decision rests on, find the specific line in the original-language document that supports each one, and keep the quote in its original language so it can be checked. Numbers that cannot be traced become diligence requests.

Why is cross-border due diligence riskier than single-language diligence? Because every deal arrives in a different language with different accounting conventions, usually without a bilingual analyst to check the translation, and the investors and IC sit even further from the source than the buyer does.

What is source-language citation? It is the practice of tracing each figure back to the original-language passage it came from and preserving that passage, rather than relying only on the translated summary, so the number stays checkable.

See what a cited, contradiction-flagging brief looks like on a sample deal at Deal OS.

The three bugs my AI agent caught before a single customer saw them

DEVALAND — Mon, 20 Jul 2026 18:49:46 +0000

This is a smash story about bugs that never reached a customer, because the thing that wrote them also read them back to me.

I run a small e-commerce store. Its abandoned-cart recovery emails were quietly leaking revenue, so I rebuilt the flow. But I never opened the dashboard. I pointed an AI coding agent at the email platform's REST API and asked it to get the sequence production-ready. Reading the flow, editing the emails, inserting steps, all of it was API calls.

Then it read the generated emails back, and three bugs fell out. None dramatic. All the quiet kind that kill conversion or land you in legal trouble.

Bug 1: the button to nowhere.
The "Complete your order" button linked to a generic /cart page, not the customer's actual saved checkout. The trigger event carried the real checkout URL; the template ignored it. Every recovery email would have sent buyers to an empty cart. Fix: point the button at the event's real checkout URL, with /cart only as a fallback:

href="{{ event.abandonedCheckoutUrl | default: '/cart' }}"

Bug 2: one product shown to everyone.
The email hardcoded a single product, its name, price, and photo. Every abandoner would have seen that same item no matter what they actually left in their cart. That is worse than showing nothing: it is confidently wrong. Here is the human call in the loop: the agent surfaced it, I decided the fix. Generic-but-accurate beats specific-but-wrong, so I cut the hardcoded product rather than guess.

Bug 3: the silent compliance bug.
When the agent inserted the follow-up emails as raw HTML, the platform's branded footer, and with it the unsubscribe link, silently did not attach. An email with no unsubscribe is not just ugly, it is a GDPR and CAN-SPAM problem. Fix: re-send the emails as native blocks so the compliant footer attaches, then verify the unsubscribe actually renders.

The lesson.
I would have skimmed past all three in a nice-looking template. The difference was that the agent read every line back out loud. That is the real defense layer: not that AI writes the thing, but that it shows its work, so the expensive mistakes surface before a user ever hits them. Assume you will slip at 3am, and build the layer that catches it.

The flow is live now. It has not recovered a cart yet, and I am not going to pretend otherwise: the store is new and low-traffic, so nothing real has abandoned through it since cutover. The bugs are the story here, not the revenue. I wrote the whole thing up, rough edges and all, here: https://devaland.com/blog/sequenzy-review-agent-first-email

Disclosure: the email platform in this story is one I reviewed independently. I was given a free account; the write-up was not paid for or approved by them.

Best Due Diligence Software for Acquisitions (2026)

DEVALAND — Mon, 20 Jul 2026 14:00:13 +0000

If you search for "due diligence software," you get two very different kinds of product wearing the same label, and buying the wrong category is how teams end up paying for secure storage when what they actually needed was analysis.

This is a plain-English 2026 buyer's guide for acquirers: search funds, independent sponsors, boutique M&A advisors, and micro-PE teams. It explains the two categories, compares the main tools honestly (including where ours fits and where it doesn't), and gives you a way to choose for the size of deal you actually run.

Quick answer: Most "due diligence software" is a virtual data room (VDR), secure document hosting, permissions, and a Q&A tracker (Datasite, Ansarada, DealRoom, Intralinks). That solves storage and access, not review. A newer category, diligence-automation / document-intelligence tools like Deal OS, actually reads the documents in the room and produces source-cited findings. For a small-to-mid-market deal, the two are complementary: the VDR holds the data room, the automation tool helps you get through it.

The two categories, plainly

1. Virtual data rooms (VDRs)

A VDR is a secure, permissioned place to host the data room and run a buyer/seller Q&A process. Strengths: granular access control, audit trails, redaction, and a defensible record of who saw what. What they generally don't do is analyze the content, a VDR will store a 200-page CIM and forty contracts, but it won't tell you the EBITDA add-backs don't reconcile. Pricing is typically quote-based and scales with data volume and users; historically VDRs are priced for sell-side and larger transactions.

2. Diligence-automation / document-intelligence tools

These read the documents and produce analysis, source-cited summaries, financial extraction, risk and contradiction flags, missing-information checks. The point isn't to store the data room; it's to compress the reading and reconciling that eats most of a diligence timeline. This is the category Deal OS sits in. It does not replace your data room, your QoE provider, or your own verification, it gets you to the real questions faster.

The honest distinction: VDRs manage the documents; diligence-automation tools read them. Many teams use one of each.

At a glance

Tool	Category	Best for	Reads & analyzes docs?	Pricing model
Datasite	Virtual data room	Mid-to-large sell-side M&A	No (storage + Q&A)	Custom quote
Intralinks	Virtual data room	Large enterprise / banking	No (storage + Q&A)	Custom quote
Ansarada	VDR + deal workflow	Sell-side prep, checklists	Limited	Custom quote
DealRoom	VDR + project management	Buy-side process management	Limited	Subscription/quote
Generic AI chat (e.g. uploading PDFs to an LLM)	Ad-hoc document Q&A	Quick one-off questions	Partially, un-audited	Low/free
Deal OS	Diligence automation	Search funds, sponsors, micro-PE buy-side review	Yes, source-cited findings	Published SaaS tiers

Categories and capabilities are described in general terms; verify current features and pricing with each vendor, as products change.

Where each one fits

Datasite and Intralinks are the incumbents for larger, often sell-side transactions where the data room itself is the product and enterprise security and audit trails are the priority. They're robust and expensive, and usually more room than a sub-$10M deal needs.

Ansarada and DealRoom blend a data room with deal workflow, checklists, trackers, and project management, which is genuinely useful on the process side. They still center on managing documents and tasks rather than reading and reconciling the content for you.

Generic AI chat (uploading PDFs to a general LLM) is tempting and cheap, and fine for a quick one-off question. The problem for diligence is trust: answers aren't reliably cited back to the source page, nothing is structured for a data room, and there's no contradiction or missing-information audit. For a decision where a single missed clause changes the deal, "probably right, no citation" isn't good enough.

Deal OS is built for the buy-side review itself. You load a deal workspace, CIM, financials, contracts, tax returns, and the data-room PDFs, and it produces source-cited diligence briefs where every claim is quoted from your own documents and verified before you see it. It ties the same figure out across the CIM, the financials, and the tax return and flags every discrepancy, scrutinizes each EBITDA add-back for whether it survives a sale (a quality-of-earnings first pass), checks a management-call transcript against what the documents actually support, and drafts a buyer-ready investment-committee memo from the verified findings, with risk, contradiction, and missing-information audits across the whole room. It's aimed at the people doing the reading on small-to-mid-market deals, and it's priced on published SaaS tiers rather than a custom enterprise quote. You can try it on a deal that looks like yours in the interactive sandbox, no login, and see exactly what the output looks like.

AI diligence software vs the alternatives

Before you compare tools, compare approaches. On a small-to-mid-market deal a buyer usually weighs five ways to get through the documents, and the honest trade-offs look like this:

Approach	Typical cost	Speed through a data room	What you actually get	Best when
Read everything yourself	Your own hours	Days to weeks per deal	Deep familiarity, but one tired reader, the highest miss rate, and nothing cited for later	You run one or two deals a year and have the time
Hire or borrow an analyst	A salaried hire you usually can't justify before close, or a contractor re-briefed each deal	Faster, bounded by their availability	A second reader, but context resets every engagement and quality varies	You have steady deal flow and budget for headcount
Upload PDFs to a generic AI chat	Low or free	Minutes	Quick answers, but un-cited and un-audited, easy to hallucinate a clause that changes the deal	A throwaway question, never a decision
Commission a formal QoE	Several thousand to tens of thousands per engagement	A week or more	A signed, defensible earnings opinion your lender relies on	At LOI, on a deal you are serious about
Diligence-automation software	A published monthly SaaS tier	Minutes to hours	Source-cited findings, a contradiction map, a tie-out across the CIM, financials and tax return, and a discarded-claims log, every figure traced to its page	You are the buyer and the reading is the bottleneck

Costs are industry-typical ranges, not quotes; they vary by deal size, market, and provider.

These are not mutually exclusive. The pattern most small-to-mid-market buyers settle on is automation software to compress the reading and reach a defensible number, then a formal quality-of-earnings engagement on the deals that clear that bar. The automation is the first pass that makes the paid engagement faster and cheaper, not a replacement for it.

How to choose

A few honest questions cut through it:

Do you need to host a data room, or get through one? If you're running a sell-side process and need permissions and audit trails, you need a VDR. If you're the buyer drowning in documents, you need diligence automation. Many deals want both.
What's the deal size? Enterprise VDRs are priced for larger transactions. For a search fund or micro-PE deal, an enterprise quote is often more room, and more cost, than the deal warrants.
How much of your time is reading? If diligence is mostly reconciling financials and reading contracts against a checklist, that's the part automation compresses. If it's mostly process coordination, a workflow-oriented VDR may matter more.
Can you trust the output? For analysis tools, insist on source citations back to the document. Un-cited AI output can't be defended to an investor or a lender.

What software can't do

No tool closes the deal for you. Software can store the room, read the documents, and surface the questions, but the judgment, the seller conversations, the legal review, and the quality-of-earnings work still belong to you and your advisors. The right software just means you spend your scarce hours on judgment instead of on grinding through PDFs. Pair any tool with a real due diligence checklist so you know what you're verifying, not just where it's stored.

Frequently asked questions

What is the best due diligence software for a small acquisition?
For a search fund, independent sponsor, or micro-PE deal, the better question is which category you need. If you must host and permission a data room, a virtual data room (Datasite, Ansarada, DealRoom) is the tool. If you're the buyer trying to get through the documents, a diligence-automation tool like Deal OS that reads and cites the financials and contracts will save more of your time. Many teams use one of each.

Is a virtual data room the same as due diligence software?
Not quite. A virtual data room (VDR) securely stores the documents and runs the Q&A process, it manages access, not analysis. "Due diligence automation" tools instead read the documents and produce source-cited findings, contradiction checks, and missing-information audits. VDRs manage the data room; automation tools help you get through it.

Can AI do due diligence?
AI can do the document-heavy parts, reading, summarizing, extracting financials, and flagging contradictions across a data room, and produce source-cited findings so you reach the real questions faster. It does not replace your judgment, seller conversations, legal review, or a quality-of-earnings analysis. Treat it as leverage on the reading, not a substitute for verification.

How much does due diligence software cost?
Virtual data rooms are usually quoted custom and scale with data volume and users, which can be expensive for a small deal. Diligence-automation tools like Deal OS are typically priced on published SaaS tiers, so a single buyer can run a deal without an enterprise contract. Always confirm current pricing directly with each vendor.

Should I use due diligence software or hire an analyst?
Before you own a business you usually can't justify a full-time analyst, and a contractor needs the same context re-explained every deal. Diligence-automation software gives you a tireless second reader that cites every figure to its source, for a published monthly price instead of a salary. The honest split is software for the repeatable document reading, and a human (you, your advisors, a QoE provider) for the judgment.

Does AI due diligence software replace a quality of earnings report?
No. It does a QoE first pass: it ties EBITDA out across the CIM, the financials, and the tax return, flags discrepancies, and scrutinizes each add-back for whether it survives a sale, so you reach a defensible number before you commission a formal engagement. The signed QoE opinion your lender and reps-and-warranties rely on still comes from your provider, who now starts from an organized, already-flagged position instead of a cold data room.

Is AI due diligence software worth it?
For a buyer whose main bottleneck is reading, yes: it compresses the slowest phase of a deal from an analyst-week into minutes, and every finding is cited so you can defend it to an investor or lender. The return is not only time saved, it is the missed clause or unreconciled add-back it catches before you wire money. For a pure sell-side hosting need, a virtual data room is the better spend.

See what the output looks like

The fastest way to judge a diligence tool is to look at what it produces. See a real source-cited diligence brief, try it on a deal that looks like yours with no login, or see an example of how Deal OS turns a workspace of documents into cited findings, then decide which category your next deal actually needs. Not weighing a tool yet? Grab the free Deal Kit, 20 cited Claude diligence agents you can run on your own deals today.

Fix: WebP og:images silently break Medium imports and social previews

DEVALAND — Sat, 18 Jul 2026 06:27:40 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

My site (devaland.com) is a static blog built with React and vite-react-ssg, around 70 articles. Every article has a hero image, served as WebP/AVIF for performance. Those articles are also imported into Medium and shared on LinkedIn and X.

Bug Fix or Performance Improvement

A silent bug: WebP/AVIF hero images and og:image tags do not import into Medium's "Import a story" and do not render link previews on LinkedIn or X. The page looks perfect, but importing an article pulled no hero image, and shared links showed no preview. Nothing errors; the image just vanishes.

There is a sneaky second half: even after fixing the og:image, Medium still dropped the hero, because Medium imports the image from the article body <img>, which was also WebP. Two layers, one root cause.

Repro: point a page's hero <img> and og:image at a .webp, then run the URL through Medium's importer or the LinkedIn Post Inspector. No image. Swap to .jpg, it appears.

Code

The repo is private, so here are the exact changes as code snippets.

1) A prebuild step that auto-generates a .jpg twin of every local hero, skip-if-exists:

// scripts/gen-og-jpg.mjs (runs in `prebuild`)
import { blogPosts } from "../src/data/mock.mjs";
import { execFileSync } from "node:child_process";
import fs from "node:fs"; import path from "node:path";
const isLocalRaster = i => i && !/^https?:/i.test(i) && /\.(webp|avif)$/i.test(i);
for (const rel of [...new Set(blogPosts.map(p => p.image).filter(isLocalRaster))]) {
  const src = path.join("public", rel), jpg = src.replace(/\.(webp|avif)$/i, ".jpg");
  if (fs.existsSync(jpg) || !fs.existsSync(src)) continue;
  execFileSync("ffmpeg", ["-y", "-loglevel", "error", "-i", src, "-q:v", "3", jpg]);
}

2) Point both the og:image and the visible body hero <img> at the JPG twin:

ogImage={post.image?.replace(/^(\/.+)\.(webp|avif)$/i, '$1.jpg')}
src={post.image?.replace(/^(\/.+)\.(webp|avif)$/i, '$1.jpg')}

My Improvements

The trick is to keep WebP for the live page (performance) but serve a JPG wherever a scraper or importer looks. The prebuild script runs on every build, so new articles are covered automatically with zero manual work, and the generated JPGs are committed so the deploy does not depend on the CI having ffmpeg. 37 heroes converted. Result: the hero now imports into Medium automatically and every link preview renders, while browsers still get WebP on the page. The boring, permanent kind of fix that clears the bug off the stage for good.

Sequenzy Review: I Rebuilt My Cart-Recovery Emails Through the API

DEVALAND — Sat, 18 Jul 2026 05:31:30 +0000

Disclosure: The Sequenzy links in this article are affiliate links, and I earn a commission if you sign up through them. I only write about tools I have actually run, and nothing here is softened for the affiliate. Where a thing was clunky, I say so.

Most reviews of an email tool are written by someone clicking through the dashboard. This one is different, because I barely touched the dashboard. I rebuilt a real abandoned-checkout recovery flow for one of my stores almost entirely through Sequenzy's REST API, driven by an AI coding agent. That turned out to be the most interesting thing about the tool, and the most honest way to judge where it actually stands against Klaviyo.

Sequenzy is an indie, agent-first email platform. I run a small gold-jewelry store, and its cart-recovery emails were the thing standing between me and real revenue that leaked every day. This is not a thought experiment: the flow is live on the store right now, and its emails deliver and get opened. To be precise, because precision is the whole point of this piece: it has not recovered a cart yet. The store is new and low-traffic, so no real abandonment has run through it since cutover. What follows is a build-and-verification story, not a revenue-results story. Here is exactly what happened, warts included.

The setup: an email flow built by an agent, not a human

I did not open the sequence builder and drag blocks around. I pointed an AI coding agent at Sequenzy's REST API and asked it to read the account, find the abandoned-checkout sequence, and get it production-ready. Everything below, reading the flow, editing the emails, inserting steps, fixing links, was done through API calls, not clicks.

What the agent caught before a single customer saw it

The auto-generated recovery email looked fine at a glance. It was not. Three real problems, in order of how much they would have cost me:

The button opened an empty cart. The link pointed at a generic /cart page, not the customer's actual saved checkout. The trigger event carries the real checkout URL, but the generated email ignored it.
The product was hardcoded. The email named one specific product, price, and photo, baked in. Every abandoner would have seen that same item regardless of what they carted.
The follow-up emails had no unsubscribe. Inserted as raw HTML, they came through with no footer and no unsubscribe link, which is a compliance problem, not just an ugly one.

None were dramatic. All three quietly kill a flow's conversion or land you in trouble. Working through the API, with an agent that reads back what it changed, surfaced them immediately.

The rough edges, said plainly

The generated flow shipped paused, and it was not obvious it needed activating.
Raw HTML inserts silently dropped the compliance footer.
The API returned a 403 to a non-browser user agent, which can trip up scripted and agent traffic.

To the platform's credit, I flagged these to the founder and got same-day fixes on more than one. That responsiveness matters more than a perfect first run.

Sequenzy vs Klaviyo, without the marketing

I use Klaviyo for other stores, so this is a fair comparison. For a human building e-commerce flows in a UI, Klaviyo is still easier today. It ships a prebuilt abandoned-checkout flow with a native dynamic cart block, and Sequenzy does not match that yet. If you want the full picture on when a store outgrows Shopify Email and whether Klaviyo is worth its price, I wrote that up in Klaviyo vs Shopify Email.

But that is not the game Sequenzy is playing. Its edge is that I built and fixed this entire flow from an API and an agent, start to finish, which Klaviyo cannot do. If you build with agents, Sequenzy is less friction, not more. The gap it needs to close is prebuilt e-commerce templates with dynamic carts, so nobody hand-builds the recovery email.

The real lesson

Building through an agent changed what I noticed. A broken cart link, a lie about which product someone carted, a missing unsubscribe: these are exactly the things a human skims past in a nice-looking template and an agent reads out loud. That is the same reason we build the way we do at Devaland: systems where the machine shows its work, so the expensive mistakes surface before a customer ever hits them.

If you build with agents, Sequenzy is worth a serious look today, with clear eyes about where it is still behind. If you build by clicking, give it a few months on the e-commerce templates. Either way, an email flow you can hand to an agent and have it catch your mistakes is a genuinely new thing, and it is here.

Claude's Private Equity Plugin vs a Turnkey Diligence Tool (2026)

DEVALAND — Thu, 16 Jul 2026 14:00:05 +0000

In 2026, Anthropic released a suite of agent templates for financial services, including private-equity and due-diligence workflows. If you buy companies for a living, it is worth understanding what actually shipped, because the headlines make it sound like a finished diligence product, and it is not quite that.

This is an honest comparison, written by someone who builds diligence tooling on the same models. I will be specific about what Anthropic released, who it fits, and where a turnkey, source-cited tool serves a searcher or small sponsor better. Full disclosure: we make one (Deal OS). I will keep the comparison fair, because pretending otherwise helps no one.

Quick answer: Anthropic's private-equity and diligence offerings are agent templates that run as plugins inside Claude Cowork or Claude Code, or as Managed Agents on the API. They are powerful reference architectures you customize and connect to your own data tools. They are not a hosted product you log into. If you are a fund with a data stack and technical capacity, that flexibility is an advantage. If you are a self-funded searcher or a small independent sponsor, a turnkey tool that returns a source-cited brief the moment you upload a CIM will usually fit better.

What Anthropic actually released

Per Anthropic's own announcement (May 2026), the company shipped ten ready-to-run agent templates for financial services. The key facts:

Each template is a reference architecture that packages three things: skills (instructions and domain knowledge), connectors (governed access to data), and subagents. Firms adapt them to their own modeling conventions, risk policies, and approval flows.
They run in two forms: as a plugin inside Claude Cowork or Claude Code (alongside the analyst's desktop apps), or as a cookbook for a Claude Managed Agent that runs autonomously on the platform (public beta).
The deal-relevant templates include a pitch builder, a model builder, and a valuation reviewer; Anthropic's plugin marketplace also lists a Private Equity plugin covering deal screening, diligence over document sets, and IC-memo support.
They connect to enterprise data through connectors: SS&C Intralinks (data-room search and diligence Q&A), PitchBook, FactSet, S&P Capital IQ, plus a Moody's MCP app, all under governed access.
They are optimized for Claude Opus 4.7 and available on paid Claude plans.

That framing is the one that matters most. These are reference architectures you adapt and connect, not an out-of-the-box application. Anthropic is showing what its platform can do and giving teams a serious head start, which is genuinely valuable. It is just a different thing from a product you log into.

Who the templates are built for

Read the connector list again: FactSet, S&P Capital IQ, PitchBook, Moody's. Those are expensive, enterprise data subscriptions used by established funds. Deploying a Managed Agent via the API, or customizing a plugin and wiring it to your data room, assumes someone on the team can do that work and maintain it.

So the natural fit is a fund or advisor that already owns the data stack and has the technical capacity (or budget) to build on top of it. For that profile, the templates are a strong accelerant.

The real distinction: a kit versus an appliance

The honest way to frame the choice is not "Anthropic versus a startup." Both run on the same underlying models. The difference is what layer you are buying.

A template or plugin is a kit. You bring the model plan, the connectors, the data-tool accounts, the setup, and the maintenance. In return you get maximum flexibility.

A turnkey tool is an appliance. You sign up, upload a CIM, and read a result. The vendor handles hosting, the workspace, the data room, billing, security, the citation discipline, exports, and support. In return you give up some flexibility.

Neither is "better." They serve different buyers.

Side by side

	Claude's PE / diligence templates	A turnkey cited diligence tool
What it is	Agent templates and plugins (Cowork, Code, or Managed Agent)	A hosted application you log into
Setup	Install, customize, connect your own data tools	Sign up, upload a document
Who runs and maintains it	You (or your engineers)	The vendor hosts and runs it
Data sources	FactSet, PitchBook, S&P Capital IQ, your drives	The documents you upload
Citations	However you choose to build them	Every claim quoted from the source and verified; unverifiable claims discarded
Time to first brief	A setup project	Minutes
Best fit	Funds with a data stack and technical capacity	Searchers, independent sponsors, small advisors

What a searcher or small sponsor actually needs

Most people buying a single small business are not a fund. A self-funded searcher, a two-person independent sponsor, or a boutique advisor usually has no FactSet seat, no PitchBook subscription, and no engineer to deploy and babysit an agent. They have a data room full of PDFs and a clock running on exclusivity.

For that buyer, the job is narrow and concrete: turn the CIM and the financials into a defensible, cited brief, fast, so the real hours go to judgment instead of page-turning. A kit they have to assemble is friction. A tool that works the moment they upload is the point.

The part that actually differentiates, once both run on Claude

When the underlying model is the same, raw capability stops being the differentiator. Two things decide whether the output is safe to act on:

The discipline. Does every claim carry a verbatim quote tied to its exact source page, and is anything that cannot be verified discarded before you see it? A confident summary that smooths over a number is worse than no summary. This is the standard that separates useful automation from the kind that quietly hurts you, and we wrote about it in detail in what due diligence automation actually catches.
The product layer. Hosting, an isolated and encrypted workspace, an audit trail of what was checked, exports your IC can read, and someone to email when you are stuck. None of that is the model. All of it decides whether you can rely on the thing on a live deal.

How to decide

You are a fund with a data stack (FactSet, PitchBook) and engineers, and you want to build a custom pipeline: the templates are a strong starting point.
You are a searcher, independent sponsor, or small advisor who wants a cited brief on a CIM without a setup project: a turnkey, source-cited tool fits better.
You want to compare turnkey tools specifically: see our honest best due diligence software breakdown.

Frequently asked questions

Is Claude's private equity plugin a finished product?
No. It is a reference architecture, a template of skills, connectors, and subagents you enable as a plugin in Claude Cowork or Claude Code, or deploy as a Managed Agent. Firms adapt it to their own conventions and connect it to their own data tools. It is powerful, but it is a kit you assemble, not a hosted application you log into.

Do I need FactSet or PitchBook to use it?
The templates are built to connect to enterprise data platforms such as FactSet, S&P Capital IQ, PitchBook, and Intralinks data rooms, and you get the most from them if you already hold those subscriptions. Many self-funded searchers and small sponsors do not, which is part of why a turnkey tool that works on your own uploaded documents can fit better.

Can I just paste a CIM into Claude instead?
You can, and for a quick read it helps. The risk is verification: a general chat summarizes confidently whether or not the summary is accurate. Without a discipline that ties every claim to its source page and discards what it cannot verify, you have to re-read the document anyway. The verification layer, not the summary, is what makes the output safe to act on.

What is the difference between a plugin and a turnkey diligence tool?
A plugin is a kit: you bring the model plan, the connectors, the setup, and the maintenance, in exchange for flexibility. A turnkey tool is an appliance: you sign up, upload a document, and read a result, while the vendor handles hosting, the workspace, citations, security, and support.

Which is right for a self-funded searcher or independent sponsor?
Usually the turnkey tool. If you do not have an enterprise data stack or an engineer to deploy and maintain an agent, a hosted tool that returns a source-cited brief minutes after you upload a CIM matches how you actually work.

The bottom line

Anthropic moving into PE and diligence is good news for everyone who buys companies. It validates that this work is worth automating, and because tools like Deal OS run on the same models, the platform getting better makes the appliance better too. The question is not which company is smarter. It is whether you want to build the kit or use the appliance, and which one matches how you actually work.

If you want to see what "every claim tied to its source" looks like in practice, here is a cited sample diligence brief on a synthetic deal, every figure quoted from the document and verified, no login and no call. Then you can judge the output for yourself and decide which approach your next deal needs.

AI CIM Analysis Tools Compared (2026)

DEVALAND — Mon, 13 Jul 2026 15:38:09 +0000

Reading a Confidential Information Memorandum is the first real work of any acquisition, and it is exactly the kind of dense, repetitive reading AI is supposed to help with. The catch: a CIM is a sales document. A tool that simply summarizes it well can make the pitch more convincing rather than more true. This is a buyer's comparison of the main options in 2026, judged on one question: does it help you trust the numbers, or just restate them?

The one test that matters

A summary is not diligence. The value for a buyer is verification: every figure traced to the page it came from, contradictions between the CIM and the financials surfaced, and claims that cannot be supported set aside rather than repeated with confidence. Judge every tool below on whether it moves you toward evidence or just toward a tidier version of the seller's story.

At a glance

Tool type	What it does well	Where it breaks for a buyer
General AI assistant (ChatGPT, Claude, Gemini)	Fast summary and Q&A on a pasted CIM	No page-level citations by default; will assert claims it cannot support; no data-room structure; confidentiality is on you
VDR with an AI add-on (Datasite, Ansarada, Intralinks)	Hosting, sharing, and sell-side workflow	Built to host documents, typically priced per page or per project; the AI leans toward summarizing rather than verifying; heavy for a sub-$10M deal
Prompt packs and DIY agent kits	Cheap, flexible starting point	You assemble and maintain the quality; depends on your own prompts; no running product and no audit trail
Purpose-built diligence software (Deal OS)	A cited brief: every claim traced to a source page, unverifiable claims discarded, contradictions surfaced	A newer category; not a VDR replacement for a large sell-side process

None of these is best in the abstract. A large sell-side process wants a VDR. A tinkerer wants a prompt pack. A buyer who has to stand behind a number in front of an investment committee or a lender wants each claim traced to the page it came from. Match the tool to the job.

What "cite or cut" looks like in practice

The behavior that actually protects a buyer is unglamorous: for every claim, find the exact page and quote that supports it, and if the support is not there, do not soften it, discard it and turn it into a question. A general assistant will happily produce a plausible average contract value or a clean "no material litigation" sourced from nothing. That is not a model bug; it is what a summarizer does when nothing forces it to cite. You can see the discipline running on a synthetic deal, no login, in the sample brief.

Frequently asked questions

Can ChatGPT or Claude analyze a CIM? Yes, for a summary and first-pass questions. The gap for a buyer is verification: a general assistant will not, by default, cite the exact page each figure came from or flag where the CIM contradicts the financials. That page-level tie-out is the part that protects you. See how to use Claude for due diligence.

Is a VDR the same as CIM analysis software? No. A virtual data room (Datasite, Ansarada, Intralinks) stores and shares documents, mostly for the sell side. Analysis is a separate job. Some data rooms add AI summaries, but hosting and analysis are different tools optimized for different sides of the table.

What is the cheapest way to analyze a CIM with AI? A prompt pack is cheapest to start. The trade is that you build and maintain the quality yourself and get no audit trail. A running product costs more but standardizes the work and records what was checked and what was set aside.

What should a small buyer use for a sub-$10M deal? Something priced for a single buyer rather than a per-page sell-side data room. The relevant comparison is on the best due diligence software for search funds.

See the cite-or-cut discipline running on a real-looking deal at Deal OS.