The Null Report: A Nine-Dimension Analysis With Zero Facts, and the Extraction Failure Behind It

Hook

I want to begin with a document that should not exist.

It landed in my inbox on a Tuesday: a nine-dimension analytical report, roughly four thousand words, covering technical architecture, token economics, market structure, ecosystem position, regulatory posture, team and governance, a six-category risk matrix, narrative and expectation gap, and supply-chain transmission. It had a table of contents. It had confidence annotations. It had a glossary, a disclaimer, and a status line at the bottom printed in red.

Every cell of substance read the same thing: N/A — insufficient information.

Not unknown. Not unverified. Insufficient information. The phrase repeated across sixty table cells, nine section conclusions, six risk categories, and four value ratings that all resolved to zero stars. The document's final line stated, plainly, that the analysis could not be completed because the input data was empty.

The system that produced it had done something genuinely remarkable. It generated a complete analytical scaffold — the entire vocabulary of rigor, the full ceremonial apparatus of a research desk — and populated it with nothing. Then it graded itself zero stars, listed its own data gap as a high-priority risk, and appended a request for the minimum input set needed to run again.

Here is the part that matters, and the reason I am writing this instead of deleting it.

The report was correct. Not in any of its claims — it made none — but in its behavior. Every other pipeline I have audited in the last eighteen months would have fabricated the missing content and shipped a confident, unhedged, entirely plausible document. This one refused. It failed loudly, in a language a human could read, and it told the truth about what it did not know.

That is not the failure. That is the only part of the system that worked.

The failure happened upstream, in extraction, and it happened silently. The shape of that silence is one I have seen before — in a different layer of the stack, with a different name, and with consequences measured in liquidations rather than wasted tokens.

I spent six months in 2020 writing a Python harness that submitted malicious state roots to the original Optimism testnet, hunting for a case where the seven-day challenge window could be gamed by a reentrancy pattern the fraud proof did not model. I found one, and I published twenty pages on it. What I took away from that exercise was not about rollups. It was that a verification system that cannot distinguish "the claim is true" from "no claim was submitted" is not a verification system. It is a formality with a settlement period attached.

That is what we are looking at here. Stage one returned nothing. Stage two treated nothing as a valid input, ran anyway, and produced a document. The only reason the document is honest is that the analysis template happened to require a confidence field, and the model filling it had no choice but to write zero.

Strip that field out of the schema and you get the same document with the same zero-fact content, minus the confession. Ship that to a fund. Watch what happens.

Context: The Two-Stage Contract Nobody Signed

To understand how a report can contain four thousand words and zero information points, you have to understand the pipeline architecture, because the bug is architectural, not statistical.

Almost every crypto research pipeline in production today — the ones inside funds, the ones inside exchanges, the ones feeding Telegram channels with forty thousand subscribers — is built on the same two-stage split.

Stage one is extraction. It fetches a document: a blog post, a governance forum thread, a whitepaper PDF, a GitHub README, a block explorer page. It strips navigation chrome and cookie banners. It chunks the remaining text. It runs an extraction pass that converts prose into atomic information points — typed tuples of the form subject, predicate, object, source span, confidence. Output: a list.

Stage two is analysis. It receives that list and runs it against a fixed taxonomy of analytical dimensions. Nine dimensions, in this case. Each dimension has a template with slots: a technical comparison table, a supply distribution table, a risk matrix, a set of conclusion fields. The model fills the slots from the list. Output: a report.

The contract between the stages is implicit and almost never written down. Stage two assumes stage one returned a non-empty list of facts. Stage one has no obligation to signal when it returned an empty one.

This is the same class of assumption as an internal call inside a smart contract. You invoke a function, you get a return value, you use it. You do not check whether the function actually ran, because you wrote it, and you know it works.

Except when it does not. Except when the address you called has no code at it. Except when the call succeeds and returns zero bytes, and your require(success) passes because success is true, and you decode an empty buffer into a uint256 and get zero, and you set the price of your lending market to zero.

I have written about this before and I will write about it again, because it is the single most reproducible bug class in this industry: consuming a return value without validating its content. It does not matter whether the return value is an ABI-encoded integer, an HTTP response body, or a list of extracted facts. The failure mode is identical. The call succeeds. The data is empty. The consumer does not check. The system proceeds on a foundation of nothing.

In Solidity the fix is three lines. In a research pipeline it is roughly the same number of lines. Almost nobody writes them, because the failure is invisible until it is not.

