Licensing data is buying a set of claims: coverage, counts, freshness, provenance. The data room is where those claims are supposed to become checkable. Most data rooms fail at this. They contain a deck, a whitepaper, and a flattering sample, none of which can contradict the marketing page even in principle.
This guide describes what a serious data room contains and how to inspect one in about thirty minutes. It applies across lanes: market data, organizational data, code. The worked examples come from Gerra's public data-room artifacts, because inspecting real files beats discussing hypothetical ones.
Five artifact classes do the real work: dated schema files, delivery-shape samples, checksums, reconcilable manifests, and stated limitations.
1. Schema files with extract dates
A schema file should be machine-readable, enumerate every file in the delivery, and state per-file record counts and field meanings, including nested structures. The schema published for Gerra's Retail Sentiment Stream is a usable reference shape: schema.json opens with "extract_date": "2026-02-24", then walks each delivered file with its record count and a field-by-field description, down to the nested user object inside each message.
The date is load-bearing. Schemas drift as products evolve, and an undated schema cannot be reconciled against the sample in front of you or the delivery you will receive. You cannot even tell whether it describes what exists or what someone once intended to build. If the schema, the sample, and the coverage claims carry no dates, ask which of them is current; the answer is usually instructive.
2. Samples shipped in delivery shape
The sample is the only part of the room you can fully test, so it must be shaped exactly like delivery: same formats, same identifiers, same conventions, same field set. The Federal Software Ledger sample ships real procurement records in both delivery formats, JSON and CSV, with the full production field set intact: reseller flags, point-in-time publication dates, fiscal fields, award identifiers that can be reconciled against the public source.
The anti-pattern is the hand-built showcase: a curated slice with cleaned values and simplified fields that will never appear in the paid corpus. Three tests catch it. Could this sample have been drawn mechanically from the release? Does it include the boring operational fields, or only the impressive ones? Does every field in the sample appear in the schema, and vice versa?
3. Checksums for every member
Every member of a sample or delivery archive should carry a SHA-256 digest, and the archive itself should have one. SHA-256 is specified in NIST's FIPS 180-4 Secure Hash Standard; its role here is to bind every claim in the room to exact bytes. Without member-level checksums, "the sample" is whatever you happened to download that day, and any later dispute about what was shipped is undecidable.
The downloadable Codebase Collection sample is the worked example: a 479 KB ZIP whose SHA256SUMS file covers every packaged member, with the ZIP's own SHA-256 published on the dataset page. Verification is one command:
shasum -a 256 -c SHA256SUMS
If this fails, stop. Nothing else in the room means anything until the bytes match.
4. Manifests that reconcile with the bytes
A manifest states what the package contains: identifiers, refs, hashes, and per-unit counts. Reconciliation means re-deriving those numbers from the extracted bytes yourself. The codebase sample packages this as MANIFEST.json, a DATA_CARD.md with exact measurement definitions, a SELECTION_REPORT.json recording how the sample unit was chosen, an anonymous commit index, and the checksum file.
Its published claims are all recomputable: 119 source text files, 18,497 measured code lines, a cloneable 23-commit Git history, and five authentic patch pairs. Count the files, rerun the line counter under the data card's definition, then clone and inspect the history:
git bundle verify history/repository.bundle
git clone history/repository.bundle repo
git -C repo fsck --strict
git -C repo log --oneline --graph --all
The full release applies the same discipline at scale, and publishes the distinctions that sloppy corpora blur: 178 repositories, 15,238 unique commit objects against 16,555 summed commits, 23,633 current files, 47.8 million historical lines, 178 of 178 bundles verified with zero checksum mismatches. The methodology and audit trail are documented in the Codebase Collection technical note. Counts you cannot reproduce from bytes are estimates wearing precision.
5. Stated limitations and what was not tested
The most trustworthy sentence in a data room is a negative one. The codebase sample states that 98 of 98 JavaScript files parse and that zero relative imports fail to resolve, and then states that runtime test success is not claimed, because the exact dependency tree was unavailable. Gerra's Operational Telemetry report documents an activity graph from 5 consented companies across 38 tools and says outright that it reports no signal, no model, and no predictive result.
This practice has a formal ancestor in Datasheets for Datasets, which argued that every dataset should document its composition, collection process, and recommended limits. A room containing no negative statement anywhere means the limits were never looked for, or were found and not written down. Either one should move your prior.
The room at a glance
| Artifact | Question it answers | How you check it |
|---|---|---|
| Schema with extract date | What fields exist, as of when | Diff sample fields against schema fields |
| Delivery-shape sample | What you will actually receive | Parse it with your production loader |
| Per-member checksums | Are these the claimed bytes | `shasum -a 256 -c SHA256SUMS` |
| Manifest and data card | Do published counts reconcile | Recount from the extracted files |
| Limitation statements | What was not tested | Look for explicit negative claims |
- Download the sample and verify every checksum. A failure here ends the exercise.
- Extract and parse the sample with the tooling you would use in production, not the vendor's viewer.
- Pick two or three published counts and recompute them from the extracted bytes.
- Diff the sample's fields against the schema file. Note anything present in one and absent in the other.
- Check the dates: schema extract date, sample generation date, stated coverage window. They should cohere.
- List the negative statements. If you cannot find any, write down the ones you would expect and send them as questions.
- For data derived from public sources, reconcile one record back to the primary source by its identifier.
For code datasets specifically, where Git integrity, deduplication, secret scanning, and test evidence add their own failure modes, the companion deep dive is How to Audit a Codebase Dataset Before You License It.
A data room built this way costs the vendor real effort, which is the point. Each artifact is cheap to fake in isolation and expensive to fake coherently: the checksums must match the manifest, the manifest must match the bytes, the schema must match the sample, and the limitations must survive your protocol. Thirty minutes of inspection tells you whether the work was done.