Your customers are training someone's moat.

The moat that quietly expired

For two funding cycles, the defensibility slide in every document AI deck said the same thing: proprietary model, fine-tuned on domain data, benchmarked a few points above the general-purpose alternative. It was a believable moat while it lasted, because reproducing it required training data, training budget and training time that a new entrant did not have. Then 2026 removed all three legs at once. Frontier inference prices reset to a fraction of their 2024 levels, which made the economics of "just call the big model" beat the economics of hosting a tuned small one for most extraction workloads. Open-weight models closed the quality gap on domain tasks — not on every benchmark, but on the ones that decide invoice fields, claim lines and bank-statement tables, which are the benchmarks a buyer actually runs. And the tuning itself commoditised: what took a research team a year in 2024 is a well-documented weekend in 2026.

The uncomfortable arithmetic is that any advantage expressible as "our model scores higher today" now has a shelf life of roughly 90 days — one provider release cycle, one open-weight drop, one competitor's evaluation sprint. That does not mean models stopped mattering; it means the model stopped being the asset. The asset is whatever your system accumulates that a competitor cannot replicate by swapping in this quarter's best model. And in document AI there is exactly one thing that fits that description: the record of every time a customer told your system it was wrong, and what your system did about it.

What a correction actually is

Watch what happens in any document operation in production. An operator fixes a vendor name the extractor misread. A reviewer reverts an approval the decision engine got wrong. A supervisor reclassifies an exception the router sent to the wrong queue. Most platforms treat these moments as workflow: the fix is applied, the document moves on, the event lands in an operational log that rotates out in 30 days. That treatment is the single most expensive habit in the category, because each of those moments is a labelled training example, produced by a domain expert, on the exact distribution of documents that matters — the customer's own — at marginal cost zero. No annotation vendor sells data like that. No fine-tuning corpus contains it. It exists only in production, only at the vendor who is there, and only if someone built the plumbing to keep it.

A correction is a domain expert labelling your hardest production case for free. The vendor who logs it as workflow noise and the vendor who feeds it back into the system are running the same software for about 90 days. After that, they are running different companies.

The flywheel is what turns that observation into architecture: a pipeline where corrections flow from the operator's click back into the system's behaviour — automatically, governed, and measurably. Done properly, each correction updates something specific. A misread field retrains the validator that should have flagged it. A reverted decision adjusts the confidence threshold that routed it to auto-approval. A repeated exception pattern refines the extraction prompt or expands the schema so the pattern stops being an exception. The customer experiences this as a system that stops making the same mistake — correct it once, and it stays corrected. The vendor experiences it as a learning curve whose slope is proportional to production volume, which is the part that makes it a moat: the more a customer uses you, the harder you are to replace, not because of contractual lock-in but because the replacement starts from zero on a curve you have been climbing for a year.

The anatomy of a flywheel that compounds

Most vendors claim some version of "our system learns from feedback." The claim is cheap; the architecture is not. A flywheel that actually compounds has five components, and the difference between marketing and moat is whether each one exists as running infrastructure or as a slide.

Two details in that table deserve emphasis, because they separate the vendors who built a flywheel from the vendors who built a feedback form. The first is that corrections route to different fixes — a wrong field and a wrong decision are different signals and improve different parts of the system; a pipeline that funnels everything into "more training data" wastes most of what it captures. The second is that auto-resolution rate is the only honest KPI for the loop. Accuracy measures the model; auto-resolution measures the system — extraction, validation, routing and decision together, on the customer's own documents. It is the number that converts directly into the operator hours the customer is paying to eliminate, which is why it belongs on the QBR slide and, increasingly, in the pricing model itself.

The compounding math, and why 6 months becomes forever

The numbers reported by operations with a mature flywheel cluster in a consistent band: human review falling 40–60% within 12 months of go-live, on a base model that did not change. Read that carefully, because it inverts the assumption most buyers still carry. The improvement did not come from a better model; it came from the system learning the customer's vendors, formats, edge cases and policies — the long tail that no general-purpose model ships with and no fine-tune anticipates. The flywheel converts the customer's own exception history into configuration, and exception history is the one dataset where the incumbent vendor has a monopoly.

That monopoly is what makes the gap permanent rather than temporary. Suppose a competitor enters the same account 6 months after you, with a model that benchmarks two points better. On day one, their system makes the mistakes yours made 6 months ago — the ones your flywheel already retired. To catch up, they need the same volume of corrections you consumed, from the same operators, who now have to fund two learning curves with their attention. Rational operators will not: every document routed to the new system is a document the proven system would have auto-resolved. The incumbent's curve steepens while the entrant's starves. This is the dynamic the consolidation wave is pricing when it pays premiums for vertical platforms: not the revenue, the learning curve attached to the revenue. A model can be bought. Six months of a customer's corrections, governed and compounding, cannot.

Four ways the flywheel breaks

Like most architectures that look obvious in a diagram, the flywheel fails quietly and in predictable places. Four failure modes account for most of the vendors whose "learning system" has not learned anything a customer can detect:

