Seller and agent acceptance standards

Overview

Graunt is a marketplace for agent-ready data: evaluated packet assets with declared rights, provenance, freshness, and machine-readable manifests. This page is the operational acceptance contract that sellers, providers, and agents follow before a packet is likely to be accepted. The same contract is published as a JSON API at /v1/meta/seller-standards.

• Evaluated, not verified. Graunt evaluates packets and validates objective structure (supported formats, required fields, manifest hashes, bundle structure, asset role taxonomy). Graunt does not verify upstream rights, provenance, or fitness for any specific buyer use.
• Sellers remain responsible for the rights, provenance, and accuracy of the material they submit.
• Admin review remains the publish gate. Every listing enters PENDING_REVIEW; admin approval is required before it appears in the public catalog.
• Requirement identifiers on this page are submission-checklist identifiers, not reject reasons. The canonical reject-reason taxonomy is owned by a separate slice.

Schema version: 1. Requirement set version: 1.

Accepted packet shape

A Graunt packet is a self-describing asset:

• One packet family from the canonical five-value vocabulary.
• One packet kind from the registered slug registry.
• A manifest covering 11 required presence fields plus seven evidence buckets.
• One or more delivery artifacts in a supported format.
• A rights block and rights passport declaring license, origin, allowed actions, and obligations.
• Optional publication metadata for works that have a publisher, edition, or standard identifier.
• For multi-asset packets: a packet bundle revision with tagged asset roles and a single manifest sha256 covering the canonical inventory.

Packet families

Five canonical packet families. Adding a family requires a new locked decision.

• NORMALIZATION — Normalization. Buyer-supplied data normalized against a canonical entity-resolution rule set with match confidence and source trace.
• TAXONOMY — Taxonomy. Controlled vocabularies, classification trees, and crosswalks with versioned scope.
• WORKFLOW_SOP — Workflow / SOP. Procedural guides and standard-operating-procedure packets with declared scope and applicability.
• REFERENCE_DATA — Reference data. Authoritative reference material — standards, regulations, lookup tables, machine-readable metadata.
• EVALUATION — Evaluation. Labeled evaluation sets with rubric and optional scoring reference for downstream LLM or system evaluation.

Packet kinds

The registered slug registry for first-revenue packet kinds. Each kind maps to exactly one family. Adding a new slug requires a profile spec block plus a registry extension.

• standards_spec_metadata.v1 — Standards Spec Metadata (v1) (family REFERENCE_DATA). Machine-usable metadata for technical standards (title, issuing body, version, jurisdiction, citation) across a declared scope.
• material_properties_reference.v1 — Material Properties Reference (v1) (family REFERENCE_DATA). Material property reference data (mechanical, thermal, electrical, chemical) with units, conditions, and per-row citation.
• vendor_master_normalization.v1 — Vendor Master Normalization (v1) (family NORMALIZATION). Normalize a buyer's raw vendor master against a canonical entity-resolution rule set with match confidence and source trace.
• po_invoice_matching_eval.v1 — PO Invoice Matching Eval (v1) (family EVALUATION). Labeled PO/invoice matching evaluation set with rubric and optional scoring reference for downstream LLM/system evaluation.

Accepted formats

Two related but distinct format vocabularies. Each is locked.

Manifest delivery formats — packet_manifest.delivery_format

What the packet declares as its overall delivery format. Surfaced in the API as accepted_formats with scope: "manifest_delivery_format".

• CSV — CSV (.csv) · text/csv
• JSONL — JSON Lines (.jsonl) · application/jsonl
• JSON — JSON (.json) · application/json
• PARQUET — Parquet (.parquet) · application/octet-stream
• MD — MD
• PDF — PDF document (.pdf) · application/pdf
• ZIP — ZIP

Bundle asset upload formats — packet_bundle_asset.file_format

What the bundle validator accepts for each individual file in a multi-asset bundle. Narrower than the manifest delivery_format set. Surfaced in the API as bundle.accepted_asset_formats.

Accepted per-asset formats: CSV, JSON, PARQUET, TEXT, JSONL, PDF.

