Draft public contracts
How reviewed observations could become versioned public records and releases.
A public record
The proposed envelope separates the scheme and its revision, a produced value or an explicit unavailable result, source attribution, an observation period, and any evidence-backed software claims.
| Field | Meaning |
|---|---|
schema_version | The separately versioned public record contract. |
record_id | A stable SHA-256 identity from the scheme, result, and source reference. Labels and dates do not change it. |
scheme | Scheme ID and revision. Draft-1 admits only tls.ja3@1 and tls.mercury@1. |
result | Exactly one named scheme output, or an unavailable reason. No invented value. |
source | A source category and a public-safe reference. |
observation_period | The inclusive date range represented by the record. |
software_associations | Optional software/version claims with reported, supported, or disputed status and supporting evidence references. |
The selected produced projections are a five-field decimal/list string named ja3 and a 24-character lowercase hex digest named mercury. Unknown schemes, revisions, extra outputs, and mismatched names are rejected. This is not privacy or license certification; other schemes need their own safe projection review.
What stays private
Canonical inputs are excluded entirely from this draft. There is no generic metadata escape. Unknown fields are rejected at every object level. Endpoints, private session identifiers, request identities, and unreviewed capture enrichment do not belong in this envelope.
Aggregation and uncertainty
Repeated records with the same scheme, result, and source reference share an identity. Their dates can be merged and identical claims deduplicated. Distinct sources remain distinct records. Conflicting software claims remain visible; a shared value does not prove a shared application.
The proposed release count is the number of unique public record IDs, including unavailable results. It is not a packet count or application count.
A release manifest
A manifest will name the dataset and immutable release version, record-schema version, collection and publication dates, sources, count and counting rule, artifact formats and HTTPS URLs, byte sizes, SHA-256 checksums, applicable terms, and change notes.
The build checks the release catalog. Draft versions, synthetic fixtures, and unadopted terms cannot enter it. Artifact integrity, source permission, and legal adoption need separate release review; a valid manifest alone does not prove them.
From private captures to releases
A planned offline publisher will validate private captures, apply a positive publication allowlist, review software claims and permissions, aggregate records, produce exports, and verify real counts and checksums. It is not implemented. The static website reads only reviewed metadata and does not ingest private captures.
Capture notes were inspected at source revision 38c9628c3c3d2f19e83dcb6bcf9790f158c5ff7f on 14 October 2026. Relevant files were clean despite unrelated changes in that checkout. These notes are not public package or deployment qualification.
Read scheme compatibility limits and the licensing work still required.