Why the failure is invisible

The invisibility comes from an asymmetry that any systems designer should recognize immediately.

When extraction fails partially — say, it pulls sixty percent of a document and drops the rest — the downstream report is degraded but not obviously wrong. It reads fine. It has claims. They are simply incomplete. Nobody catches it, because catching it requires independently reconstructing the source, which is the work the pipeline was supposed to do.

When extraction fails totally, the pipeline has two options. Option A: emit an empty report and alarm. Option B: emit a full report and let the model's language prior fill the vacuum.

Option B produces a better-looking artifact. It scores better on every surface-level quality metric. It passes every review that does not independently verify the underlying facts. It has more words, more tables, more headers, more conclusions. If your quality dashboard measures length, section coverage, or schema conformance, Option B wins on all three.

The pipeline chooses Option B. Not because anyone decided to. Because nobody built the branch that would make it choose Option A, and because every automated metric in the system rewards the wrong answer.

Who reads these reports, and what the readers are paid for

This matters because the incentive structure determines whether the bug ever gets fixed.

There are three consumers of automated crypto research, and none of them is paying for accuracy.

The first is the fund analyst under time pressure. Their job is coverage. They are expected to have an opinion on forty projects by the end of the quarter, and they physically cannot read forty whitepapers. They need a summary. They will take the summary that exists over the summary that is correct-but-absent. A null report is a hole in their coverage; a hallucinated report is a filled slot. From the analyst's perspective, the hallucinated report is strictly more useful, which is a sentence I dislike writing and cannot refute.

The second is the content operation. Newsletters, aggregation accounts, research-as-marketing arms of exchanges and L2 ecosystems. Their KPI is volume and engagement. A null report generates no engagement. A confident report generates engagement whether or not it is true, and the correction, if it ever comes, generates engagement a second time.

The third is the model itself. Reports are training data. A null report contributes nothing to the next training run; a confident fabricated report contributes a fabricated fact that will be reproduced by every model trained on it, forever.

All three consumers reward population over correctness. The null report is the only artifact in the system that produces no value for any of them, which is precisely why it is the only one that is honest.

I will come back to this. It is the core of my contrarian argument, and it is the reason I do not think the fix is as simple as adding a validator.

Core: Tracing the Failure Back to the Extraction Layer

Let me be concrete about where the data died, because "the input was empty" is a symptom, not a diagnosis, and I have no patience for symptom-level reporting.

The anatomy of the null payload

The stage-one output object, reconstructed from what the report itself implies, looked like this:

{
  "title": null,
  "source": null,
  "article_type": null,
  "domain_tags": [],
  "information_points": [],
  "entities": [],
  "time_sensitivity": null,
  "source_quality": null
}

Every field is either null or an empty array. The schema is satisfied. Null is a legal value for every key. An empty array is a legal value for every list. There is no constraint anywhere in the schema that says at least one information point must exist. There is no required flag with a minimum-length validator. There is no if len(information_points) == 0: raise.

This is the crux, and it is worth stating precisely: the payload was not malformed. It was well-formed and empty. Those are different things, and virtually every validation layer in production today checks the first and ignores the second.

JSON Schema will happily validate an empty array against a definition of type array with an items schema. Pydantic will happily construct the model. TypeScript will happily type-check it. Every tool in the modern data stack treats an empty collection as a valid collection, because it is. The type is correct. The semantics are dead.

I have spent a lot of time in the EVM's ABI decoder, and this is the exact same distinction. abi.decode does not know what a uint256 means. It knows how many bytes it needs. Hand it a well-formed buffer containing the integer zero and it returns zero with no complaint, because zero is a perfectly valid uint256. The decoder is correct. The protocol that used the zero as a price is wrong.

Type systems validate shape. They do not validate meaning. Every engineer knows this abstractly. Almost no engineer builds the check.

Where the text actually died

Stage one returned empty. Why? There are five ways a crypto research pipeline loses an entire document, and I have hit four of them personally.

The first is client-side rendering. The source was a page whose content is assembled by JavaScript after load. The fetcher issued a plain HTTP GET, received a shell containing a root div, a bundle reference, and a footer, and passed that shell to the extractor. The extractor found no sentences worth extracting. It returned an empty list, correctly. Nobody told it to render the page.

