This playbook treats a geozone as a governed record with a lifecycle, not a polygon someone can silently edit. Confirm the schema edition and publication rules accepted in your jurisdiction before issuing a zone.
Define geometry, altitude, and applicability
Create the horizontal geometry in an explicit coordinate reference system and validate ring closure, self-intersection, and dimensional limits. Record lower and upper vertical references, units, and whether boundaries are inclusive. Add the category, restriction or information, authority, contact, and applicability conditions required by the target profile.
Represent “surface,” height above ground, and altitude above mean sea level precisely. Never convert between them without terrain evidence and a recorded method.
Draft with provenance
Every draft needs an author, source, created time, intended jurisdiction, and reason. Attach notices, airspace decisions, survey files, and source identifiers. If a geometry was imported, retain the original file and parser report.
Run semantic validation in addition to schema validation. A record may be structurally valid while its end time precedes its start time or its altitude band is impossible.
Review and publish
Use maker-checker separation for publication. The reviewer confirms geometry, vertical limits, dates, authority, and downstream audience against the rendered map and the serialized record. The person who created or last materially changed the draft should not be its sole publisher.
Publication creates an immutable version with an effective time and a content hash. Subscribers receive the version identifier, not merely the stable zone identifier.
Operate activation windows
Model one-off, recurring, and conditional activation explicitly. State the timezone and daylight-saving treatment. For externally triggered activation, record the trigger source, operator, time, and resulting window.
Test boundary cases before publication: the first instant, final instant, overnight recurrence, timezone change, and a consumer whose clock is slightly skewed.
Amend without rewriting history
Correcting a draft may update that draft. Changing a published zone creates a new version with a reason, effective time, and relationship to the superseded version. Material changes should trigger the required notice and invalidate plans whose frozen context relied on the old version.
Consumers must be able to distinguish “this is the latest version” from “this is the version used when this operation was approved.” Preserve both.
Withdraw and notify
Withdrawal does not delete the zone. Issue a terminal lifecycle event with the withdrawing authority, reason, effective time, and final version. Notify consumers and retain the record for audit and investigation.
Plan for cache lag and disconnected consumers. State how long a published record may remain in consumer caches and how an urgent correction is communicated outside the normal feed.
Acceptance checklist
- Geometry and vertical references pass structural and semantic validation.
- Draft and publication actors are distinct where policy requires it.
- Effective and recurring times have boundary tests.
- Published changes create versions rather than in-place edits.
- Operation records retain the exact zone versions they used.
- Withdrawal is propagated, observable, and auditable.