Data

Data pages describe public structures used by PunchCard Labs: schemas, metrics, and future aggregate publications. This area should make machine-readable records predictable before large datasets exist.

The data surface is not a dumping ground. Any public dataset should have provenance, schema, update cadence, privacy review, and correction process. If those controls are not available, the data should not be published.

SchemasPublic JSON schemas for advisories, reports, tools, and metadata.MetricsReserved metrics surface for aggregate, non-sensitive publication data.PublicationsFuture downloadable datasets and aggregate records.

Publication Standard

Data should be useful without requiring private context. Every dataset needs fields, definitions, limitations, and a contact path for corrections.

A publication standard keeps the absence of records distinct from a broken route. If no public artifact exists yet, the page should say so directly, identify what will appear here later, and point users to the nearest useful policy or contact path.

Data Standard

Data pages should make schema, provenance, update cadence, and limitations visible. Aggregate data is useful only when consumers can determine how it was produced and what conclusions it cannot support.

Data entries should name the schema, source boundary, update cadence, and correction path before they are treated as citable. If those fields are not available, the data should stay unpublished rather than appear as an informal dump.

Data Catalog

The data catalog identifies the record families that will eventually make the data section useful: advisory indexes, report indexes, schema registry entries, tool metadata, and aggregate metrics. The catalog exists before the datasets because data should not be published as an informal dump. It needs schema, provenance, cadence, exclusions, and correction rules.

Data CatalogPlanned public datasets, schemas, metrics, and correction paths.SchemasPublic contracts for records and validators.