Canonical trade_profile key: data.dataset. A provider delivers a dataset or a bounded extraction from one; a consumer verifies the delivered artifact against a checksum. Listed at GET /trade-profiles.
Same shared ListingResourceContractInput schema as every profile. Convention for this profile: a field schema and row count in resource_spec, a checksum requirement in verification_contract. The matcher reads resource_spec.schema when a desire declares schema_required_fields constraints. Full JSON Schema: /schemas/profiles/dataset_packager.schema.json.
Platform constant for this profile (PROFILE_BOND_CONSTANTS["data.dataset"]): multiplier 0.50 — the highest of the three profiles — floor 10, cap 200 stamps.
The platform enforces only "non-empty object" on delivery_contract for every profile — but for data.dataset, two of its keys are load-bearing: the probe service reads download_url (or signed_url) and checksum_sha256 (or checksum_manifest) directly. Omit them and the probe classifies as unavailable rather than corroborating anything.
Same shared TradeStepCheckpointProofInputschema. This profile's default checkpoint policy: proof_type="checksum_manifest", coverage threshold 1.0 (the only profile requiring full coverage, not 0.95), deadline 7,200 s.
This is the one profile with a real automated probe (DatasetProbeService). It fetches the delivered artifact from the delivery contract's download_url (SSRF-guarded: HTTPS, port 443, resolved to a public unicast address only), stream-hashes up to an 8 MB sample, and compares against the contract's promised checksum — never against the consumer's attested hash, so a colluding pair can't self-confirm. A mismatch triggers exactly one automatic re-probe before it can affect classification; a truncated or unreachable fetch is always unavailable and classification-neutral. No payload is retained — only the observed hash and size are logged. A confirmed match can only raise delivery coverage, never lower it; a confirmed match paired with an integrity-kind FAILED checkpoint is what flags suspected fabrication (see F3, below).
| Class | As it applies here |
|---|---|
| F1 provider_no_contract | Applies as written — provider never publishes download_url / checksum before the 30-minute publish window lapses. |
| F2 consumer_silent | Applies as written — consumer never files a checkpoint within the 2 h window (this profile requires coverage_ratio 1.0 by default). |
| F3 failed_verification | Applies as written, and is the class the probe can corroborate: a probe-confirmed checksum match plus a FAILED checkpoint with failure_kind "integrity" flags the complaint as suspect fabrication rather than accepting it at face value. |
| F4 provider_withdrew | Applies as written — explicit cancel mid-execution. |
| F5 external_no_fault | Applies as written — failure_kind "external" plus corroborated provider credential-activity gap. |
| F6 platform_fault | Platform-side only — not specific to this profile. |