The declared per-asset file_format must match the asset bytes and the original filename extension. Mismatches are rejected at finalize.

Rights and provenance

Every packet must declare the rights basis and source chain for its underlying material. Graunt records seller-declared rights; it does not verify upstream ownership or licensing.

Vocabularies in use:

• License families (19): PROPRIETARY, CC0, CC_BY, CC_BY_SA, CC_BY_NC, CC_BY_ND, CC_BY_NC_SA, CC_BY_NC_ND, MIT, APACHE_2_0, BSD_2_CLAUSE, BSD_3_CLAUSE, GPL_3_0, LGPL_3_0, MPL_2_0, ODC_BY, ODC_ODBL, PUBLIC_DOMAIN, GOVERNMENT_WORK
• Rights origins (4): ORIGINATOR, LICENSED, PUBLIC_DOMAIN, GOVERNMENT_WORK
• Rights-passport access modes: OPEN_PUBLIC, STANDARD_PURCHASE, GATED_VERIFIED_BUYER, CONTROLLED_ACCESS, BUYER_EXTERNAL_LICENSE
• Rights-passport delivery modes: STANDARD_DOWNLOAD, API_QUERY

• RIGHTS_ORIGIN_DECLARED required applies to: all_packets
  Declare a rights origin (originator / licensed / public domain / government work).
  Expected evidence: rights_block.rights_origin set to one of the four locked values; rights passport access_mode consistent with the origin.
  Machine fields: rights_block.rights_origin, rights_passport.access_mode.
  Graunt does not verify upstream rights chains; declared origin is a seller statement.
• RIGHTS_LICENSE_FAMILY_DECLARED required applies to: all_packets
  Pick a license family from the locked vocabulary and declare it consistently in both the rights block and the rights passport.
  Expected evidence: rights_block.license.family populated; rights_passport.license_family_ref equal to the rights_block value; license identifier or URL where the family is non-proprietary.
  Machine fields: rights_block.license.family, rights_block.license.identifier, rights_passport.license_family_ref.
• RIGHTS_SOURCE_DISCLOSURE required applies to: all_packets, seller_rights_claims
  Disclose the rights source — own compilation, identified upstream license, public-domain corpus, or government work. Vague claims ("found online", "open data") are not sufficient.
  Expected evidence: human-readable rights source statement; linked license or upstream agreement reference where applicable.
  Machine fields: rights_block.license.url, rights_block.license.text_hash.
• PROVENANCE_SOURCE_LIST required applies to: manifests
  Manifest sources[] must list at least one source entry with type (public / licensed / buyer_provided / synthesized).
  Expected evidence: manifest.sources[] non-empty; each source entry carries type plus url, citation, or hash.
  Machine fields: packet_manifest.sources[].type, packet_manifest.sources[].url, packet_manifest.sources[].citation, packet_manifest.sources[].hash.
• PROVENANCE_NO_INFERRED_CLAIMS prohibited applies to: seller_rights_claims, agent_prepared
  Do not claim rights or provenance beyond the evidence on hand. No "likely public", no "assumed open", no "presumed government work" without a citation.
  Expected evidence: every rights claim traces to a concrete source or license document.
  Graunt does not enforce this rule at publish time; sellers remain accountable for the claims they submit.

Publication metadata

Where the underlying material is an editioned publication, standard, regulation, or formally published work, declare publisher, role, and identifiers so buyers and agents can locate the canonical source.

Publisher roles: PUBLISHER, EXCLUSIVE_DISTRIBUTOR, NON_EXCLUSIVE_LICENSEE, SELF_PUBLISHED, GOVERNMENT, STANDARDS_BODY, OPEN_LICENSE, UNKNOWN.

Publication statuses: ACTIVE, SUPERSEDED, WITHDRAWN, DRAFT, DEPRECATED, EXPIRED, CURRENT.

Standard identifier kinds: doi, isbn, issn, standard_number, patent_number, regulatory_citation.

