Quickstart

Say your tool exports a vendor spend table and you want the next tool along to know exactly what its return figures mean. This page takes you from nothing to a document that validates, in four steps.

1. Fetch the schemas

Download two files from this site’s schema mirror:

• estimand.json: the seven-field estimand that every exchanged number carries (section 5).
• model-manifest.json: the manifest that describes a model of any tier (section 7).

The schema index lists every published file. Inside each file, $id names the schema (for example https://schemas.ump.dev/v1/estimand.json). It is an identifier, not a download address, so validate against your local copies.

2. Write a minimal document

Start from the estimand in section 5. It describes a 30% cut on a set of geos, measured against the current plan over a 6-week window, as incremental revenue per US dollar of net spend, reported as a posterior median with a 90% HDI. Save it as my-estimand.json:

{
  "intervention": { "type": "scale", "size": -0.30, "arms": ["down"], "population": "geo_set" },
  "baseline": "current_plan",
  "horizon": { "type": "window", "weeks": 6 },
  "unit": { "kpi": "incremental_revenue", "per": "spend", "currency": "USD", "cost_basis": "net" },
  "point_rule": "posterior_median",
  "interval": { "method": "hdi", "level": 0.90 },
  "schema_version": "est-registry/1.2.0"
}

Then wrap it in the smallest model manifest that validates: a name, a tier (here C, a spend table) and an engine. Save it as my-manifest.json:

{
  "name": "northwind-reels-spend-table",
  "tier": "C",
  "engine": "vendor:example",
  "estimands": {
    "reels_cut_return": {
      "intervention": { "type": "scale", "size": -0.30, "arms": ["down"], "population": "geo_set" },
      "baseline": "current_plan",
      "horizon": { "type": "window", "weeks": 6 },
      "unit": { "kpi": "incremental_revenue", "per": "spend", "currency": "USD", "cost_basis": "net" },
      "point_rule": "posterior_median",
      "interval": { "method": "hdi", "level": 0.90 },
      "schema_version": "est-registry/1.2.0"
    }
  }
}

3. Validate

Any JSON Schema 2020-12 validator works. With Node, Ajv needs its format plugin, because the schemas use "format": "date":

npx -p ajv-cli@5.0.0 -p ajv-formats@3.0.1 ajv validate --spec=draft2020 -c ajv-formats -s estimand.json -d my-estimand.json
npx -p ajv-cli@5.0.0 -p ajv-formats@3.0.1 ajv validate --spec=draft2020 -c ajv-formats -s model-manifest.json -d my-manifest.json

Each command prints valid for its file. If another validator stops on an unknown format, load its format plugin or switch format checking off; the shape check is the same either way.

A schema check tells you the document is well formed. It does not tell you the numbers can be combined: two estimands can both validate and still answer different questions. That comparison is the job of gate G-EST-02 (section 15).

4. Optionally, run the gates

With a checkout of the UMP repository, the reference implementation can also run the gates on the document:

python -m ump_spec check model_manifest my-manifest.json

For this manifest the report shows no stops and one fallback, G-VEN-01 with VENDOR_UNVALIDATED: a vendor table nobody has back-tested yet is usable, labelled, at reduced trust. The package is an informative reference implementation; where it and the spec disagree, the spec wins.

Next

• Pick your conformance class and read what it asks of you.
• See every artifact kind with a minimal example on the schemas page.