D-06 — Ontology Pack for Developers

Scope: What an ontology package binds, how a naming change reaches every desk that already committed to the old name, what a bundle developer must declare when adding a new thing, who approves a new name, and what never goes in code. (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md; source: Jijibora Architecture — Design Thesis in Developer Terms)

Status: as of 2026-11-09

Blueprint sources: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md; Jijibora Architecture — Design Thesis in Developer Terms; Data Fabric — Message Bus and Engine Interfaces (Developer Concept Doc); Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs; Playbook Registry — What You Can Run, Who Runs It, What You Get Back; AGENTS.md (cohort definition broadcast, s157)

What this means for you

New things enter the platform as ontology entries, not as new branches or new stores. You declare the kind, its visibility profile, its lease purposes, and its governed name, and the pack machinery carries that declaration to every desk. If your change needs a place to store a new kind of record, stop and ask before writing code (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md; source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md).

Details

1. What the pack binds

The ontology package is one shared registry: a single town dictionary where every department uses the exact same name for everything, so the same physical borehole and compound carries one identity instead of five departmental names (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). In developer terms the package binds six things together.

Claim types. Every fact — ticket, due, announcement, visitor pass, building event, sourcing requirement — is a claim under the claims plane, and the plane is a single generalised primitive where packs supply values only and the runner never branches on claim type (source: Jijibora Architecture — Design Thesis in Developer Terms; source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs). A pack therefore names the governed claim types it operates on, the way the community packs name their ticket, due, announcement, and passing-on types over their declared channels and governed actions (source: Jijibora Architecture — Design Thesis in Developer Terms).

Entity kinds. The registry gives every clinic, pump, vehicle, and road one clear identity, so a ward officer's breakdown report is instantly the same record the water engineer and the finance clerk see, entered once and updated everywhere (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). Those kinds are the addressable things the pack senses and acts on — buildings and properties in the property family, people and vehicles in the claims families (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs).

Scope and space hierarchy. Tenancy and isolation are carried by scope: the requesting community's scope filters what the assistant or resolver may see, and federation stays a whole-record allow or deny decision at the boundary (source: Jijibora Architecture — Design Thesis in Developer Terms). Space is carried by the hierarchical broadcast subjects and cell-based narrowing the packs already declare when they listen (source: Data Fabric — Message Bus and Engine Interfaces (Developer Concept Doc)).

Council and naming registry. Standards, ceilings, and canonical names live as governed configuration that every ward inherits. A council standard such as no public water point out of service beyond a day is inherited by every ward, a ward may tighten it but never loosen it behind closed doors, and that inheritance is enforced at compose time rather than reported after the fact (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). The naming registry is how the one name stays the one name: adding a new canonical name is a registry entry, not a local rename.

CNS types and capability refs. Governed naming is typed: each claim and entity type is a governed path, and each capability the pack needs is a governed path that resolves to a route through the interface catalogue, failing closed when the capability is missing (source: Data Fabric — Message Bus and Engine Interfaces (Developer Concept Doc)). Packs bind those typed names so a consumer can match interest rather than address, the engine resolves the subject, validates against the declared allowlist, and dispatches the declared handler (source: Data Fabric — Message Bus and Engine Interfaces (Developer Concept Doc)).

Naming governance hooks. The active-rules layer is what makes the dictionary more than a filing cabinet: bylaws become active monitors that watch for real-world events and cascade pre-approved responses across agencies in seconds (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). The template for those hooks is the community-starter plus property families the platform already ships, with their reflex and standing-order families as the senses and the terminal steps as the acts (source: Jijibora Architecture — Design Thesis in Developer Terms).

2. How naming changes propagate

Yes — the sources describe the propagation pattern. The cohort definition broadcast pattern in the platform memory is the template: a definition snapshot is taken, broadcast as an audit-trailed publication with delivery confirmation, subscribed to by consumers who declare their filters, and acknowledged by receipt, so a change in the registry travels as a definition rather than as a code change to each consumer (source: AGENTS.md s157). The pack's naming change follows the same story.

