Green Fee Transparency Portal · Toolkit Document 2 · Sample

Registry & Analytics Reference Guide

Version 0.1 · August 2026 · Āina Design Corp

Demonstration only: field definitions below are exercised with fictional sample data. The authoritative definition of any real program metric belongs to the State program administration, not to this registry.

1. The Award Registry Manifest

One JSON file per fiscal-year cohort (registry/FY2026.json), validated against a versioned schema (schemas/registry.schema.json, JSON Schema Draft 2020-12, closed to undeclared properties). 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

FieldMeaningRule
idAward identity (GF-2026-HI-001)Immutable once issued; never reissued or renamed
slugRoute identity (/projects/<slug>/)Stable once published; link permanence is a contract
project, organization, agencyWhat, who, and which administering agencyNames come from the program record, not from this registry
island, mokuPlace: island + moku servedMoku is stewardship context (regional axis), never a regulatory classification
programArea, act96AlignmentProgram taxonomy + statutory alignmentAlignment mapping is program methodology — the State decides it; the registry records it
publicationStatusThe gatedraft → validated → published, monotonic, human-held
awardFiscal year + amountMust match the cohort; display-only, never a financial record
summary, storyOne-paragraph summary; awardee-voice narrativeStory serves only when published
outcomes[]Reported metricsSee §4 — definition rules
linksArcGIS destinations (dashboard, StoryMap, web map)Null until the State registers a destination
provenanceProgram record + authoritative sourceRequired to publish; see §6

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

  1. Every metric is a tuple: metric, value, unit, period, source note — no bare numbers, no undated claims.
  2. 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).
  3. Elapsed-time and throughput measures state what they actually measure — total elapsed calendar figures must not be described as agency processing time.
  4. A metric that identifies areas for further review (screening, prioritization) is labeled a screening view, not a decision.

5. Data-quality controls

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 the portal 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.