The Abu Dhabi Protocol

One contract every dataset in the registry carries.

Technical substance: the Neer Vazhvu Data Model, version 1.0, an open standard accepted on 30 July 2026 and enforced by the registry infrastructure this site runs on. [Water Parliament review: adoption language, see the note at the end.]

The world reports water in a hundred incompatible ways. A registry that simply collects them inherits every incompatibility. The Protocol takes the other route: it does not tell anyone what to measure, it tells every dataset how to say what it is, where it came from, and who stands behind the number. That is the whole contract. Everything below is what it takes to keep that promise machine-checkable.

What "verified" means here

A dataset is verified when a machine, not a reader, can confirm five things about it.

  1. It knows what it is. It names its logical dataset and the place or water system it describes, and the name on the file agrees with the name inside it. A record that cannot say what it belongs to is not data yet.
  2. Every upstream is named. Each external source carries its title, publisher, address, licence terms, the period the evidence describes, and the date it was retrieved. Accountability is per source, with no dataset-level waiver: a source is either a registered, watched publisher, or a one-time document declared closed with its date.
  3. Someone stands behind each value. Values are either asserted, where a publisher stands behind them and the quotable form is "the agency says X", or derived, where the registry computed them from named inputs and the quotable form is "analysis of these inputs shows Y". Derived values name their method.
  4. The traps are declared. Units live in the key names. Sign conventions, aggregation bases, and comparability breaks are written into the record. Absence is stated as absence, never as zero.
  5. Conformance is graded, not asserted. Every dataset sits on a four-rung ladder, assessed by a validator, and the grade travels with it.

The envelope

Every dataset carries the same wrapper around its content. For a plain data file the envelope keys sit at the top level; for a map layer they sit beside the features; for a database row they map to columns. The content inside can be anything the dataset's own contract defines. The envelope is what makes ten thousand different datasets one registry.

{
  "nvdm": "1.0",
  "dataset": "data-root/ward-profiles",
  "scope": { "kind": "city", "id": "madurai" },
  "provenance": {
    "sources": [
      {
        "id": "wris-gw-levels",
        "title": "India-WRIS Ground Water Level dataset",
        "publisher": "CGWB via India-WRIS",
        "url": "https://indiawris.gov.in/wris/",
        "license": "GoI open publication, cited with attribution",
        "as_of": "2026-06",
        "retrieved": "2026-07-25"
      }
    ],
    "method": "api",
    "produced_at": "2026-07-26",
    "produced_by": "scripts/fetch-wris-gw.py",
    "note": "free-text caveats",
    "conventions": {
      "sign": "depth positive-down; per-station overrides in station records",
      "units": "depths metres below ground level"
    }
  },
  "ext": { }
}

Three timestamps and only three, all ISO 8601: as_of, the period the evidence describes; retrieved, when it was acquired; produced_at, when this dataset was generated. Seven competing spellings of "when" in the wild were the reason.

A dataset that is an administrative view of evidence owned by another scope, a city page showing its basin's data for instance, declares itself a projection of that scope and names the method, instead of becoming a divergent copy. One canonical record, many projections.

Download the envelope as a JSON Schema (draft 2020-12).

Four shapes

ShapeWhat it isExample
Record envelopeAn object: the envelope plus named collections of recordsAllocations, commitments, facts
Feature collectionA GeoJSON layer with the envelope as foreign membersWater bodies, rivers, wards
Indexed collectionA map keyed by an external identifierCatchments keyed by OSM id
SeriesAn observation timeseries: entity id, ISO dates, unit-suffixed values, declared conventionsGroundwater levels, reservoir storage

Each logical dataset declares one shape and a core: the keys every instance must provide, with types and units. A core only grows by optional additions; removing or retyping a key for one place is exactly the drift the contract exists to stop. Anything a place needs beyond the core goes in a namespaced extension, and an extension used by two or more places is promoted into the core: the standard grows from practice.

Conventions

QuantityCanonical unitNote
Reservoir storagetmcPublisher units may sit alongside, never silently converted
Supply and demand flowmldEntitlements also in native units
Depth to waterm below groundSign convention must be declared
Areaha for water bodies, sqkm for catchmentsNever mixed within a dataset
Rainfallmm
Percentagespct, 0 to 100Not fractions

Names carry the romanised form, with local-language names in language-suffixed keys. External identifiers are named by their system (osm_id, lgd_code, census_code) and never collapsed into one another; crosswalks are explicit records. Geometry is WGS84 GeoJSON with stable feature identities so editions can be compared. Absent evidence is an absent key plus a note, hedged as "no known public X as of a date".

The conformance ladder

L0
Catalogued
In the catalogue; scope and dataset derivable from its path.
L1
Accounted
Every living upstream is registered and watched for new editions, or explicitly allowlisted with a reason.
L2
Enveloped
Carries a valid envelope: identity agrees with the path, dates are calendar-valid, per-source accountability holds.
L3
Contracted
Content validates against the dataset's own schema; records that make quotable claims cite their source and date individually.

The ladder is cumulative: a valid envelope on an unaccounted dataset stays at L1. New datasets entering the registry are required to reach L2; L3 requires the dataset's contract to be published.

Versioning

The contract is versioned semantically. Additive changes, such as new optional envelope fields or new dataset contracts, are minor versions; anything that would invalidate a conforming dataset is a major version, and version 1 datasets remain readable by version 2 consumers. Registries of scopes, datasets, and sources are append-only: renames are new entries with crosswalks. Changes ship with the validator's report attached, so the difference in conformance is the review artefact.

What the Protocol does not do

It governs data records, not presentation, and not policy. It does not prescribe what to measure or set targets. It is not a methodology for water credits, indices, or financial instruments; those sit outside the contract, and data conforming to it is not thereby an input to any of them. Conformance says how a dataset is described and verified; access to a dataset is governed by the licence each source states.

Full specification: Neer Vazhvu Data Model v1.0, maintained by Neer Vazhvu, the Parliament's platform and technology partner. [Water Parliament review: this page describes the contract the registry infrastructure enforces today. Whether the Parliament names it the Abu Dhabi Protocol's technical standard, or adopts it as the basis for one, is the Parliament's decision and this page will say so in the Parliament's words.]