# ZenoDivergent provider guide

Version: **zeno-provider-handoff/0.1.0 — proposed interchange contract**  
Prepared: **9 September 2026**

This is a specification to share with data, corpus and model providers. It describes what to collect, how to export it, and how the receiving team should preserve it. It is a new handoff proposal, not a claim that Zeno or Offdiagonal already accepts these JSON files directly. A reviewed adapter must translate it into the receiving system's versioned contract.

The accompanying kit contains JSON Schemas, a complete fictional example, a local validator and regression checks. It runs no models, contacts no external APIs, and authorizes no training. Every submission starts with `training_eligible: false`; a consumer-owned, separately versioned admission decision is required.

**1. What we are trying to learn**

Zeno studies the behaviour of predictive models: how their error, calibration, uncertainty and availability change across time, conditions, versions and related systems. A useful record lets us reconstruct:

> This exact model, using these available inputs, issued this prediction for this target; this outcome arrived later; these conditions and lifecycle changes were present.

The immediate supported research question is whether histories from other forecasting products improve reliability estimation when a held product has few adaptation labels. Current development results favour a simple pooled mean-reversion rule over richer peer features. A provider should help make this question measurable, without manufacturing peer diversity, uncertainty, interventions or earlier availability.

Useful later questions include forecast-error growth, loss of interval coverage, sustained degradation, recovery after a witnessed change, useful abstention and adaptation after a model upgrade. These require their own targets and evaluations. Collecting the evidence does not establish those capabilities.

Providers do not need to manufacture a “surprise” or “trust” score. Native predictions, outcomes, uncertainty and traceable conditions let the receiving team derive and compare candidate behavioural measures.

**2. What different providers can contribute**

| Provider capability | What to send | What it enables |
| --- | --- | --- |
| Operates predictive models | Predictions as emitted, exact model/version/run, input membership and clocks, later outcomes, failures and abstentions. | The strongest route to prospective behavioural evidence. |
| Archives other models' forecasts | Original forecast files/receipts, provider and gateway identities, issued/received/valid times, member IDs, original revisions and later references. | Historical comparisons with an explicit availability basis. |
| Owns measurements or labels only | Native observations/labels, units, spatial or subject support, acquisition/publication/receipt clocks, quality and revision history. | Outcome verification and contextual features. Predictions must come from another source. |
| Already has performance histories | Per-model/task/horizon window values, metric definition, sample counts, availability, constituent pairs or membership hashes, lifecycle/context. | Behavioural episodes; the evidence is weaker when the underlying pairs cannot be audited. |
| Owns model weights or an API | Versioned inference contract, preprocessing and normalization, input requirements, output semantics, reproducibility metadata and training-data lineage where available. | Producing a comparable forecast history; weights alone do not provide that history. |
| Owns contextual data | Weather, operating conditions, input quality, workload, geography, acquisition geometry, changes or outages, each with its own availability clock. | Testing which conditions explain shared or model-specific failures. |
| Has only a leaderboard or final evaluation score | Per-case outputs and dated references, if recoverable; otherwise the score's exact test population and method. | Limited benchmarking context. A single aggregate score is insufficient for temporal behavioural learning. |

Four export profiles are supported by the proposed schema:

- `forecast_outcome`: models, tasks, forecasts and outcomes.
- `forecasts_only`: models, tasks and forecasts; explicitly awaiting or lacking outcomes.
- `outcomes_only`: tasks and outcomes; a data-only contribution.
- `performance_history`: models, tasks and performance windows.

Run, input/context, score and lifecycle records enrich any compatible profile. An absence should be declared; do not invent substitute records to satisfy a richer profile.

**3. Which kinds of data matter**