When a name is added, corrected, or deprecated, the owning desk snapshots the new registry state and broadcasts the definition with its schema, so subscribers receive the change under the name they already subscribed to. Subscribers apply it against their own filters — which cohorts, scopes, or subjects they follow — and acknowledge with a receipt that confirms delivery. The audit trail records the broadcast and the receipts, so a verifier can show that the old name and the new name referred to the same thing from the moment the receipt arrived. Consumers do not learn the new name by reading the pack's files; they learn it because the definition was broadcast to their subscription (source: AGENTS.md s157; source: Data Fabric — Message Bus and Engine Interfaces (Developer Concept Doc)).

Interest-based routing is what makes that safe: consumers subscribe by interest rather than by point-to-point address, the fabric is aligned to ceilings and tiered evaluation, and playbooks declare their publisher and consumer subjects explicitly (source: Data Fabric — Message Bus and Engine Interfaces (Developer Concept Doc)). A desk that did not subscribe to the changed definition keeps the old meaning; a desk that subscribed receives the new meaning as a receipted delivery, never as silent drift. The durable store remains the record plus a bounded vocabulary — the broadcast is the delivery anchor for the naming change (source: Data Fabric — Message Bus and Engine Interfaces (Developer Concept Doc)).

Thin coverage, stated plainly: the s157 pattern describes cohort-definition broadcast, subscription, and receipt in full, and the ontology pack reuses that pattern for naming, but the exact naming-broadcast subject wording and the exact schema-filter vocabulary for a new name are UNKNOWN in the read set (source: AGENTS.md s157; source: Jijibora Architecture — Design Thesis in Developer Terms).

3. What a bundle developer must declare when adding a "new thing"

Declaring a new thing is four declarations, not a feature build.

Entity kind. Name the kind itself and the governed identity it carries. The kind must map into the canonical primitives — a claim, a truth node, a resource — and if it cannot be mapped, stop and ask before writing code (source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md). The governed types the new kind needs are declared as typed paths, the way a community ticket kind pairs with its person kind (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs).

Indexability profile. Declare what may become a searchable facet and what must never travel as raw metadata. Scrubbed facets are the only thing that matches; raw metadata in a facet is refused, and the indexability scrub is required before matching (source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md). That profile is a value in the pack, not a code switch — a new profile is a new lookup value the runtime reads, and runtime services never read pack files from disk (source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md).

Lease-purpose overlays. Declare why history may be read. Building history is leased only for the stated purpose, a child role inherits the same purpose ceiling, and a purpose grant is what unlocks anything beyond scrubbed fields (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back). Each overlay names its purpose so a consumer can be checked against it rather than granted open-ended access.

CNS entry. Register the governed name itself, with its capability references, in the naming registry so the interface catalogue can resolve every capability the pack uses (source: Data Fabric — Message Bus and Engine Interfaces (Developer Concept Doc)). The entry carries the canonical subject, the canonical event name, and the pipeline identity the pack declares for its lookups, so future packs match by declaration rather than by guessing (source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md). Advisory helpers stay off by default: hooks propose and narrate only, the core path works with hooks empty, and nothing auto-approves or auto-pays (source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md).

A claims-taxonomy entry is declared the same way when the new thing is adjudicated rather than sensed: the pack names the claim type, the entity it binds to, the evidence it demands, and the quorum bands that govern it, and the runtime resolves those values without branching on the type (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs).

4. Who approves a new name

Ownership is the council, and the clerk keeps the registry. The government-trial story is the ownership story: the council passes the non-negotiable service standard, every ward inherits it, and no ward office can secretly loosen the standard to seven days behind closed doors (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). In platform terms, that means a new name is approved at the parent scope that owns the ceiling, and child scopes may narrow it but never widen it — a widening composition is refused at compose time and logged (source: Jijibora Architecture — Design Thesis in Developer Terms).

Operationally that approval looks like the two-person discipline used elsewhere: one person drafts the registry change, a second named person co-signs, and the change lands only when both have acted and the base has not moved since drafting started, with a full audit trail of who drafted and who co-signed and when (source: D-06 — FINMON: Money Side — Billing, Desks, and Proof of Value). The exact committee name, quorum size, and voting procedure for the naming committee itself are UNKNOWN in the read set — the sources give you the council-owns-the-ceiling rule and the two-person landing discipline, but not the committee's charter (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). Name that gap explicitly to the customer rather than inventing a committee.