• PUBLICATION_METADATA_COMPLETE recommended applies to: datasets, text_assets
  Populate listing_publication_metadata with title, publisher, role, publication date, and version where the source is a published work.
  Expected evidence: publication_metadata.title and publisher_name set when the source has them; publication_metadata.publication_date in YYYY-MM-DD form.
  Machine fields: publication_metadata.title, publication_metadata.publisher_name, publication_metadata.publication_date, publication_metadata.version_number.
• PUBLISHER_ROLE_DECLARED recommended applies to: datasets, text_assets
  Declare the publisher's role: publisher, exclusive distributor, government body, standards body, open-license, self-published, or unknown.
  Expected evidence: publication_metadata.publisher_role from the locked vocabulary.
  Machine fields: publication_metadata.publisher_role.
• STANDARD_IDENTIFIERS_WHEN_APPLICABLE conditional applies to: datasets, text_assets
  Where the source has a standard identifier (DOI, ISBN, ISSN, standard number, patent number, regulatory citation), include it.
  Expected evidence: publication_metadata.standard_identifiers populated when applicable.
  Machine fields: publication_metadata.standard_identifiers.doi, publication_metadata.standard_identifiers.isbn, publication_metadata.standard_identifiers.issn, publication_metadata.standard_identifiers.standard_number, publication_metadata.standard_identifiers.patent_number, publication_metadata.standard_identifiers.regulatory_citation.
• JURISDICTION_DECLARED_WHEN_APPLICABLE conditional applies to: datasets, text_assets
  Where the source has a jurisdiction (federal, state, supranational), list ISO-style codes so jurisdiction filters work.
  Expected evidence: publication_metadata.jurisdictions[] populated with uppercase codes.
  Machine fields: publication_metadata.jurisdictions.

Freshness and known limitations

Declare how the packet ages, when it was last refreshed, and what is intentionally missing. Buyers planning recurring use depend on these declarations.

Update patterns: SNAPSHOT, EDITIONED, ROLLING_GROWING, ROLLING_LIVE, ERRATA_ONLY, WITHDRAWN.

• FRESHNESS_DATE_DECLARED required applies to: freshness_sensitive
  For freshness-sensitive packets (regulatory text, market data, current rosters), declare the as-of date or fetch date.
  Expected evidence: publication_metadata.last_reviewed_at or publication_date set; a human-readable as-of statement in the listing description.
  Machine fields: publication_metadata.last_reviewed_at, publication_metadata.publication_date.
• UPDATE_PATTERN_DECLARED required applies to: all_packets
  Declare the update pattern from the locked vocabulary: snapshot, editioned, rolling growing, rolling live, errata only, or withdrawn.
  Expected evidence: rights_block.update_pattern populated; packet_manifest.update_semantics populated and consistent.
  Machine fields: rights_block.update_pattern, packet_manifest.update_semantics.
• KNOWN_LIMITATIONS_DECLARED recommended applies to: all_packets
  List what the packet does not cover: source coverage windows, excluded geographies, missing fields, intentionally redacted material. A short "none observed" is acceptable; an empty section is not.
  Expected evidence: listing description includes a known-limitations section.

Manifests and integrity

Packet manifests are machine-readable contracts. The strict Zod schema rejects malformed manifests; sha256 hashes pin asset bytes.

Source types: public, licensed, buyer_provided, synthesized. Manifest sources must include at least one entry with a type plus a URL, citation, or hash.

• MANIFEST_HASHES_PRESENT required applies to: manifests, bundles
  Every delivered asset must carry a sha256 content hash; bundle manifests are sha256-hashed at finalize.
  Expected evidence: asset.content_sha256 in sha256:<64 hex> form; bundle revision carries manifest_sha256.
  Machine fields: packet_bundle_revision.manifest_sha256, packet_bundle_asset.content_sha256.
• MANIFEST_STRUCTURE_VALID required applies to: manifests
  Manifest passes the strict Zod schema: 11 presence fields, packet family + kind from the locked registry, validation status from the six-value bounded set.
  Expected evidence: packetManifestSchema parse succeeds; packet_kind is a registered slug; packet_family matches packetKindFamily mapping.
  Machine fields: packet_manifest.packet_family, packet_manifest.packet_kind, packet_manifest.validation_status.