The second is anti-bot gating. Cloudflare, PerimeterX, a challenge interstitial. The fetcher received a 403 or a verification page, logged it at INFO level, and continued. The extractor received the interstitial's text — typically forty words about proving you are human — and returned an empty list, or worse, extracted the forty words as facts. If the pipeline had a minimum-facts threshold, it would have caught this. Most do not.

The third is document-format mismatch. A PDF whose text layer was never embedded — scanned, or exported from a design tool as vector outlines. The parser returns zero characters. A DOCX inside a ZIP behind a redirect. A spreadsheet where the extractor expected prose. All of these produce a clean, non-throwing, empty string.

The fourth is boilerplate stripping run too aggressively. This one is my favorite, because it is the only failure caused by the system working as designed. A deduplication and chrome-removal pass tuned on news sites sees a governance forum thread where the same header repeats on every reply, decides the header is navigation, and — through a similarity threshold set slightly too low — decides the entire thread is navigation. It strips everything. Empty list. No error. The pipeline reports success.

The fifth is truncation upstream of extraction. A token-budget guard applied to input for cost reasons, cutting the document at eight thousand tokens when the meaningful content sits at token twelve thousand. The guard did its job. The extractor saw eight thousand tokens of preamble, introductions, and legal disclaimers. It extracted nothing of substance.

Five different root causes. One identical downstream symptom: an empty list, a 200 OK, and a pipeline that moves on.

The schema trap

Now the interesting part. Given an empty list, why did stage two produce a full report rather than an error?

Because stage two is a language model with a template, and templates exert gravitational pull.

I built a Groth16 prover in Rust from scratch in 2022 — forty failed attempts before I got a proof under one hundred milliseconds. The lesson from that exercise was not about elliptic curves. It was about what happens when you give a system a fixed structure and an incomplete input. The structure wins. The prover does not care whether your witness is meaningful. It will produce a proof for whatever witness you hand it, and the proof will verify.

A model given a nine-dimension template and an empty fact list will fill the template. It has no other option. Every slot is a generation target. The prompt says produce a technical analysis. The input contains nothing. The model has been trained on hundreds of thousands of technical analyses, all of which had content. So it produces the distributional average of a technical analysis: correct structure, plausible register, hedged claims.

When the schema includes an explicit field for confidence or data availability, the model fills that field honestly — which is why this particular report is riddled with insufficient-information annotations. When the schema omits such a field, there is nothing to be honest in, and the output becomes indistinguishable from real analysis.

This is not a model defect. It is a specification defect. The template was designed for the case where the input exists, and it has no representation for the case where it does not. In a well-designed system, the empty case is not a degenerate instance of the normal case — it is a different state with a different output. In this system, it was silently coerced into the normal case.

Tracing the gas cost anomaly back to the EVM

I want to push this analogy as far as it goes, because I think it is load-bearing rather than decorative.

Consider the classic Solidity pattern, still shipping in production in 2026:

(bool success, ) = oracle.staticcall(
    abi.encodeWithSelector(AGGREGATOR.latestRoundData.selector)
);
require(success, "oracle unavailable");
// returndata discarded entirely

Two things are wrong here.

First, staticcall to an address with no code returns success equal to true and zero bytes of returndata. This is specified behavior, not a bug. An externally owned account has no code. The EVM does not revert on a call to an empty account; it returns success. So require(success) passes against an address that will never answer, and the protocol treats silence as a price.

Second, the returndata is discarded. Even if the call returned a well-formed tuple, the consumer never reads it. The success flag is the entire information channel, and the success flag says only that the call completed, not that it said anything.

Now compare the research pipeline. Stage two calls stage one. Stage one returns success — a 200, a valid JSON object, a well-formed schema. Stage two checks success. Stage two does not check content. Stage two proceeds.

Same bug. Different layer. Same three-line fix.

The fix in Solidity is to check the returndata length and validate the decoded values:

(bool success, bytes memory data) = oracle.staticcall(payload);
require(success && data.length == 160, "oracle: no data");
(uint80 roundId, int256 answer, , uint256 updatedAt, uint80 answeredInRound)
    = abi.decode(data, (uint80, int256, uint256, uint256, uint80));
require(updatedAt > 0 && answeredInRound >= roundId, "oracle: stale");
require(answer > 0, "oracle: non-positive");

The fix in the pipeline is the same check, expressed in a different language:

def run_stage_two(extraction):
    if not extraction.information_points:
        raise InsufficientInput(
            upstream="stage_one",
            missing=["information_points"],
            upstream_status=extraction.status,
            exit_code=2,
        )