| Evidence | Examples | Requirements |
| --- | --- | --- |
| Point predictions | Temperature, pollution, demand, machine temperature, expected delay. | Native quantity/unit, target support, emission time and eventual reference. |
| Probabilistic predictions | Probability of an event or class, quantiles, intervals, predictive samples or ensemble members. | Exact event/class vocabulary, nominal levels, native method and complete member identities. Preserve what the producer actually emitted. |
| Outcomes | Sensor observations, adjudicated labels, transactions reaching a defined state, verified events, later analysis products. | Source, target definition, availability, maturity/finality and revisions. Distinguish direct observations from modeled references. |
| Temporal performance | Signed error, absolute error, squared error, coverage, interval width and other declared losses over windows. | Same task/lead/metric definition, window boundaries, sample membership and clocks. |
| Input quality and context | Missing sensors, source latency, cloud cover, regime indicators, input distribution, geography, operating load. | Individual clocks and source references, including the provenance of any derived indicator. |
| Lifecycle and operations | Actual retraining, activation, rollback, routing changes, model version witnessed, source dependency failures, abstention. | Witness artifact, event type, time precision, affected model and evidence class. |
| Comparable models | Baselines, incumbents, independent forecasting systems, challengers already running. | Same target cases and eligible information; explicit upstream dependencies and version identities. |
| Failures and missing outcomes | Forecast job errors, empty responses, non-emission, censored/delayed truth, retired models. | Preserve the expected population and a reason. Missing evidence is not zero. |

Start with naturally occurring predictions and outcomes already available in a provider's workflow. There is no need to launch new paid training to instrument these records.

Weather, air quality and other physical forecasting data are immediately relevant to the existing research. Classification, LLM judgements, manufacturing, demand and other domains are potential additional corpora; each needs an adapter, a task-specific reference and independent qualification. An LLM judge is a versioned measurement process, not automatically objective truth. Structured outputs such as images or segmentation masks can use content-addressed artifact references and task-specific evaluators.

For earth-observation data, retain acquisition and publication/receipt times separately; scene/collection/processing version; footprint, grid and resolution; quality masks; and joins to the forecasted target. A later reanalysis or reprocessed satellite scene must not silently become an earlier feature.

**4. Keep these identities separate**

| Identity | Meaning |
| --- | --- |
| Provider | The organization/service exporting the evidence. |
| Upstream producer and lineage | The forecasting system or shared ancestry behind the output. |
| Logical model | A stable forecasting product or procedure. |
| Model version | A particular artifact, configuration or witnessed producer version. |
| Run | One execution or provider issuance; receipt-derived run IDs must be identified as derived. |
| Task version | A fixed target, unit, aggregation, reference and matching policy. |
| Entity/subject | Station, region, machine, account, prompt/task instance or other supported unit. |
| Case | A particular target opportunity shared by comparable forecasts. |
| Record | An immutable item or revision in the exchange. |

Use namespaced stable IDs. The model registry includes `model_id`, `model_version`, `lineage_id`, `dependency_refs` and optional artifact/training-data references. Every forecast points to its exact `model_record_id`, not a mutable “latest” alias.

A case ID should not encode the winning model or outcome vintage. Multiple models can predict the same case, and one outcome can verify several predictions. Lead time and decision cutoff must still be matched before comparing forecasts for that case.

Multiple locations, horizons, wrappers or aliases do not establish multiple independent models. Versions can remain strongly dependent. An ensemble member is not automatically an independent model. Provider or algorithm-family labels alone do not establish independence either.

Preserve shared-input and shared-training ancestry. Do not declare a gateway's `best_match` composite to be IFS, GFS or another named model unless the actual underlying identity is supported. Unknown identity/version is an explicit null or unknown state.

If independently collected case/entity IDs need reconciliation, provide a versioned mapping with its method, confidence and limitations. Do not silently match records by row position or nearest timestamp.

**5. Freeze each task definition before comparing models**

The task registry must specify:

- Domain and quantity; numeric, count, binary, categorical or structured target.
- Native unit, class vocabulary or artifact/output semantics.
- Target aggregation: instantaneous value, interval mean/sum/count, event, label or structured target.
- Entity namespace and spatial/subject support: point, station, grid, polygon, ward, machine or task instance.
- Expected issue cadence where known.
- Outcome source, quality, maturity/finality and revision policy.
- Matching rules, including temporal tolerance, spatial mapping, missingness and exclusions.
- The baseline policy and the conditions under which forecasts are comparable.

Changing the outcome source, task support, horizon semantics, aggregation or scoring definition creates a new task/metric version. It does not rewrite earlier measurements.

A station observation, a spatially weighted ward estimate and an analysis-grid value are different references. A daily mean cannot verify an hourly maximum. Training and scoring must use the same declared unit and reference policy. Probabilities require a fully specified event threshold and interval.

The schema deliberately separates a task from its per-case target interval. `target.start_at == target.end_at` represents an instantaneous target. Otherwise use a declared interval convention, recommended [start, end). Store actual timestamps; derive lead from timestamps and the declared origin, never an array index. Distinguish the forecasting model's native lead from Zeno's future-reliability horizon.