• MANIFEST_SOURCES_LISTED required applies to: manifests
  Manifest sources[] is required and non-empty. Each source has a type, plus a url, citation, or hash where applicable.
  Expected evidence: manifest.sources[] populated; each source entry passes packetSourceSchema.
  Machine fields: packet_manifest.sources.

Packet bundles and asset roles

Multi-asset packets ship as a single packet_bundle_revision with one row per delivered file, controlled asset_role slugs, and enforced size caps.

Default launch caps: 1,000 assets per bundle, 5 GB per asset, 50 GB total. Higher tiers are reserved for future operator-managed overrides.

Required per-asset metadata: asset_role, file_format, file_size_bytes, content_sha256, original_filename.

Asset roles:

• PRIMARY — Primary. The principal delivered asset (the dataset, the document, the reference table). Every bundle must include at least one PRIMARY asset.
• SUPPORTING — Supporting. Auxiliary material — codebooks, schemas, supplementary data, intermediate artifacts.
• EVIDENCE — Evidence. Provenance, transformation, or scanner-evidence artifacts that back the manifest claims.
• MANIFEST — Manifest. Manifest snapshots and machine-readable contract files emitted alongside the delivered material.
• LEGAL_NOTICE — Legal notice. License text, attribution notice, or other legal-context documents associated with the packet.

• BUNDLE_ASSET_ROLES_VALID required applies to: bundles
  Tag every bundle asset with a valid asset_role from the locked five-value vocabulary.
  Expected evidence: packet_bundle_asset.asset_role is one of PRIMARY / SUPPORTING / EVIDENCE / MANIFEST / LEGAL_NOTICE.
  Machine fields: packet_bundle_asset.asset_role.
• BUNDLE_PRIMARY_ASSET_PRESENT required applies to: bundles
  Every bundle must include at least one PRIMARY asset. Validation rejects bundles that ship only SUPPORTING / EVIDENCE / MANIFEST / LEGAL_NOTICE rows.
  Expected evidence: packet_bundle_revision has at least one row with asset_role = PRIMARY.
  Machine fields: packet_bundle_asset.asset_role.
• BUNDLE_SIZE_LIMITS_RESPECTED required applies to: bundles
  Respect the bundle capacity caps. Default launch caps are 1000 assets per bundle, 5 GB per asset, 50 GB total. Higher tiers are not enabled today.
  Expected evidence: asset_count within cap; every asset within per-asset byte cap; sum of file_size_bytes within total cap.
  Machine fields: packet_bundle_revision.asset_count, packet_bundle_asset.file_size_bytes.

Evaluated quality posture

Graunt evaluates packets; it does not verify them. Graunt records presence-and-fact evaluation signals only. There is no public numeric rating, no aggregate trust signal, and no claim that an accepted packet is fit for any specific buyer use.

Graunt records presence-and-fact evaluation signals (row counts, schema coverage, manifest references, scanner disclosures where applicable). There is no public numeric rating, no aggregate signal, and no claim that an accepted packet is fit for any particular buyer use.

• QUALITY_SIGNALS_DECLARED recommended applies to: datasets
  Where applicable, declare evaluation signals: row count, schema coverage, sample completeness, coverage windows. Presence and fact only, never an aggregate rating.
  Expected evidence: dataset.row_count populated when known; ai_metadata.token_count populated for text assets.
  Machine fields: dataset.row_count, ai_metadata.token_count, ai_metadata.includes_examples.
• DATA_DICTIONARY_PROVIDED_WHEN_APPLICABLE recommended applies to: datasets
  Where the packet is a structured dataset, include a data dictionary (column names, types, descriptions) inside the manifest structure or as a SUPPORTING asset.
  Expected evidence: packet_manifest.structure.fields[] populated; or a SUPPORTING asset containing the dictionary.
  Machine fields: packet_manifest.structure.fields, packet_manifest.structure.field_dictionary_ref.
• TRANSFORMATION_LOG_PROVIDED_WHEN_APPLICABLE recommended applies to: datasets
  Where the packet is a derived or normalized work, include a transformation log: what the seller did to the source material, in what order, with what tools.
  Expected evidence: packet_manifest.build_recipe_ref populated; or an EVIDENCE asset containing the transformation log.
  Machine fields: packet_manifest.build_recipe_ref.