Nobody wrote it. That is the entire story.

The oracle parallel, and why latency is the wrong variable

There is a specific version of this failure that has cost real money, and it is worth naming because it is the same shape and the industry keeps getting it wrong.

Everyone in DeFi talks about oracle latency. Latency is the wrong variable. A feed that is thirty seconds stale and correctly marked as stale is safe. A feed that is thirty seconds stale and consumed without checking the update timestamp is a liquidation engine pointed at a historical price. The integration guidance has said this for years: read the update timestamp, read the answered-in round, check the min and max answer bounds, check the decimals. Protocols that read only the answer have been exploited repeatedly, and the exploits are not sophisticated. They are the mechanical consequence of consuming a return value without validating it.

The lesson is not that oracles are bad. The lesson is that a data source's contract is defined by its failure modes, not its success modes. An oracle that always returns a number is more dangerous than an oracle that reverts, because the reverting oracle cannot be consumed incorrectly. The returning oracle can.

Apply that to research pipelines. A stage one that raises on empty input is strictly safer than a stage one that returns an empty list. The empty list is a loaded weapon. The exception is a safety feature.

The cost model

Let me put numbers on the null report, because the industry does not take a failure seriously until someone prices it.

The document was roughly four thousand words, or about fifty-five hundred tokens. Generating it consumed, at a rough estimate, six thousand output tokens and perhaps twelve hundred input tokens of template scaffolding. At current frontier pricing, that is somewhere between fifteen and twenty-five cents. Call it twenty cents.

Twenty cents is nothing. That is the point. The failure is economically invisible at the unit level, which is precisely why it never gets fixed. A pipeline that produces a useless document for twenty cents and a useful document for twenty-five cents has a twenty-five percent cost difference between correct and incorrect behavior. Nobody routes engineering time to a twenty-five percent cost delta on a component that is not in the critical path.

Now scale it. A research desk running two hundred pipeline executions a day, of which — and I am being conservative, based on what I have seen across three audits — eight percent hit extraction failure, produces sixteen null or degraded reports daily. Over a year, that is five thousand eight hundred and forty documents. If even five percent of those reach a human decision-maker who does not independently verify, you have nearly three hundred decisions made on documents whose factual content is either absent or fabricated.

The gas metaphor writes itself. The pipeline is paying for block space and filling it with NOPs. The transaction is included. The state does not change. And unlike a failed transaction, which reverts and refunds, this one consumes the budget and returns a receipt that looks like a success.

I once spent four consecutive nights in 2017 tracing a transferFrom path through a DEX's core library to find a twelve percent gas reduction using unchecked arithmetic. The pull request was merged, and the cumulative savings over the first year were substantial. I mention it because it established a habit I have never broken: every claim about efficiency has to be traceable to an opcode. The null report is the opposite artifact. It is a document whose entire cost is execution overhead, with zero state change at the end. There is no opcode to trace because nothing executed. There is only gas burned.

Inscriptions taught us something adjacent to this in 2023: block space has a market value independent of execution. You can fill a block with bytes that do nothing and someone will pay for it, because the bytes themselves are the product. A null research report is the same artifact. It occupies the attention budget. It carries no execution. And it was paid for.

The nine dimensions, measured

The report itself gives us the measurement. Nine analytical dimensions, sixty distinct data cells across the dimension templates, zero populated.

| Dimension | Template cells | Populated | Density | |---|---|---|---| | Technical architecture | 12 | 0 | 0.00 | | Token economics | 9 | 0 | 0.00 | | Market structure | 5 | 0 | 0.00 | | Ecosystem position | 4 | 0 | 0.00 | | Regulatory compliance | 6 | 0 | 0.00 | | Team and governance | 6 | 0 | 0.00 | | Risk matrix | 6 | 0 | 0.00 | | Narrative and expectations | 5 | 0 | 0.00 | | Supply-chain transmission | 7 | 0 | 0.00 | | Total | 60 | 0 | 0.00 |

Information density: zero. Not low. Zero. Every conclusion field in the document reads some variant of insufficient information, cannot assess. The four value ratings at the end — technical value, investment value, timeliness value, reference value — all resolve to zero stars, and the document is careful to note that zero stars means no information to evaluate, not negative value.

I have read a lot of research in this industry. This is the only document I have ever seen that scored itself honestly.

The retry loop that hides the failure

There is a mitigation most teams already have that makes this worse, and it is worth calling out because it is universally considered a best practice.

