Blanket Papers No.12026-08-05

Sixty ways to find nothing

What 71 designed risk shapes found, and did not find, on a live exchange

The product read 71 written business descriptions, named the risk each one carried, and went looking on a live exchange for a contract that would pay when that risk arrived. It found one 11 times.

Those descriptions were written for this product, not collected from it. Seventy of them are generated business types built to give the matcher broad coverage, and the last is a sports demo. So this is a coverage reading of the exchange against plausible small-business risk, and not a measurement of what real owners ask for.

The other 60 are the subject of this paper. A miss is usually reported as a blank. It is not blank. Each of these briefs left a written record of what it looked at and why it walked away, and read together those records describe the shape of a market that does not exist yet.

71briefs published
11found a contract
60found nothing that fits

Section 1

What a miss looks like from the inside

A miss arrives in one of three shapes, and they do not overlap. The brief either wrote the gap down, or stopped and put a question back to the owner, or recorded nothing at all. Crossed with whether anything was examined first, that is the whole anatomy.

Read the second column first. In 11 of the 60 misses the exchange offered nothing close enough to open. In the remaining 49, there were candidates on the table, 203 of them, and every one was turned down.

Section 2

Why the candidates were turned down

Across the corpus, 250 contracts were examined and 219 were rejected with a written reason. The reasons are near-unique text: 207 of them are different strings. They are grouped below by an ordered set of patterns, first match wins. The full rule list is printed at the end so the grouping can be argued with.

219 of 219 notes fall under a rule and 0 do not. That coverage is descriptive rather than predictive: the rules were written by reading these same notes, which the methods block states plainly.

Section 3

Which risks found nothing

Sorted by how often the risk was detected. Of the 9 risk types the corpus names, 3 matched a contract zero times. The figure on the right of each row is the briefs that found a contract over the briefs where that risk was detected.

Section 4

The gaps, in the product’s own words

When a brief could not cover a risk it wrote the gap down under a name. These are those names, and how many times each was written.

9 further briefs never got as far as a gap. They stopped and asked the owner a question instead. Every one of them asked the same question: What weather would hurt the business most: heavy rain, extreme heat, cold, or another condition? Those misses are not the exchange’s doing. They are what happens when a risk is stated too loosely for any contract to settle on it.

Section 5

When it did fit, how well

The 11 briefs that selected a contract each recorded how loosely the contract is tied to the business result. Every one of them recorded a mismatch.

Methods

How this was counted

Rendered verbatim from the dataset. Nothing in this block is edited on the page.

Which corpus

  • THE CASES ARE DESIGNED, NOT COLLECTED. 70 of the 71 published cases are generated personas from data/personas/personas.json, a file that self-describes as built for this tool to give broad business-type coverage for semantic matching; the 71st is a sports demo fixture. None is a real submission from a real owner. This paper is therefore a coverage study of the exchange against plausible small-business risk shapes, and it is NOT a measurement of customer demand, of what real owners ask for, or of how often real businesses go uncovered. Read every count below as a fact about this designed corpus.
  • The corpus is the published one: frontend/public/kg/cases_index.json and the seam files beside it. That is what the product actually shipped to readers, and it holds 71 cases.
  • It is not the working case directory, which holds more. An earlier probe measured the working directory, and the count it produced was wrong for the purpose of a paper. This module has no code path to that directory.
  • The published corpus is generated by frontend/scripts/materialize-data.mjs from committed sources, so it can be rebuilt exactly, but it must be rebuilt before this dataset can be.

What was included

  • Every case listed in the published index is included. There is no sampling and no selection on outcome.
  • A case counts as having found a contract when the construct stage carries at least one sized position. Everything else counts as a miss.
  • A miss counts as having examined no candidate when the translate stage recorded no evaluated market at all.
  • A rejection note is included when its candidate's decision is exactly 'rejected'. Candidates recorded as recommended, shown as a signal, or left unlabelled are reported in the decision counts and excluded from the reason coding.

What was excluded

  • Owner input is not read and does not appear here. The published seams carry it; this dataset does not.
  • Cases the publication filter withheld are absent by construction, because they are absent from the published index this module reads.
  • Trading activity, volume, open interest and quote age are not read, not counted and not reported. Thinness does not rank or explain anything in this paper.
  • No dollar figure is totalled anywhere. Money appears only where a single case's own published number is restated for that case.