Validation and remediation

The six bounded validation statuses describe a packet manifest at a particular point in its review lifecycle. Accepted states: PASSED, PASSED_WITH_NOTES. Blocking states: PUBLISH_BLOCKED, EVIDENCE_INCOMPLETE.

• DRAFT — Draft. Seller is still composing the manifest; not yet submitted for review.
• STRUCTURAL_VALID — Structurally valid. Manifest parses against the strict Zod schema; evidence buckets may still be incomplete.
• EVIDENCE_INCOMPLETE — Evidence incomplete. Manifest structure is valid but required evidence is missing for the declared packet kind.
• PASSED_WITH_NOTES — Passed with notes terminal. Accepted; reviewer notes attached but do not block publication.
• PASSED — Passed terminal. Accepted with no outstanding notes.
• PUBLISH_BLOCKED — Publish blocked terminal. Manifest cannot be published as-is; the seller must fix the flagged issues before resubmission.

When admin review flags issues, the seller is expected to remediate before resubmission. Common remediation expectations:

• Correct manifest hash mismatches before resubmission.
• Add the missing publication metadata fields where the underlying source is a published work.
• Declare known limitations explicitly rather than implicitly.
• Clarify the rights origin and license family with linked evidence.
• Provide a non-empty manifest sources[] entry list.
• Tag every bundle asset with a valid asset_role and include at least one PRIMARY asset.
• Use raw enum values (e.g. NORMALIZATION) rather than humanized labels.

These identifiers are submission-guidance only. The canonical reject-reason taxonomy is owned by a separate slice and will surface there when it ships.

Agent submission expectations

Submissions prepared by agents must follow the same rules as human-prepared submissions, plus a handful of agent-specific expectations that protect downstream parsing and trust.

Agent-prepared submissions follow every requirement on this page, plus the agent-specific expectations below. The same identifiers appear in the JSON contract so an agent can self-check before posting.

• AGENT_RAW_ENUM_SUBMISSION required applies to: agent_prepared
  Submit raw enum values where the API expects them (e.g. NORMALIZATION, PASSED_WITH_NOTES, OPEN_PUBLIC). Do not submit humanized labels.
  Expected evidence: every enum field carries a member of its locked vocabulary.
  Machine fields: packet_manifest.packet_family, packet_manifest.validation_status, rights_passport.access_mode.
• AGENT_RETRIEVAL_DATES_PRESERVED required applies to: agent_prepared
  Preserve source URLs and retrieval / access dates for every source the agent fetched. These belong in the manifest sources[] entries or in the listing description.
  Expected evidence: manifest.sources[].url populated where the source is online; fetched-at date recorded in the citation or description.
  Machine fields: packet_manifest.sources[].url, packet_manifest.sources[].citation.
• AGENT_NO_VERIFICATION_CLAIM prohibited applies to: agent_prepared, seller_rights_claims
  Do not claim that Graunt verified the packet, that it is verified by Graunt, that it carries a Graunt quality guarantee, or that it is risk-free.
  Expected evidence: listing description avoids the phrasings above.
  Graunt evaluates packets and validates objective structure. It does not verify upstream rights, provenance, or fitness for use.
• AGENT_NO_INFERRED_RIGHTS prohibited applies to: agent_prepared
  Do not infer rights beyond the documentary evidence the agent collected. If the upstream license is unclear, surface that rather than picking the most-permissive plausible value.
  Expected evidence: license_family supported by an explicit citation.
  Machine fields: rights_block.license.family.
• AGENT_NO_FUTURE_LANE_CLAIMS prohibited applies to: agent_prepared
  Do not advertise capabilities Graunt has not shipped — autonomous agent purchasing, agent-held payment instruments, anonymous paid checkout, or any future commerce capability not yet listed as live in the current public API. These remain on the roadmap and are not part of the current public surface.
  Expected evidence: listing description references only currently-live acquisition modes; agent submission cites only capabilities listed in the OpenAPI document at the time of submission.