The retry loop. When extraction returns empty, retry with a different fetch strategy. Different user agent, headless renderer, archive mirror, cache lookup. Three attempts, then proceed.

This is correct engineering for transient failures and catastrophic engineering for permanent ones. A 403 from a bot gate is transient in the sense that a different fetch path might succeed. A PDF with no text layer is permanent — retrying it four times returns four empty strings and burns four times the budget, and the final attempt still returns empty, and the pipeline still proceeds.

Worse, the retry loop destroys the signal. A single empty extraction is a notable event. Four consecutive empty extractions across three fetch strategies is a definitive statement about the source, and the pipeline should treat it as such. Instead it treats the sequence as noise and continues, and the logging makes the final state indistinguishable from a slow success.

I have seen this pattern before in block production: a node that retries a failing transaction four times and then includes it in the next block anyway, because the retry loop's exit condition is time, not success. The transaction reverts on-chain. The block is produced. The metrics show a successful block.

What the correct output looks like

Since I am complaining, I should specify the alternative. A pipeline that cannot analyze should emit this and stop:

{
  "status": "INSUFFICIENT_INPUT",
  "stage": "extraction",
  "missing": ["information_points"],
  "upstream_http_status": 200,
  "fetched_bytes": 41200,
  "post_strip_characters": 0,
  "extraction_attempts": 4,
  "strategies_tried": ["direct", "render", "archive"],
  "exit_code": 2
}

Eighty bytes. Machine-readable. Non-zero exit code. A log line, not a document.

The four thousand words of scaffold are not neutral padding. They are an active liability, because the document will be skimmed, and the skimmer will see a table of contents, nine section headers, and a risk matrix, and will infer structure and therefore substance. The scaffold is the attack surface. The status object has none.

Threat Model: What the Null Payload Enables

Any security review of this pipeline has to enumerate what an attacker does with it, because the null payload is not merely a waste of compute. It is an exploitable primitive, and I want to be precise about the four vectors.

Vector one: the suppression attack. If you control a source that a research pipeline ingests — a project's own documentation site, a governance forum, a publishing account — you can force extraction failure on your own material and on competing material. Serve content only to renderers with a specific user agent; serve an empty shell to everyone else. The pipeline returns null for your project. The pipeline also returns null for the project you want buried, if you control the shared CDN. Nulls are indistinguishable from each other, which means you can suppress a competitor at the cost of suppressing yourself, and in a market where absence of coverage reads as neutrality, that trade is frequently positive for you.

Vector two: the poisoning attack. When extraction fails, the model fills the gap from its language prior. That prior was trained on the corpus. Control the corpus — through search optimization, through a coordinated set of analytical posts about the same entity — and you control what the prior fills in. The model does not hallucinate randomly. It hallucinates toward the distribution. A pipeline with an unguarded empty-input path will confidently repeat whatever the internet most frequently says about an entity, and the internet's frequency distribution is purchasable for less than the cost of a single audit.

Vector three: downstream propagation. Null reports do not terminate at the reader. They get aggregated into meta-reports, which get summarized into newsletters, which get scraped into the next training set. A null assertion — insufficient data to assess — is semantically inert and propagates safely. A fabricated assertion generated to fill the same slot is semantically active and propagates permanently. Once a hallucinated fact enters the corpus, it is not removable. It will be re-extracted as an information point by the next pipeline that ingests the newsletter, and it will acquire a source span, and it will look verified. The verification is circular and self-reinforcing, and the only thing it verifies is that someone wrote it down.

Vector four: the false-negative economy. In a bull market, absence of negative research reads as endorsement. A null report on a project is functionally a clean bill of health to anyone who skims the header and not the body. The document says insufficient information sixty times and zero times says this is a problem. A reader under time pressure encodes it as no red flags found.

That last vector is the real threat, and it is not technical. It is a reader-side vulnerability that the pipeline manufactures, and it is worse in an up market than a down one, because in a down market nobody is looking for reasons to buy.

Contrarian: The Null Report Is the Best Artifact in the Pipeline

Here is where I part company with the obvious reading.

The easy take is that the null report is a failure — a waste of compute, a sign of a broken pipeline, an embarrassment to be deleted and forgotten. Fix the extraction, tighten the schema, move on.

I think that is wrong, and I think it is wrong in a way that matters.