5. What NEVER goes in code

No per-vertical branches. The claims runner never branches on claim type, and swapping a value group changes refusal rules with zero code change (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs). The same rule governs ontology: a new ontology entry is a pack edit — new typed names, new fragments, new vocabulary, new lookup values — never a new branch that asks what kind of thing this is (source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md).

Never a second bus or envelope. Packs reuse the canonical envelope and the criteria subject family, declaring their publisher and consumer subjects explicitly, and the durable store remains the record plus a bounded vocabulary (source: Data Fabric — Message Bus and Engine Interfaces (Developer Concept Doc)). Never a filesystem read at runtime: pack values are published to the messaging key-value store by the offline seeder and read from there (source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md). Never leave the audit: every naming change ships with its snapshot, its broadcast, and its receipts, because a rule that cannot be audited cannot be governed (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md).

Ceilings ride along with every new name: if the new kind carries a service standard, the standard is declarative and inherited, and tightening is allowed while loosening is refused (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). A new thing that carries no ceiling is allowed — but it must say so.

6. Land and space design

Space is a design primitive, not a map label. The hierarchy runs continuously from the largest jurisdiction through intermediate districts and estates down to a single block or building and then to a unit or parcel and finally to a sensor or asset site. Each level is a governed kind in the pack with the same rules as any other kind: a governed name, a scope, and a place in the inheritance chain. Design space first, then let operations attach themselves to it, because every city operation the sources name already assumes it can point at a place — a building history summary anchors to a property, a community ticket anchors to a resident's location, and a water outage anchors to the ward that inherits the service standard (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back; source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md).

Land-use types are declarative values in the pack, not code. A parcel or building carries a declared use from a governed vocabulary the pack reads at runtime — residential, commercial, public, mixed — and that value drives which inspections apply, which utility routes serve it, and which service standards it inherits. Changing the vocabulary is a pack edit with a new version mark, never a migration (source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md; source: Data Fabric — Message Bus and Engine Interfaces (Developer Concept Doc)).

City operations attach to space entities by binding, not by duplicating. Permit claims bind to the parcel or building they authorize, inspections bind to the site they visited, utility routes bind to the corridor and the sites they serve, complaint claims bind to the unit or site they complain about, and tax assessments bind to the parcel whose value they assess. The pattern is the household pattern the sources already use: a home claim binds to its building kind, a vehicle claim binds to its vehicle kind, and a person claim binds to its person kind (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs). The same binding holds for space: the operation is a claim, the place is the entity it points at, and the two are joined by reference so they share one history.

The canonical mapping follows the zero-bespoke rule with no exceptions. A land entity, a space node, and an operation against it all map into the same canonical primitives the platform already owns — the claim record for the durable fact, the graph node and typed edge for the navigable place and its relations, and the universal integration ledger when the fact must mirror an external system. No new stores are introduced for land, no per-jurisdiction branch is written, and when something about a parcel cannot be mapped onto those primitives the design stops and asks instead of inventing a store (source: Core Concepts — Vocabulary as Mechanisms (Developer Concept Doc); source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md). Broadcast hierarchy and cell narrowing already give the delivery side of space its shape, so a place-bound event travels with the hierarchy rather than being hand-delivered per district (source: Data Fabric — Message Bus and Engine Interfaces (Developer Concept Doc)).

Thin coverage, stated plainly: the exact land-use vocabulary, the exact parcel-level lease-purpose wording, and the exact inspection and tax-assessment claim shapes are UNKNOWN in the read set. Treat the hierarchy, the declarative land-use values, and the binding pattern above as the design; treat every specific vocabulary entry as pack data to be declared, not as code to be assumed (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs).

7. Entity history and lifecycle design

