Empty Schema, Null Signal: Anatomy of a Failed Crypto Analytics Pipeline

A collaborator forwarded me a pipeline output on Tuesday. Seven fields. Title: resolved. Summary: null. Author stance: undefined. Key points: empty array. Source quality: unrated. Time sensitivity: unassessed. Article type: null. The parser had ingested a complete document — roughly fourteen hundred words of crypto commentary — and returned a structurally valid object containing zero information. Syntax passed validation. Semantics were void. I have seen this exact behavior in deployed contracts. A function reverts silently because the input never satisfied the require() it was written against; the caller reads a revert reason and files it as success. The ABI promised a boolean. The runtime returned nothing. Nobody traced the gas. The failure is not in the language model. The failure is in the schema. Someone asked an extraction layer to output a verdict, and the extraction layer behaved correctly: when a value is not computable from its input, it returned null. I do not read the whitepaper; I read the bytecode. The bytecode would have told you the field was uncomputable before a single token was generated. The crypto intelligence stack has spent eighteen months bolting language models onto indexers and calling the result analytics. The pitch is uniform across the product category: ingest unstructured crypto content — governance posts, podcast transcripts, on-chain activity, Discord chatter — and emit structured signal. Narrative detection. Sentiment scoring. "Alpha extraction." Every surface of the market that used to be read by humans is now scheduled to be parsed by a model, and the model's output is scheduled to be consumed by a trader. The architecture that most teams converge on is a two-phase pipeline. Phase one performs structured extraction: it reads a source and produces a typed record — title, author, date, claims, evidence, source quality, stance, time sensitivity. Phase two consumes that record and performs judgment: is this bullish or bearish, is it actionable, does it decay. It is a clean design on a whiteboard. It is almost always broken in production, and the break is almost always at the same seam. The seam is this: the phase-one schema routinely contains fields that can only be produced by phase two. Stance is not extractable. Source quality is not extractable. Time sensitivity is not extractable. They are judgments, and they are being demanded of a layer that computes — not concludes. In a sideways market the demand for signal is highest and the supply of it is lowest. This is precisely when the temptation to fabricate structure is strongest, and precisely when a fabricated stance is most expensive to the person who acts on it. The empty template I received is not an anomaly. It is the modal output of a mis-typed schema. The interesting question is not why it happened. The interesting question is why the schema was allowed to exist, and what happens to anyone who trades on the fabricated version of the same object. Separate the two functions before you build the pipeline that composes them. Extraction is f: bytes → facts. Judgment is g: facts → verdicts. These are different computational classes. f is deterministic given the same input and the same block height. It is reproducible. Two engineers running f on the same transaction get the same bytes back. g is neither. Two analysts running g on the same facts will disagree, and the disagreement is not a bug — it is the entire content of the judgment. Now look at what the phase-one schema asked for. It asked for a title — extractable, f(·). It asked for a summary — arguably extractable, a compressed restatement of observed text. It asked for key points with evidence and source quality — the claims are extractable; the quality rating is not. It asked for author stance — pure g. It asked for time sensitivity, with a timestamp attached — the timestamp is f, the sensitivity is g. So the schema is a union of f's codomain and g's codomain, presented as if both were f. When the extraction layer reaches the g-fields, it has no computable value to write, and it writes null. Downstream, a consumer reads null as "missing data" — a sparse record — when the correct reading is "wrong layer." The record is not incomplete. It is mis-specified. Time sensitivity deserves its own paragraph because it is the field most teams get wrong in the most instructive way. The timestamp is f: a block height, a publication date, a Unix integer. It is observed. The half-life is g: the estimate of how fast the claim stops mattering. A team that conflates the two ships a dashboard that sorts by "recency" and calls it "relevance." They are not the same object. One is a coordinate. The other is a forecast. I have run this exact decomposition on contracts, and the discipline transfers cleanly. In 2019 I spent forty hours tracing a reentrancy vulnerability in the remixed source of an ICO contract — Solidity 0.4.24, a state-ordering bug that drained 42 ETH from the treasury. The facts were computable: the call stack, the storage writes, the order of external calls versus balance updates. The malicious intent was not computable. It was a conclusion I drew after establishing the facts, and I labeled it as a conclusion. I did not ask the disassembler to emit "intent: malicious" as a field. The disassembler emits opcodes. Intent is downstream. If I had put "intent" in the extraction schema, I would have gotten null in my own report, and I would have deserved it. The pipeline I was shown did not maintain that boundary. It emitted an object whose contract promised conclusions and whose implementation could only deliver observations — so the observations that were available, like the title and the presence of an empty array, survived, and the conclusions came back null. The shape of the null distribution is the diagnostic. Fields that are null are the fields that belong to g. The empty array that should have held key points is the tell: the extractor could not identify claims because the schema never asked it to find claims — it asked it to find claims with quality ratings, and it could not produce the ratings, so it produced nothing. There is a second failure mode stacked underneath the first one, and it is the more common one in practice. The empty template is frequently a build artifact, not an analysis artifact. A prompt template with unbound variables produces exactly this output: the schema is instantiated, the variable placeholders are never substituted, and the model receives a request to fill fields it was never given the source for. This is a missing format call, not a missing thought. It looks identical to the schema error from the consumer's side — both return null — but the repair is different. One is a type fix. The other is a string concatenation that never ran. I have seen teams spend a week tuning model temperature on a pipeline that was dropping its input at the join. The third layer is field-mapping drift. Upstream produces a record with the key "title." Downstream expects the key "resolved." Somewhere a rename landed in a config file and nobody versioned the schema. The extraction works perfectly. The binding fails silently. Every field arrives null because every field arrived under a name the consumer never learned. This is the crypto-indexer equivalent of a subgraph that indexes a proxy whose implementation address changed: the query runs, the result set is empty, and the dashboard renders a flat line that everyone reads as "no activity" instead of "no index." All three failures produce the same observable — a well-formed object with no information — and all three are structural. None of them are solved by a better model. A better model asked to compute an uncomputable field produces a more confident null, or worse, a fabricated value. The second outcome is the dangerous one. A fabricated stance does not announce itself. It arrives typed as a string, wrapped in a schema that promised it was extracted, and consumed by a reader who has no way to see the layer boundary underneath it. The bull case for the pipeline is that it is honest, and the bull case is correct. The obvious reaction to an empty template is "the tool is broken." The more precise reaction is that the tool refused to fabricate. On-chain data has exactly one property that no other financial data source has: it cannot lie. An indexer cannot tell you a transfer did not happen. A node cannot invent a balance. That property is the entire reason on-chain analysis is worth doing, and it is destroyed the moment you wrap the observed layer in an inference layer that fills its missing fields with plausible values. The camp that says "just add a judgment stage" is solving the right problem the wrong way. Adding phase two is necessary and insufficient. If you leave the uncomputable fields in the phase-one schema, phase two inherits a record where the judgment fields are null, and it will either re-derive them — in which case why did phase one claim to produce them — or it will hallucinate around them. The fix is not to move the fields downstream. The fix is to delete them from the extraction contract and re-declare them where they belong, clearly marked as inference. There is a version of this discipline that the industry already practices on-chain and refuses to practice off-chain. Nobody asks an event log for a token's "level of decentralization." Nobody asks a transaction receipt for a project's "long-term viability." Those are analyses, and everyone understands they are analyses because they sit one layer up from the raw data. The crypto content pipeline forgot the layer boundary because the source happened to be prose instead of bytes. Prose does not change the computational class of the field. A judgment is a judgment whether it is made about calldata or about a tweet. The next generation of crypto analytics will not be won by the team with the largest model. It will be won by the team that can draw the line between what is observed and what is inferred, and hold it under pressure. The intelligence layer keeps returning empty templates because the schema keeps asking extraction to think. Fix the schema, and the nulls become informative: a null in a judgment field is a correct output, not a missing one. The question worth sitting with is not whether your pipeline can produce a stance. It is whether you can tell the difference between a stance it observed and a stance it invented — and whether you would notice if it stopped telling you.