sample guard became a declared cohort fact every record must match; island, moku, and act96Alignment may be null until reported; programId, appropriation detail, and a sourced reports list were added; a fiscalPublic cohort lists and pages every record while story and outcomes stay gated, and a record cannot publish without its moku. The fictional FY2026 cohort referenced below is a validator fixture (schemas/fixtures/v0/).1. The Award Registry Manifest
One JSON file per fiscal-year cohort (registry/FY2026.json), validated against a
versioned schema (JSON Schema Draft 2020-12, closed to undeclared properties). Two versions are
published: v0 (schemas/registry.schema.json), the demonstration
schema this cohort uses, whose sample guard makes real data unable to validate; and
v1.0 (schemas/registry.v1.schema.json), the program-data shape,
published as a reviewed artifact and exercised only by test fixtures — see §2a. The registry
governs five things and only five things:
identity, cohort membership, publication eligibility, discovery, and route
generation. It stores no financial system of record, no personal information, and no
regulatory determination.
2. Record anatomy
| Field | Meaning | Rule |
|---|---|---|
id | Award identity (GF-2026-HI-001) | Immutable once issued; never reissued or renamed |
slug | Route identity (/projects/<slug>/) | Stable once published; link permanence is a contract |
project, organization, agency | What, who, and which administering agency | Names come from the program record, not from this registry |
island, moku | Place: island + moku served | Moku is stewardship context (regional axis), never a regulatory classification |
programArea, act96Alignment | Program taxonomy + statutory alignment | Alignment mapping is program methodology — the State decides it; the registry records it |
publicationStatus | The gate | draft → validated → published, monotonic, human-held |
award | Fiscal year + amount | Must match the cohort; display-only, never a financial record |
summary, story | One-paragraph summary; awardee-voice narrative | Story serves only when published |
outcomes[] | Reported metrics | See §4 — definition rules |
links | ArcGIS destinations (dashboard, StoryMap, web map) | Null until the State registers a destination |
provenance | Program record + authoritative source | Required to publish; see §6 |
2a. Schema v1.0 — the program-data shape
v0 keeps real data out of this demonstration by construction. v1.0 is the versioned change v0 was documented to anticipate, and it rests on two rules instead of a guard:
- Minimal at draft, complete at publication. A record may enter the registry knowing only what an enacted appropriation line knows — project, administering agency, amount — and must earn island, program area, Act 96 alignment, summary, location, story, outcomes, and provenance before the gate releases it. The validator enforces that release bar.
- Fiscal facts are public law. A cohort marked
fiscalPublicrenders appropriation and funding-release figures for every record in the fiscal-status visual, while project pages and stories remain behind the publication gate.
v1.0 adds budget join keys (departmentCode, programId), appropriation
detail (means of financing, non-recurring, legislative reference), a funding block
(status, released, expended, as-of), an indicatorId on each outcome keyed to an
indicator dictionary, real TMK divisions, an open program-area taxonomy (a product of the outcomes
framework, not of the schema), and a submitter contact for accountability that is
never exported in the published projection and never rendered on a page. Every gate in
this repository accepts --registry <dir>, so the identical validation, build,
and intake run against a cohort kept outside the public repository. Doctrine:
docs/SCHEMA-V1.md.
3. Publication lifecycle
draft — the record exists and validates; visible to no one.
validated — data checked against its source; still builds nothing.
published — a person has reviewed and released it; the record renders a page and
exports in the published projection. The lifecycle is monotonic and the release bar is enforced
by the validator: a record cannot reach published without a story, at least one
outcome, and full provenance. Held records are publicly counted ("2 remain draft or
validated") but never leaked.
4. Outcome metric definition rules
- Every metric is a tuple: metric, value, unit, period, source note — no bare numbers, no undated claims.
- Values are reported and steward-validated, never derived, extrapolated, or forecast by the pipeline. The build renders what the registry holds; it computes only visible aggregates (counts and sums labeled as such).
- Elapsed-time and throughput measures state what they actually measure — total elapsed calendar figures must not be described as agency processing time.
- A metric that identifies areas for further review (screening, prioritization) is labeled a screening view, not a decision.
5. Data-quality controls
- Schema validation on every change — closed schemas, typed fields, enumerated vocabularies, pattern-checked identifiers.
- Registry invariants beyond schema: unique ids and slugs, id ↔ cohort consistency, award fiscal year ↔ cohort consistency, the publication release bar.
- Rejection is total: any finding stops the pipeline — an invalid registry builds nothing, rather than building something partly wrong.
- The audit trail is the version history: every published change is a reviewed commit; the pipeline run is its receipt.
6. Provenance
Every public claim walks one chain, rendered on every project page:
public page → published project record → Award Registry Manifest → State program record → authoritative State source.
The registry is a pointer of record, not a source of record: when a report and the State system disagree, the State system is right and the registry carries the defect.
7. Local adaptation checks
Before reusing this structure in another program or jurisdiction: map the local terminology (what is an "award," a "project," a "cohort" locally); confirm which office holds publication authority and encode that person into the gate; validate identifier conventions against local systems; and re-derive the metric definitions with the local program owner — definitions are never portable by default.