Compare the null report against the industry standard. In a bull market, the modal crypto research artifact is a twenty-five hundred word document with a bullish thesis, twelve data points of unclear provenance, a tokenomics section that reproduces the project's own pie chart without comment, a risk section that lists smart contract risk and regulatory uncertainty as generic line items, and a conclusion that says the project is well positioned. It is fully populated. Its information density is not zero, but it is low, and — this is the critical part — its low density is invisible, because the slots are filled with plausible content.

The null report has an information density of zero and says so sixty times.

Which document is more dangerous?

I have spent a decade doing code-level post-mortems, and the pattern never changes: the failures that cost the most are the ones that looked fine. In 2021 I declined a set of paid partnerships to do a line-by-line review of an ERC-721A implementation ahead of a major mint. I found a subtle overflow in the mint path that could produce unbounded tokens under high concurrency, reported it privately, and watched it get patched before launch. The reason that bug was worth finding is that it was invisible in every functional test. The contract worked. The mints succeeded. The state was wrong only at the boundary.

Research has the same boundary. Nobody loses money on a document that says insufficient information. They lose money on a document that says the treasury is well capitalized, based on a number the model invented because the source page did not load.

The honest artifact is not the populated one. It is the one that knows what it does not have.

This is uncomfortable, because it implies that the industry's output quality is negatively correlated with its output volume. Every pipeline that eliminates its null path — by prompting harder, by retrying with a different fetch strategy, by loosening the extraction threshold so that fewer documents return empty — is increasing the number of populated reports. It is not increasing the number of true reports. Those are different metrics, and only one of them is being optimized.

There is a second contrarian point, and it is about the Layer 2 landscape, which is where I spend most of my working hours.

The competition between the major rollup stacks is not decided by proof systems. It is decided by which ecosystem convinces more teams to deploy a chain, because the value accrues to whoever owns the default. That is a distribution contest wearing technical clothing. Research pipelines are part of that distribution layer. They are how a narrative reaches the people who allocate capital. And a distribution layer optimized for volume rather than accuracy produces exactly what you would expect: an enormous quantity of confident, structurally perfect, semantically empty material.

The null report is what the distribution layer looks like when it accidentally tells the truth. It is the only honest document in the stack, and it exists only because nobody built the branch that would have suppressed it.

I am not arguing that we should ship empty reports. I am arguing that we should stop treating their absence as an improvement, and that the metric we should be tracking is not reports generated. It is reports declined.

Takeaway: Build the Revert

The fix is not exotic. It is four requirements, and I would refuse to sign off on a research pipeline that lacks any of them.

One: make empty input a hard failure, not a soft state. Stage one must raise when it extracts zero information points. Not return an empty list. Not return a null-filled object. Raise, with the upstream HTTP status, the byte length of the fetched document, the number of characters remaining after stripping, and the extractor's confidence. A null payload that reaches stage two is a pipeline defect, and the defect should be loud enough to page someone.

Two: validate content, not shape. Schema validation is necessary and insufficient. Every stage boundary needs a semantic minimum — at least N information points, each with a non-empty source span and a resolvable entity. I would set N at five for a full nine-dimension run and refuse the run below that. A report built on two facts is not a report; it is a hypothesis with formatting.

Three: make the null state a first-class output. The report that reached my inbox did the right thing by accident, because its template happened to include a data-availability field. Make that deliberate. A pipeline that cannot analyze should emit a short, machine-readable status object and exit non-zero. It should not emit four thousand words of scaffold. The scaffold is the attack surface.

Four: instrument the null rate. Track extraction failure rate as a first-class metric, broken out by source domain and by failure cause. A domain with a forty percent null rate is telling you something — either about your fetcher or about the domain's honesty. I want that number on a dashboard, not buried in a log file that nobody reads until an incident review.

The forward-looking question is not whether pipelines will get better at extraction. They will. The question is what happens when every actor in this market has one, and the marginal cost of a confident, structurally perfect, factually empty research document falls to zero.

We are close to that. The null report I received is the artifact of a system that failed correctly. In eighteen months, the systems that fail correctly will be the minority, because failing correctly has no KPI. There is no dashboard line for reports we declined to generate. There is no bonus for the pipeline that raised an insufficient-input exception instead of writing four thousand words about nothing. The incentive gradient points entirely the other way, and incentive gradients win.

The verification is the product. Everything else is block space filled with NOPs.

And the uncomfortable version of the question, the one I have not been able to answer: if a document contains no facts, makes no claims, and scores itself zero, is it a research report that failed — or is it the only honest report your desk produced all quarter?