provider handoff
Ask for the record, not the score.
Zeno learns how models behave across time, conditions and model families. That needs versioned predictions as they were actually emitted, the outcomes that arrived later, and enough provenance to reconstruct exactly what was available at each decision. A health index or a trust badge cannot be reconstructed backwards into that record.
status
zeno-provider-handoff/0.1.0 · proposed interchange contract · 9 September 2026
This is a proposal to share with data, corpus and model providers — not a claim that Zeno or Offdiagonal already accepts these JSON files directly. Corpus API v1 remains the live ingestion contract; a reviewed adapter must translate this handoff into the versioned model-behaviour ledger, preserving origin, clock strength, task identity, revision lineage and dependency membership. Every submission starts training_eligible: false. Structural validation is not training authorization, and nothing here opens a sealed evaluation or authorises a training run.
Collection, structure, timing, normalization, packaging, API and acceptance instructions — the full specification to hand to a provider.
download ↓
JSON Schemas for all nine record types, a complete fictional export, a local validator and 12 passing regression checks. Runs no models, contacts no APIs.
download ↓
contract zeno-provider-handoff/0.1.0 · proposed interchange contract · prepared 9 September 2026 · schemas JSON Schema Draft 2020-12 · timestamps RFC 3339, UTC subset
what to send
Providers contribute different kinds of evidence
Not every provider has models, weights and labels together. Declare an absence rather than inventing substitute records to satisfy a richer profile.
Predictions as originally emitted, exact model/version/run, input membership and clocks, later outcomes, failures and abstentions.
The strongest route to prospective behavioural evidence.
Original forecast files or receipts, provider and gateway identities, issue/receipt/target times, member IDs, revisions and later references.
Historical comparisons with an explicit availability basis.
Native observations, units, spatial or subject support, acquisition/publication/receipt clocks, quality and revision history.
Outcome verification and contextual features. Predictions must come from another source.
Per-model, per-task, per-horizon window values with metric definitions, sample counts, availability and constituent pairs or membership hashes.
Behavioural episodes — weaker evidence when the underlying pairs cannot be audited.
Operating conditions, input quality, missingness, source latency, workload, geography and outages, each with its own availability clock.
Testing which conditions explain shared or model-specific failures.
Versioned inference contract, preprocessing, output semantics, dependencies and reproducible examples.
A comparable forecast history. Weights alone do not provide one; dated outputs stay necessary.
structure
Immutable records with explicit links
Nine record types. A complete raw contribution uses the four marked core; predictions-only, outcomes-only and performance-history exports are also supported. Every record carries an immutable ID, provider, provenance, availability basis and revision link. A case ID identifies the target opportunity shared by comparable models — it never encodes the winning model or the outcome vintage.
identity
Four distinctions that must stay explicit
timing
The most consequential requirement
UTC timestamps at source precision, one clock per meaning, and four separate admission rules. Apply the checks to every historical constituent before computing averages, lags or peer changes — not just to the latest point.
Every availability clock also declares its basis — observed, source_supported, derived_rule, assumed, unknown — and whose information access it describes. A non-null timestamp never promotes a weak basis into observed evidence.
the 1 / 100 / 3 case
At a decision, values 1 and 3 are available while an intermediate value of 100 arrives later. The eligible average is 2, and the one-step change between available windows is 2. Build the whole eligible history first, then take the newest admitted window by window end — never by latest arrival, never carried forward.
Historical replay is useful when it is labelled honestly. A newly generated backfill cannot establish that a downstream system received the information earlier, and a source-supported publication clock does not prove a consumer had received it. Origins stay classified as live capture, archived receipt, historical replay or synthetic.
native data
Preserve the record before normalization or fusion
Future exclusion and held-model exclusion must be independently enforceable. A scaler fitted across the whole archive violates both.
- Original values, units, quality flags and missingness — zero is a real value, missing is null with a state.
- Conversion formulas, required physical conditions and processing versions.
- Each source's value before fusion, with weights and shared dependency groups.
- Normalizer parameters, fitting cutoff and fitting membership — never a scaler fitted across the whole archive.
- Clipping, rejection and imputation rules, with affected counts.
- Stable ensemble-member identities across time, including explicitly missing members.
- Emitted probabilities, quantile levels, intervals or members — a confidence badge is not a calibrated probability.
Preserve cold starts, retired models, difficult cases and missing outcomes. Missing evidence is not zero, and a delayed label is not a negative event — dropping them lets successful cases dominate the corpus.
priorities
What would make the next experiment informative
The current development result favours a simple pooled mean-reversion rule over richer peer features. That rule is now the benchmark any added architecture has to beat, so the evidence that moves the question forward is specific.
Supported availability clocks
Observed or source-supported, not assumed. Assumed clocks support development analysis only.
Genuinely different lineages
Independent ancestry, not more stations, leads, wrappers or aliases of one upstream system.
Longer temporal coverage
Eligible calendar days and lineage-days matter more than row counts.
Comparable target cases
Shared case IDs under one frozen task definition, with matched decision cutoffs.
A new provider or a new snapshot does not qualify the registered later weather evaluation. Its cohort, cutoffs, held products, decision-day count and untouched-outcome declarations remain governed by the dated registration addendum of 9 September 2026, and any new domain needs a separately declared study.
delivery
A versioned snapshot first, then incremental updates
UTF-8 JSONL parts, one complete typed record per line, plus a manifest and a detached manifest.sha256. Corrections append new versions linked to earlier records; large archives can use Parquet through an agreed adapter preserving the same semantics.
the manifest records
- · Immutable snapshot ID, provider, creation time, schema and profile versions.
- · Collection decision bounds and outcome-as-of time.
- · Role: collection, development, reserved evaluation or example.
- · Every part's path, record type, row count, byte count and SHA-256.
- · Clock assumptions and processing references.
- · Permitted uses, redistribution, attribution and prior evaluation exposure.
- · `training_eligible: false` and `eligibility_status: requires_consumer_review`.
APIs are equally acceptable when they expose stable IDs, immutable revisions, snapshot-bound pagination, resumable cursors and downloadable manifests. A hash establishes byte integrity — never truthfulness or historical publication time.
onboarding sequence
- 1. Select one precisely defined task and existing model outputs.
- 2. Export a small sample with matching outcomes and clocks.
- 3. Agree on identity, task, timing and revision mappings.
- 4. Validate the sample and report unresolved evidence.
- 5. Begin prospective receipt capture immediately.
- 6. Deliver immutable snapshots with both inventory and eligible counts.
Report eligible lineages, calendar days, task coverage and distinct outcome cases alongside row counts. There is no universal number of rows that makes a corpus sufficient.
limits
Three checks that never imply one another
Schema validity, permission to use the data and eligibility for a particular experiment are separate. The supplied validator checks structural integrity, exact hashes and counts, ID uniqueness, core foreign keys and selected timing, joining and scoring rules. It does not authenticate witnesses, prove independence, verify permissions or qualify an experiment. Scientific acceptance still requires assessing the evidence behind the records — honest partial evidence is useful; unsupported completeness makes the resulting model harder to trust.