• Corrections discarded as operational exhaust — the fix is applied to the document but never captured as signal: it lives in an audit log designed for compliance, not learning, with no field identity, no document class, no link between what the system said and what the human did. The company is sitting on the most valuable dataset in its category and rotating it out every 30 days.
• No "correct once, corrected forever" mechanism — the operator fixes the same vendor name on every invoice from the same supplier, week after week. Nothing in the product lets that correction generalise. This is the failure customers feel most directly, and it quietly poisons the loop: operators who learn that corrections do not stick stop making them carefully, and the signal quality collapses along with the trust.
• Offline training disconnected from the production signal — the ML team retrains quarterly on a curated corpus while production corrections accumulate in a different system, owned by a different team, in a format the training pipeline cannot read. The flywheel exists organisationally in two halves that never touch. The tell: model updates that move benchmark scores but not the auto-resolution rate.
• No governance separating personal from systemic correction — an operator's one-off override (this invoice, this time, because of a phone call) is fed to the same pipeline as a genuine systematic fix, and the system learns a policy nobody set. Without a boundary between "I am correcting this document" and "I am correcting the system", the loop amplifies noise with the same machinery built to amplify signal — and a flywheel that learns the wrong things compounds those too.

The trade-off, stated honestly

The flywheel has a cost side, and it is contractual before it is technical. A customer who pays for extracted output has not, by default, granted the vendor the right to learn from their corrections — and a correction is customer data in a fairly strong sense: it encodes the customer's suppliers, policies, exception patterns and judgment calls. A vendor that quietly feeds one tenant's corrections into improvements every tenant receives is making a data-rights decision its contract may not support and its regulated customers would not sign. The honest version costs something: an explicit clause defining what correction signal is used, at what scope — per-tenant learning only, or pooled improvement with PII stripped and patterns generalised — with audit evidence to back the answer, and a real opt-out that does not gut the product. Some customers will choose isolation over improvement speed, and the vendor's curve flattens accordingly. That is the legitimate price of doing it properly.

There is a buyer-side trade-off too. The flywheel deepens exactly the dependency a procurement team is paid to resist: the longer the system learns you, the higher the switching cost — not as a contractual penalty but as a regression in operational performance that a migration cannot carry across. The answer is not to avoid vendors who learn; it is to contract for the asset the learning creates. Correction history, per-field confidence configuration and learned validation rules should be exportable in a documented format, named in the same continuity clauses we argued belong in every partner evaluation. A vendor who claims the flywheel as their moat and refuses to discuss who owns its fuel is asking you to fund an asset you can never take with you. The defensible position — for both sides — is co-ownership of the curve: the vendor keeps the machinery, the customer keeps the right to their own corrections and what was learned from them.

The question that replaces "which model do you use"

RFPs in this category still open with the model question — which provider, which version, fine-tuned or not. In 2026 it is close to the least informative question on the list: whatever the answer, it describes a 90-day advantage purchasable by every competitor at the same API endpoint. The question that actually discriminates is the one about the curve: how long does your system take to learn my domain, and how will I see it happening? A vendor with a real flywheel answers in specifics — here is the correction telemetry you can inspect, here is the auto-resolution rate by document class and how it moved across our last five customers' first year, here is what happens within days when your operator corrects the same field twice, here is the clause that says what we learn from you and who owns it. A vendor without one answers with the model's name, a benchmark table and the word "continuously" — and that difference, not the benchmark, is the evaluation.

For founders, the same question is the strategy test. Capital spent making a horizontal feature slightly more accurate is funding a depreciating asset with a 90-day half-life; capital spent on correction telemetry, governed ingest and per-tenant learning is funding the only asset in the category that appreciates with usage. The investors have noticed — it is why the funding that still flows is concentrating in vertical platforms whose learning loops run deep in one domain, and why "how fast does your system learn a customer" has joined unit economics on the diligence list. The vendors who differentiate on which model they call are competing in a market where the answer is a commodity. The vendors who differentiate on how fast their system learns are competing in a market where the answer takes years to copy — because the only way to copy it is to live in production, at volume, with the plumbing already built, for as long as the incumbent already has.

Closing thought

Every technology category eventually relearns the same lesson: the component commoditises, the loop does not. Databases commoditised; the data did not. Models are commoditising on schedule; the corrections are not, because corrections are not a technology — they are a relationship between a system and the experts who use it, accumulated one fix at a time, impossible to backfill. The moat question in document AI has accordingly moved up a layer, from "what do you run" to "what do you keep". A proprietary model is something you have until the next release cycle. A production flywheel is something you become — and the becoming is the part no acquisition budget, model license or benchmark sprint can compress.

At Cogneris this thesis is load-bearing, so here is our own position in it. Corrections in our platform are first-class signal, not log lines: every operator fix is captured per field with the full context of what the system believed and why, feeds per-tenant learning through a governed pipeline, and shows up where you can see it — in an auto-resolution rate reported by document class, with the audit trail carried through every run. Correct a field once and the validator, thresholds and schema absorb it; your team should never fix the same mistake twice. And we put the data-rights answer in the contract rather than the sales call: your corrections are your data, what we learn from them stays in your tenant, and both export in a documented format if you leave. If you are evaluating document AI vendors and want to ask the learning-curve questions properly — including of us — talk to our team: bring a sample of your exception queue, and we will show you what the first 90 days of the curve looks like on your own documents.