Requirement checklist

The minimum-for-review set is the floor. Stronger packet signals improve buyer evaluation but do not gate publication on their own. Prohibited claims must not appear in the listing copy.

Minimum for review

• RIGHTS_ORIGIN_DECLARED
• RIGHTS_LICENSE_FAMILY_DECLARED
• RIGHTS_SOURCE_DISCLOSURE
• PROVENANCE_SOURCE_LIST
• UPDATE_PATTERN_DECLARED
• FRESHNESS_DATE_DECLARED
• MANIFEST_HASHES_PRESENT
• MANIFEST_STRUCTURE_VALID
• MANIFEST_SOURCES_LISTED
• BUNDLE_ASSET_ROLES_VALID
• BUNDLE_PRIMARY_ASSET_PRESENT
• BUNDLE_SIZE_LIMITS_RESPECTED
• FORMAT_SUPPORTED
• FORMAT_DECLARED_EXTENSION_CONSISTENT
• AGENT_RAW_ENUM_SUBMISSION
• AGENT_RETRIEVAL_DATES_PRESERVED

Stronger packet signals

• PUBLICATION_METADATA_COMPLETE
• PUBLISHER_ROLE_DECLARED
• STANDARD_IDENTIFIERS_WHEN_APPLICABLE
• JURISDICTION_DECLARED_WHEN_APPLICABLE
• KNOWN_LIMITATIONS_DECLARED
• QUALITY_SIGNALS_DECLARED
• DATA_DICTIONARY_PROVIDED_WHEN_APPLICABLE
• TRANSFORMATION_LOG_PROVIDED_WHEN_APPLICABLE

Prohibited or high-risk claims

• Claims that Graunt verifies seller rights or provenance.
• Guarantees of fitness for any particular buyer use.
• Claims that downloaded artifacts are risk-free.
• Claims of full legal or regulatory compliance.
• Claims that Graunt enforces buyer behavior after download.
• Inferring an upstream license without explicit documentary evidence.
• Advertising future commerce capabilities not yet listed as live in the current public API (for example: autonomous agent purchasing, agent-held payment instruments, anonymous paid checkout).

Examples of strong vs inadequate evidence

Operational examples. These illustrate the contract; they are not legal advice.

Rights and provenance

• Strong: "Compiled by seller from the U.S. Office of Management and Budget federal AI use-case inventory; source is a U.S. federal government work, not subject to copyright; retrieval date 2026-03-14; source URL recorded in manifest.sources[0].url."
• Inadequate: "Found online; assumed open."

Known limitations

• Strong: "Covers federal civilian agencies 2024-01 through 2026-03; excludes DOD and intelligence community; missing fields: budget allocation, project cost basis."
• Inadequate: "No limitations."

Freshness

• Strong: "publication_metadata.last_reviewed_at = 2026-03-14T00:00:00Z; update pattern EDITIONED; next refresh planned at the OMB quarterly cadence."
• Inadequate: "Recent."

What Graunt does not promise

The acceptance contract is operational. It is not a warranty. Specifically:

• Graunt does not verify the upstream rights, ownership, or licensing of submitted material.
• Graunt does not certify the factual accuracy of any packet.
• Graunt does not represent that any packet is appropriate for any specific buyer use.
• Graunt does not control how downloaded artifacts are used after delivery.
• Graunt does not enforce buyer obligations (citation, retention, anti-redistribution) beyond recording them on the listing.
• Graunt is not a publisher, broker-dealer, investment adviser, law firm, medical provider, or tax professional, and nothing here constitutes legal, financial, medical, or tax advice.

Machine-readable surfaces

The same contract is available as a deterministic JSON API. The two surfaces are kept in sync by construction; the page renders the data the API publishes.

• /v1/meta/seller-standards — machine-readable acceptance contract (JSON).
• /llms.txt — LLM orientation manifest with pointers to both this page and the JSON contract.
• /openapi.json — full OpenAPI 3.1 document including the seller-standards operation under tag Public discovery.
• /agents — agent-facing descriptor of the broader machine surface.