**6. Record time honestly**

Use explicitly UTC RFC 3339 timestamps, such as `2026-09-01T06:02:00Z`. Preserve original provider timestamp text/timezone and precision in the referenced source artifact when needed. Do not truncate times to hours merely to simplify joins. The reference validator accepts seconds and up to six fractional digits; preserve higher source precision and use an agreed adapter when finer timing matters. [RFC 3339](https://www.rfc-editor.org/info/rfc3339/)

Every record has an `availability` object:

| Field | Meaning |
| --- | --- |
| `known_at` | When this record's value was available to the named actor, under the stated basis. Null when unknown. |
| `basis` | `observed`, `source_supported`, `derived_rule`, `assumed` or `unknown`. |
| `actor` | Whose information set the clock describes: producer, provider pipeline, Offdiagonal or Zeno. |
| `witness_ref` | Evidence for a supported clock: receipt, log, archive, commit or other source artifact. |
| `assumption_id` | A versioned derivation/lag rule in the manifest when the clock is derived or assumed. |

These describe availability, not whether a value itself is a direct physical measurement. A derived score can have an observed computation clock. A real sensor value can still have only assumed historical availability.

Keep the other clocks separate:

- `recorded_at`: when this particular record was recorded.
- `decision_at`: when the forecast's input set was fixed, if supported.
- `issued_at`: the producer's declared issuance, if known.
- Target or input valid times: when the quantity refers to the world.
- Run start/completion and actual first forecast receipt.
- Outcome `first_available_at`: first availability of the original outcome; each revision has its own current `availability.known_at`.
- Metric `computed_at`: when that score or window was produced.
- Event `witnessed_at` and occurrence bounds.
- Snapshot creation and outcome-as-of times.

Do not copy a nominal model initialization time into a receipt clock. Do not replace missing publication clocks with the export time and then claim historical availability. A verified historical receipt can support an old clock; a newly generated backfill cannot manufacture one.

Origins are independently classified as `live_capture`, `archived_receipt`, `historical_replay` or `synthetic`. A newly received replay remains replay. A source-supported publication clock does not prove that a downstream consumer had received the record at that time.

Derived and assumed clocks remain separate populations. They may support an explicitly assumption-based development analysis; they do not establish prospective availability. A nonnull timestamp must never promote a weak basis into observed evidence during adapter translation.

**7. Four timing rules for every receiving pipeline**

| Use | Required boundary |
| --- | --- |
| Forecast or Zeno features | Every constituent value must be available to the relevant actor by that prediction's decision cutoff. |
| Adaptation support | The support label must have matured by adaptation time, including label construction dependencies. |
| Fitted statistics | Every fitting record must satisfy the fit cutoff and allowed product/task population. |
| Evaluation query labels | They may arrive later; preserve maturity/revision rules and exclude them from earlier features, fitting and adaptation. |

A closed performance window is eligible only when its end is at or before the decision and its constituent outcomes and chosen computation/availability rule allow it to be used.

First construct the entire eligible history. Then select the newest admitted window by window end and compute lags, averages, standard deviations and peer changes from admitted points only. Do not select by latest arrival; do not admit an unavailable older value through a mean.

Example: at a decision, values 1 and 3 are available while an intermediate value 100 arrives later. The eligible mean is 2 and the one-step change between available windows is 2. Preserve missing expected lags and elapsed time; “previous eligible window” need not mean a fixed number of hours ago.

Delayed outcomes are not negative events. Pending labels and censored follow-up remain marked. If a positive event becomes ascertainable before its full window ends, record the task-specific maturity rule; there is no universal maturity lag for all targets.

Providers must export enough clocks and memberships for these checks. Offdiagonal/Zeno enforce the experiment's admission rules without silently substituting an easier population.

**8. Required core records and optional enrichment**

| JSONL record type | Required content beyond the common envelope |
| --- | --- |
| `model` | Stable model/version, name/family, lineage, role, dependencies; artifact/training references and cutoffs when known. |
| `task` | The complete versioned task definition described above. |
| `forecast` | Exact model/task/entity/case, run reference if known, decision/issue/target clocks, prediction kind, emission state, native output, input membership and quality flags. |
| `outcome` | Same task/entity/case/target, native value or artifact, unit/source, first and revision availability, status, reference kind and maturity. |
| `input` | One feature/context value with its own clock, valid interval, evidence type, raw/canonical value and unit, transformation/fit references and constituent inputs. |
| `run` | Exact model, configuration reference, start/completion, input cutoff/membership and status. |
| `score` | Exact forecast and outcome revision, metric/version/parameters, value, computation time and optional normalizer reference. |
| `performance_window` | Model/task/entity/lead, window, metric/value, computation and availability, denominators, score membership and verification level. |
| `event` | Model, event type, witness, occurrence bounds/precision, evidence class, before/after versions, dependency and detection rule where applicable. |

Input/context valid windows may be null when unknown or inapplicable to static metadata; retain the availability clock and state that limitation. Numeric expected-count predictions may be fractional, while an observed count remains an integer.

Every record also carries an immutable `record_id`, `provider_id`, `recorded_at`, `origin`, `availability`, `source_refs` and nullable `supersedes_record_id`.

Core foreign keys must resolve inside a self-contained submission. Raw artifacts, transformations, training manifests and external membership lists may use references with hashes and controlled access. Document their resolver and availability. The reference validator does not fetch external sources.

The optional `extensions` object supports provider metadata, but its contents are not automatically model features. Any value consumed as a feature must gain an explicit typed definition, clock and provenance in an adapter version.

For maximum value, archive the exact production feature vector or input membership. Large feature arrays or raw imagery can live in hashed artifacts rather than being copied into each JSON row. Proprietary inputs can use stable pseudonymous record IDs and an auditable provider-side resolver; disclose the resulting reproducibility limit.

**9. Predictions, probabilities and ensemble members**

A prediction payload has explicit slots:

- `point`: native scalar/class prediction, or null.
- `quantiles`: an array of level/value pairs.
- `intervals`: nominal level, lower/upper and method.
- `probabilities`: the complete class vocabulary and probabilities summing to one.
- `members`: stable member ID plus value, including explicit nulls.
- `artifact_ref`: structured output reference where applicable.

Use empty arrays for output types the producer did not emit. A point prediction does not imply an uncertainty interval. A heuristic confidence badge is not a calibrated probability. Interval coverage is measured later and belongs to score/performance records.

Quantile levels must be explicit and values nondecreasing. Intervals must have ordered endpoints. Preserve whether uncertainty is a native distribution, ensemble, calibrated postprocessing or heuristic. If several uncertainty types coexist, record the relationships and method versions.

Preserve member identity across times, variables and missing values. Aggregate a member's complete trajectory over the required target window before taking ensemble percentiles. Do not compact missing members into a shorter array and then join days by position.

An abstention or failed forecast has `prediction: null` and an explicit reason. A missing scheduled emission must be supported by the expected schedule and a declared detection/grace rule. Save failures, unscored forecasts, retired models and cold starts so their absence cannot bias the training population.

**10. Native data, normalization and fusion**

Preserve native values first. Keep any canonical conversion alongside its raw input, original unit, formula/version, and spatial/temporal mapping. Missing is null with a state or quality flag; zero remains a legitimate observed or predicted value.

For deterministic unit conversion, publish the conversion and required conditions. For example, gas concentration conversions may require temperature and pressure; do not apply a generic scaling constant without the physical assumptions.

For learned normalization or scaling, the referenced processing manifest must contain:

| Field | Purpose |
| --- | --- |
| Transformation ID/version and formula | Reproduce the mapping and its inverse where possible. |
| Source/input membership or hashed partition references | Establish which values influenced the transform. |
| Fitting cutoff and availability rule | Exclude future information. |
| Included/excluded models, tasks and entities | Enforce held-product restrictions separately from time restrictions. |
| Parameters and native/output units | Recompute values without fitting again. |
| Missing/outlier/clipping policy | Explain what was rejected or censored and count it. |

Do not fit a scaler across the entire corpus before creating evaluation folds. Do not derive a held-product scale from its query outcomes. Define denominator-zero handling before calculating relative skill; an arbitrary epsilon must not silently redefine a metric.

For fusion, retain each source value, uncertainty, availability, selected weight and dependency group, plus the fused output and algorithm version. This makes it possible to compare self-history, shared context, aggregates and individual sources with matched information.

Correlated wrappers of the same upstream source do not earn independent votes. Preserve enough unfused data to investigate shared error. Cleaning should retain a raw audit path and rejection reasons, especially for extreme values that may be the behaviour of interest.

**11. Outcomes and revisions**

An outcome is independently recorded when its source delivers it; it need not already have a matching forecast. Preserve initial, corrected, finalized and withdrawn versions with stable revision links.

The same initial outcome may score several models. Later outcome revisions can generate new score versions without overwriting original scores. The task determines whether evaluation uses first complete truth, a fixed maturity vintage, or finalized truth.

Do not claim every reference is physical ground truth. Declare `reference_kind`:

- `observation`: a measurement with its quality and support.
- `analysis` or `reanalysis`: a modeled reference product.
- `human_label`: with rubric, annotator/adjudication or judge version and revision process.
- `derived_indicator`: a reproducible transformation.
- `simulation`: a simulated reference.

Keep forecast, reference and downstream reliability targets distinct. A model predicting SST can be scored against a NOAA product, while a later Zeno task predicts changes in that model's SST error. Those are different horizons and different labels.

Track label delay, missingness and censoring. Export the expected denominator. If difficult situations have fewer labels, expose that pattern; do not retain only cases that were easy to score.

**12. Performance-history providers**

If only aggregate histories can be shared, provide one row per model/version/task/entity/lead/metric/window. The row must include its metric value, window boundaries, computation/availability, clock basis and counts:

`n_expected`, `n_emitted`, `n_matched`, `n_distinct_outcomes`.

Use null for an unknown expected denominator. Provide exact score IDs or a hashed membership file whenever possible. Record the metric's aggregation and weights. The starter full-pair profile assumes one atomic score per matched prediction for the metric; use an explicit richer adapter for other aggregation structures.

Declare one verification level:

| Level | Meaning |
| --- | --- |
| `full_pairs` | Forecasts, outcome vintages and scores are available and linked. |
| `external_membership` | Exact constituents are referenced and can be audited externally. |
| `aggregate_only` | Underlying membership cannot be independently recomputed. |

Aggregate-only histories may be useful for exploration. Their limitations must survive import, reporting and claims. They cannot establish equivalent evidence to a matched, clock-supported raw corpus.

Useful metrics include MAE, RMSE, signed bias, appropriate quantile/interval scores, native interval coverage/width, Brier/log scores for specified probabilistic events, and explicit abstention/availability rates. Supply metric definitions and denominators, not just names.

For Zeno, preserve the trajectory of each metric, its sampling uncertainty, sample size, reference age and context. Let the consumer freeze how future change is defined. Do not send only “health=87” or “failure probability=0.2” without the underlying measurement and definition.

**13. Lifecycle and operational evidence**

Emit events from actual job, artifact and routing boundaries wherever possible: training started/completed/failed; activation; rollback; input configuration change; witnessed version transition; explicit abstention; dependency failure or recovery.

Keep `evidence_class` (observed or inferred) separate from `time_precision` (exact, interval or unknown). A version transition may be witnessed but only bounded between receipts. An inferred change in an error curve remains inferred. “The model retrained” requires actual job/artifact evidence.

Do not attach a source outage to a model unless its dependencies establish the connection. A seasonal route switching to an existing artifact is different from new training. Planned changes are announcements until their execution is witnessed.

If human operators or Zeno recommendations influence model selection, inputs or interventions, record the acting policy and decision context. Before/after performance by itself does not establish the intervention's causal effect.

**14. How to package and deliver data**

Preferred first handoff: a directory or archive with `manifest.json`, `manifest.sha256` and UTF-8 JSONL files. Each JSONL line is one complete typed record. The kit's example demonstrates all nine record types; a minimal raw export needs only the four core types.

For larger exports, partition by record type and date and use NDJSON with compression or Parquet with the same logical schema. The supplied reference validator handles uncompressed JSONL; production compression/Parquet readers need their own checked adapter. Preserve precision, nulls, arrays and UTC types.

The manifest records:

- Immutable snapshot ID, provider, creation time and profile.
- Collection decision bounds and outcome-as-of time.
- Role: collection, development, reserved evaluation or example.
- Training and redistribution permissions, attribution and license/reference.
- Prior use/exposure declarations and any evaluation reservation.
- Availability assumptions and processing references.
- Every part's relative path, record type, row count, byte count and SHA-256.
- `training_eligible: false` and `eligibility_status: requires_consumer_review`.

Hash the exact bytes delivered, including whitespace/newlines and compression. Hash the finished manifest in a detached `manifest.sha256`; do not include that checksum inside the bytes it hashes. A hash establishes byte integrity, not truthfulness or historical publication time.

APIs are equally acceptable when they expose stable model/task identities, immutable revisions and downloadable snapshots. Reuse existing endpoints where possible. Needed capabilities are model/task discovery; incremental forecasts/outcomes/events; context and membership retrieval; and snapshot/manifest/part downloads.

Pagination must be bound to a stable snapshot or safe committed export sequence. Include a high-water mark and opaque continuation cursor, support retries without duplicates, and retain revisions. A database ID allocated before commit is not automatically a safe replication cursor.

Keep authentication and expiring signed links separate from the public data manifest. Share only authorized data; use stable pseudonymous identifiers where personal identity is unnecessary. Declare restrictions and redact consistently so joins remain possible. Model weights and private inputs are optional when a provider can instead supply adequate output/provenance evidence.

**15. Model providers: what makes inference reproducible**

In addition to the data records, supply a model package or model/API card with:

| Item | Required detail when available |
| --- | --- |
| Identity | Model name, exact version, artifact digest, upstream/base model and adaptation lineage. |
| Inputs | Feature names/order/types, units, missingness handling, context length, time cutoff and valid-time semantics. |
| Preprocessing | Tokenizer/encoder, normalization parameters, source mappings and configuration versions. |
| Outputs | Point/distribution/quantile/member semantics; target units, horizon and calibration version. |
| Execution | Entrypoint or API version, dependency lock/container digest, supported device, seeds and tolerances where nondeterminism exists. |
| Training provenance | Dataset/snapshot versions, training cutoff, task population and known overlap; unknown/proprietary fields clearly declared. |
| Example | Small authorized input and expected output/tolerance for a smoke check. |
| Operations | Actual selected version, latency, failure/fallback states and relevant resource/cost measurements if shareable. |

An API-only provider should preserve each normal request's model/version and response receipt, not replay old requests against a newer model and label those responses as historical predictions. A reproducible retrospective run is still retrospective unless original forecast receipts support a prospective claim.

Raw weights are not mandatory. An inference package without dated model behaviour also cannot substitute for a behavioural corpus.

**16. Receiving-team admission and quality report**

Separate the following statuses: schema-valid, references-resolved, timing-supported, task-compatible, evidence-auditable, permissions-confirmed and eligible for a named experiment. None implies the next automatically.

The receiving team should publish a census with both inventory and eligible counts, grouped by product, version, lineage, task, horizon and calendar period:

- Models, versions, task series and actual contributing lineages.
- Unique forecast opportunities, forecast records and underlying outcome cases/vintages.
- Shared calendar days, lineage-days and overlap; avoid calling these automatically independent days.
- Clock basis and origin counts, including zero measured/supported counts if applicable.
- Missing/late labels, exclusions by reason, cold starts and duplicate/suspected-ancestry groups.
- Expected/emitted/matched coverage, including model failures and retirement.
- Availability lag distributions and revision rates.
- Permitted uses, exposure history and the exact gate/version applied.

Keep excluded records and reasons available for audit. Reject conflicting IDs, corrupted parts, ambiguous task joins or admitted post-cutoff information. Preserve unknown evidence states; do not silently drop them and describe the remainder as complete.

Providers should deliver a small sample first for contract validation, then immutable full parts. The practical first milestone is an auditable forecast recorded before its target, followed later by an outcome, then a reproducible performance window. Add duration, independent lineages and conditions after that path works.

There is no universal row-count threshold for useful training. A million overlapping rows from two lineages over a few days can still be thin evidence. Corpus diversity and effective temporal coverage must be evaluated against the intended experiment.

**17. Special case: the currently registered later weather evaluation**

These conditions belong to the specific Zeno registration reviewed on 9 September 2026, not to all future providers:

- Decision rows strictly after 2026-09-05T12:00Z.
- Compatible tasks from the registered weather products; at least five held products, twenty distinct calendar decision days and forty query rows per fold after exclusions.
- A collection endpoint fixed before scoring, explicit label maturity and written untouched-outcome declarations required by that registration.
- The required hashes/importer and pinned feature/target/timing versions.
- The original restricted panel remains verification context and training-ineligible.

The exact cohort, adaptation/fitting cutoffs, lineage treatment, interval convention and evaluator must be pinned by the receiving team. A new snapshot name or different provider does not automatically satisfy the registration. Do not merge new domains or a Notflat pilot into that test without a separately declared study.

Provider structural validation and schema fixtures are not training authorization. This guide creates no permission to open sealed evaluations, launch paid jobs or promote a model.

**18. Local validation and acceptance checks**

After unpacking the kit, use Python 3.10 or newer:

```bash
python -m venv .venv
. .venv/bin/activate
python -m pip install -r requirements.txt
python validate_bundle.py examples/minimal-weather
python -m unittest discover -s tests -v
```

For a provider bundle:

```bash
python validate_bundle.py /absolute/path/to/export --report validation-report.json
```

The example is wholly fictional and tagged `synthetic` with assumed clocks and prohibited training use. It is a schema fixture, not training data.

The validator checks JSON Schemas, exact manifest/part hashes and counts, ID uniqueness, core foreign keys, selected chronology and input-cutoff rules, revision links, target/unit matching, probability/quantile/member validity, coverage counts and selected atomic error formulas. It does not authenticate witnesses, prove independence, verify permissions, recompute every scoring rule or qualify an experiment. It loads the export into memory; use a bounded streaming implementation for large archives.

Consumer adapters need additional conformance fixtures for:
late-arriving intermediate and older values; future support labels; fitted scales spanning future/held-product records; outcome revisions after cutoff; irregular history gaps; mismatched target support; missing ensemble members across time; gateway aliases sharing ancestry; paginated retries and out-of-order transaction commits; unscored predictions near pruning; and permanently missing outcomes.

For protected later evaluations, the receiving team must define which automated checks are allowed without exposing outcomes to model selection. Do not certify untouched status if it cannot be supported.

**19. Practical request to send a provider**

Please start by exporting one well-defined prediction task with its existing models and an appropriate baseline. Preserve every scheduled prediction or explicit non-emission, the actual model/version, inputs and receipt clocks, and all later outcome vintages. Keep native values and uncertainty; include source identity, quality, lineage and any witnessed lifecycle changes. Provide a manifest with immutable IDs, hashes, counts, timing assumptions, permissions and prior exposure. If original clocks or raw pairs are unavailable, declare that limitation rather than reconstructing stronger evidence. Send a small schema sample, then freeze the full export once its mapping is agreed.

The objective is to learn how models behave from evidence that can be traced through time. Honest partial evidence is useful; unsupported completeness makes the resulting model harder to trust.

**Source and compatibility notes**

The proposal is informed by the project and provider audits in this conversation and by these repository contracts, pinned to [revision abc5998d03edbc363af06571e27d4268e4f5e9b1](https://github.com/mbarbosa30/zenodivergent/tree/abc5998d03edbc363af06571e27d4268e4f5e9b1):

- [Model-behaviour ledger types](https://github.com/mbarbosa30/zenodivergent/blob/abc5998d03edbc363af06571e27d4268e4f5e9b1/model/campaign/model_behaviour_contract.py).
- [Eligible-history feature construction](https://github.com/mbarbosa30/zenodivergent/blob/abc5998d03edbc363af06571e27d4268e4f5e9b1/model/campaign/mbv2_features.py).
- [Target definition](https://github.com/mbarbosa30/zenodivergent/blob/abc5998d03edbc363af06571e27d4268e4f5e9b1/model/campaign/mbv2_target.py).
- [Later-evaluation addendum](https://github.com/mbarbosa30/zenodivergent/blob/abc5998d03edbc363af06571e27d4268e4f5e9b1/model/artifacts/mbv2/PREREGISTRATION-ADDENDUM-2026-09-09.json).

The existing typed ledger uses different field names, including `modelId`, `forecastEventId`, `targetContractId`, `nativeValue` and nested provenance. This kit's snake_case records require an adapter. That adapter must preserve origin, clock strength, task identity, revision lineage and dependency membership; the presence of a timestamp alone is not sufficient evidence.

Schemas use [JSON Schema Draft 2020-12](https://json-schema.org/draft/2020-12). Time strings use the UTC subset of [RFC 3339](https://www.rfc-editor.org/info/rfc3339/). These standards describe representation; Zeno's scientific eligibility rules remain separately versioned.