The lifelong entity plane is the continuity layer of the whole backbone. It joins an enduring entity to its history of claims through a reference pointer, so a building, a vehicle, a person, an organisation, and a resource each carry one identity from first mint to final archive, and every claim that ever concerned it stays reachable from that identity (source: Core Concepts — Vocabulary as Mechanisms (Developer Concept Doc); source: Lifelong Entities API (non-fungible lifespan) — OpenAPI 1.0.0).

Entity-to-claim links are how history accumulates. A lifecycle change names the entity kind, the entity identity, the event kind, the actor, and the before and after states, and when the change is governed the bridge starts the proof session and writes the session reference back onto the event so the early event is not lost (source: Core Concepts — Vocabulary as Mechanisms (Developer Concept Doc)). Reading history resolves through that same pointer and its ordering indexes, and an entity that is finalised closes its version chain and becomes read-only, with no further transitions allowed (source: Lifelong Entities API (non-fungible lifespan) — OpenAPI 1.0.0).

Alias resolution keeps one identity across many mentions. A first-notice alias resolves to the same person or vehicle and the same journey across search, evidence, and approval, so the life of the entity does not fork every time a caller uses a different handle for it (source: docs/platform-map/system/D-05-PLAYBOOK-REGISTRY.md). The alias is an entry in the registry, not a second entity.

Changes, timelines, attachments, and leases all ride the same plane. The entity carries its version history with actor, action, and time, and its timeline is that version history read in order (source: Lifelong Entities API (non-fungible lifespan) — OpenAPI 1.0.0). Attachments attach to the entity they evidence, and leases gate how that history may be read: a building history is leased only for the stated purpose, and a purpose grant is what unlocks reading beyond scrubbed facets (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back).

Indexability profiles are declared per entity kind. What may become a searchable facet is a pack value, and the scrub is required before matching — scrubbed facets only, never raw metadata — and that profile is how a vehicle, a building, a person, an organisation, and a resource each decide what the world may see of them (source: docs/event-sourcing/rules/lifelong-entity-state-rule.example.json; source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md). Entity-field claims bind through that same profile: the home pack binds its building kind, the motor pack binds its vehicle kind, and the ticket pack binds its person kind, so adjudication never invents its own copy of the entity (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs).

Facet-match notifications reuse the same plane without a second copy. The continuous facet watch matches scrubbed facets keyed by the entity, emits the standard fired notice with causation inherited, and downstream stages may consume that notice — sourcing and standing-order stages among them (source: docs/event-sourcing/rules/lifelong-entity-state-rule.example.json). Sensing never auto-approves: it notifies, and a human decision gate approves (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)).

History never rewrites itself, and the guarantees are structural. Lifelong history reuses the pointer rather than introducing new structures, governed signals publish to the delivery anchor rather than persisting as a private stream, and the proof trail is append-only with each step hash-chained to its predecessor so a step cannot be mutated or reordered (source: Core Concepts — Vocabulary as Mechanisms (Developer Concept Doc)). Finalisation is the strongest guarantee: once an entity is finalised, its chain is closed and it is read-only (source: Lifelong Entities API (non-fungible lifespan) — OpenAPI 1.0.0). Any correction after finalisation is a new entity or a new claim that references the old one, never an edit in place.

Thin coverage, stated plainly: merge semantics between two entities that turn out to be one, and the exact alias-dedup procedure, are UNKNOWN in the read set. The sources give you alias resolution, append-only history, and read-only finalisation; they do not give you a merge operation. Do not invent one (source: Core Concepts — Vocabulary as Mechanisms (Developer Concept Doc); source: Lifelong Entities API (non-fungible lifespan) — OpenAPI 1.0.0).

Open items / gaps

• Naming-broadcast subject and schema-filter vocabulary for a new name are UNKNOWN (source: AGENTS.md s157).
• Naming committee charter, quorum, and voting procedure are UNKNOWN (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md).
• Ceiling digest carriage in receipts and approved-digest recomputation in the seeder are not yet shipped; a name change cannot assume a digest check the seeder does not yet do (source: Jijibora Architecture — Design Thesis in Developer Terms).
• Customer-held signing root and customer certification remain not yet enforced; treat the current registry as vendor-operated (source: Jijibora Architecture — Design Thesis in Developer Terms).