How the reasons were grouped

  • The rejection notes are free text and near-unique: 250 candidates were examined across the corpus and the rejected ones are almost all differently worded.
  • They are grouped by an ordered list of regular expressions, first match wins. A note that names two defects is counted under the earlier rule, so the shares are of a note's leading reason, not of every reason it mentions.
  • The full rule list is published in this dataset under rejection_reasons.coding_scheme so the grouping can be re-run or contested.
  • The rules were written by reading this same corpus. The coded share is therefore descriptive of these notes and is not a held-out measurement of how well the scheme would code notes it has not seen.

What could not be measured

  • Timing relation: the shipped seams predate the label. The string 'timing_relation' does not occur in any published seam, so no census of timing mismatch is possible and none is attempted. The window-related rejection code is read from the analyst's own words, not from that enum.
  • Relationship mismatch kind: this label is carried, at translate.translations[].relationship_evidence.mismatch.kind. But a translation only exists where a contract was selected, so the enum describes how the fits are imperfect and is silent about the misses. It is reported under the fits and kept out of the census of misses.
  • Settlement outcomes: the published corpus carries no settlement result field. This module verifies that rather than assuming it, and does not state an outcome it cannot compute.
  • Whether a fitting market has listed since: not measured. It would need a second snapshot generation and a per-gap search, and neither is in this module. A later paper can answer it; this one does not guess.
  • How the fits would have performed: not measurable. Ten of the eleven selected contracts had not reached their close as of the market state this dataset is dated to.

Which aggregates are refused

  • There is no win rate in this dataset, no ROI, no return, and no total of dollars won or lost.
  • The refusal is structural, not editorial. assert_no_money_summation parses this module's own syntax tree and rejects any addition or sum() over a money-named value; assert_no_money_aggregates walks the emitted payload and rejects a money-named key outside a single-case record. Both run on every build of this dataset.
  • One settled brief is one observation. It is reported as an observation and is not turned into a rate.

How to reproduce this

  • Run `npm run materialize` in frontend/ to rebuild the published corpus, then `python pipeline/settle_report.py`. The output is byte-identical across runs.
  • No network call is made and no model is called. Every figure in this dataset is counted from files on disk.
  • No wall clock is read. The corpus dates itself from its own stage stamps (2026-07-14T19:20:00.000Z to 2026-07-16T00:00:00.000Z) and the market state dates itself from the published snapshot record.

The coding scheme, in full

  • 1another_line_wonpassed on because another|not selected in this saved analysis|nearby line on the same index|is the selected reference|another persisted candidate|on the same ladder gave|gave better|line for the same cost
  • 2wrong_place\bbasin\b|wrong ocean|wrong (city|team|place|state|region)|nationwide|not the gulf|where this .* sits|not local|storms hitting|weather hitting|no connection to|not gatlinburg|foot traffic in|to a \w+ store|not boston|not any chicago|not las vegas demand|the los angeles club
  • 3wrong_window\bwindow\b|settles months|stops watching|keeps observing|long after|for the year, not|this fall, not|one thursday|not on thursday|only covers one day|too narrow a trigger|year-long|a single (fed )?meeting|a single hike|before your risk|single day's|single-day|one day's temperature|quarter-long|season win (total|count)|full season|single game trigger|expires in days|wrong season
  • 4wrong_levelbar too high|lower (price )?line|higher (rain |price )?line|sets the .* too (high|low)|misses smaller|below (the owner's|your) stated|paying (out )?too early|pays out too early|far above (the|your) stated|far above your|trades less than|misses most of your risk
  • 5priced_near_certainnear[- ]?certain|already near certain|nearly certain|almost certain|pays out almost regardless|pays too easily|costs almost as much|pays almost nothing as protection
  • 6priced_near_impossiblenear[- ]?impossible|rare extreme|(far )?into the tail|only in rare|too far out to be useful|very unlikely|rarely pay|price is too low|harder to reach|pays out less often
  • 7wrong_subject, not |does not track|do(es)? not (move|track|reflect)|don't (track|move)|ha(s|ve) no (link|tie|bearing)|no link|no tie|no (clear )?link|no stated connection|not named as|unrelated|different (industry|regulator|peril|commodity|driver|loan market|policy area|product)|a different (price|thing) than|wrong (commodity|peril|driver|metal|trigger|input|direction)|same wrong|same mismatch|broad(er)? (measure|basket)|an output for|not a driver of|not an input|a step further from|weaker fit|too small and specific|too narrow a driver|nothing to do with|move separately