Ontologies, event sourcing, and the road ahead

Scope: Four plain-language stories for cities, ministries, and communities: why one shared list of names matters, how civic rules are published and checked today — and where the sources go quiet — what the civic maintenance desk does today versus what is described for tomorrow, and why entity storage — the one shared place where every city thing is kept once, named once, and remembered once — is the smart-city backbone for land and history. Status: as of 2026-11-09 Blueprint sources: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md; docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md; docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md; Playbook Registry — What You Can Run, Who Runs It, What You Get Back; S-01 — Overview (plain language); D-17 — Backlog Validation (platform-map recommendations)

What this means for you

One shared list stops five departments speaking five languages about one borehole. When every desk uses the same name and the same number for the same pump, clinic, vehicle, and road, a fault logged once is seen by everyone at once — no re-typing, no photocopying, no three-week letter chase (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md).

Your rules are kept separately from the software, and every change leaves a dated receipt. Thresholds and service times live in one editable place, so changing a number is a settings change, not a rebuild — and the history shows who changed what, when, and under which rule (source: S-01 — Overview (plain language)). What the sources do not give us is a named queue for approving a new shared-dictionary name, or a named person who can pause a rule — those are marked UNKNOWN below rather than guessed (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md; source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back).

The maintenance desk you can buy first proves the fix before it pays. A resident reports, a manager approves the crew in one tap, the crew proves the repair with a time-stamped photo and on-site position signal, and only then is money released (source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md; source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). Automatic standing orders — pre-agreed checklists that start by themselves when a set limit is passed — are described as a later expansion, not Day 1 (source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md; source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md).

Details

1. The ontology value: one shared list so every desk refers to the same thing

Ontology is a technical word for something ordinary: a single shared dictionary where every department uses the exact same names for everything (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). In plain words, it is the town's agreed list of things — the examples the sources name are clinics, pumps, vehicles, and roads, each with one clear number (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). Whether that same list also holds councils, streets, and citizens' roles in exactly those terms is UNKNOWN in the read sources (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md; source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md).

Picture the problem. The health office files the same borehole as a clinic name, the water office calls it a ward water point, public works knows it only as an asset number, finance knows only the contractor's bill, and the disaster office knows it only as the school evacuation point (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). When the pump burns out, the clinic loses sterile water, a supervisor's letter takes weeks to cross town, the artisan arrives with the wrong pipe, and finance keeps paying for a dry pump while the health director blames public works and public works blames finance (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md).

The cost it removes is time and confusion, not a promised savings figure — and no savings figure is stated here. Staff waste hours checking whether two names are the same thing, clerks spend half their week copying details between folders, and a breakdown waits weeks for an artisan (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). Under one shared list, information entered once updates all municipal desks: when a ward officer logs a broken pump on a phone, the water engineer, the health officer, and the procurement clerk see the exact same information instantly (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md).

Where naming decisions queue — who approves a new name — is UNKNOWN in the read sources. The sources do describe who sets the service standard, which is related but different: the council can pass a non-negotiable promise such as "no public drinking water point may remain out of service for more than 24 hours," every ward inherits that promise, a ward may promise to act faster, and no ward may secretly loosen it (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). That ceiling — a non-negotiable maximum promise a ward can only tighten, never loosen — is the authority pattern for standards; the sources do not name the approver for a new dictionary name itself, so do not treat the ceiling as that approval queue (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md; source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md). A related approval the sources do name is the board approving what the assistant proposes in the community desk, recorded with the decision (source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md).

How changes reach every desk without re-training. What is described is instant visibility, not a training programme: because there is one shared file, a correction is seen by all departments at the same time, and maintenance is linked directly to finance and photo proof (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). Whether staff need new training when a name changes is UNKNOWN in the read sources (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md).

2. Event sourcing management, the stakeholder half

Event sourcing means keeping a dated history of what happened, so the present state can be checked against the sequence that produced it (source: S-01 — Overview (plain language)). In this platform, history is the product: every change leaves a receipt showing who acted, when, under which rule, and what they saw — and the system refuses rather than silently inventing a step (source: S-01 — Overview (plain language)).

How rules get published and versioned, as far as the sources describe them. Business rules — thresholds, service times, and panels of who can do what — live in one editable place, not inside the software (source: S-01 — Overview (plain language)). Changing a number is therefore a settings change, not a rebuild (source: S-01 — Overview (plain language)). A change offered to connected units is gathered as roll-up answers and finalized only when all units have answered, with a signed receipt chain behind it (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back). Packs run first as a practice check with test data, and a pack cannot declare itself live (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back).

The four-step lifecycle "draft, published, paused, reviewed" is UNKNOWN in the read sources. Those labels and that queue are not defined in the six sources read for this note, so they are not presented here as today's fact (source: S-01 — Overview (plain language); source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back). The closest described pattern is practice before live, finalize only when all units answer, and a two-person rollback when a change must be undone (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back).

Who can pause what is UNKNOWN in the read sources. The only two-person control described is the rollback of a configuration change, which needs two people (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back). Emergency break-glass — one person asking and a second named person approving, with a time limit and an audit entry — is described as part of the starter pack, but it is an emergency override, not described as the rule-pause authority (source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md).

What the auditor sees when a rule changes. For a configuration change, the auditor sees the signed receipt chain, the roll-up transcript, and the rollback packet (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back). More generally, every step leaves a receipt — who, when, under which rule, and what they saw — and money or a high-value decision cannot be approved by one person alone where a quorum is required (source: S-01 — Overview (plain language); source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back). The exact shape of the auditor's file is UNKNOWN in the read sources (source: S-01 — Overview (plain language); source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back).

3. Maintenance today and soon

What the civic maintenance desk does today. In the starter desk (the sources call it the artificial intelligence (AI) maintenance desk), a resident sends a message by messaging app, text-menu phone service, or the community mobile app; the desk classifies the problem — plumbing, electrical, security, or facilities — and takes the location, urgency, and a photo (source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md). It proposes the nearest certified vendor, your manager approves in one tap, and the vendor receives the task on mobile (source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md). The town version of the same flow checks the municipal register of pre-vetted, certified local technicians in that ward, selects the closest qualified technician, and coordinates the tools and materials needed (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md).

Verified close and escrow. The technician replaces the faulty part, takes a time-stamped photo of the finished work, and the on-site position signal (GPS, short for Global Positioning System) confirms they were there (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). The vendor uploads photo and position proof, an inspector may sign, and the milestone is sealed with a proof receipt (source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md). Only then is money released — in the town story, from public repair funds to the artisan's mobile money account after the ward inspector taps approve, so no payment goes out for work nobody inspected (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). Every step is narrated in plain English and Swahili — who, how far, and what cost is held — in the sources' own example (source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md).

What is described for soon, stated exactly. The same shared foundations support an orchestration expansion — standing orders, predictive models, and emergency mode — for facilities directors who own pumps, generators, gates, and similar systems, and it requires the flagship community product first (source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md). The entry-point source excludes full orchestration, including standing orders, from the starter pack and places it as a later add-on (source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md). Separately, the town story describes active civic rules: a rainfall sensor crossing a flood threshold triggers local-language warnings, road crews clearing culverts, heavy trucks avoiding fragile roads, and a caretaker unlocking a dry shelter — coordinated in seconds under pre-approved procedures, without five separate emergency meetings (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md).

Planned-maintenance rounds and preventive schedules are UNKNOWN in the read sources. No calendar, cadence, or preventive schedule list for planned rounds is described in the six sources read for this note, so none is promised here (source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md; source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md). The only dated expansion the sources give for recurring work is standing orders in the following months after the starter desk (source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md; source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md).

4. Entity storage as the smart-city backbone: land and history

Entity storage — the one shared place where every city thing is kept once, named once, and remembered once — is what turns the shared dictionary in section 1 into a working smart-city backbone. A parcel is one piece of land with a boundary and an owner or occupant; a hierarchy is the ladder it sits on; a timeline is the dated history kept under its one name. The sources give this backbone a partial foundation: one clear number per clinic, pump, vehicle, and road, wards inheriting the council's standard, and claims that carry their stage, who touched them, and the receipts proving each step (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md; source: S-01 — Overview (plain language)). Everything below that, the sources either narrowly support or leave UNKNOWN, and the two are kept apart.

Land usage: parcels in the shared space hierarchy. The backbone this note is asked to describe puts parcels in a ladder: municipality, then estate, then block or building, then unit or parcel — with land-use types (for example, what the land is for) kept as values on the parcel, and applications, disputes, and assessments attached to the parcel as its claims and dated history. The sources do not describe that exact ladder, any land-use type list, or any parcel-attached application, dispute, or assessment — all UNKNOWN in the read sources (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md; source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md; source: S-01 — Overview (plain language)). What is in scope is narrower: construction permits are named as one kind of work the same shared engine can run, where the kind of work is a setting, not a different system (source: S-01 — Overview (plain language)). The neighbouring facts the sources do give — a building-based loss report, a contractor matched to it, and a lifelong building history summary — belong to buildings, not yet to parcels (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back).

How a smart-city situation would use a parcel — sourced anchor versus UNKNOWN. The zoning check before a permit, the use-change history, the link between a parcel and who occupies it, ground-service route planning along streets and facilities, and a public land audit are all UNKNOWN as described workflows in the read sources (source: S-01 — Overview (plain language); source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back). Their closest sourced anchors are: complaints or claims carry stage, people, and receipts, so an application and a later decision could share one parcel file (source: S-01 — Overview (plain language)); a building's history can be shared only for a stated purpose and within a time limit — a time-limited lease, in plain words — which is the pattern an occupancy link would need to respect (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back); and the maintenance flow already selects the closest qualified technician and coordinates the exact location, tools, and materials, which is the pattern ground-service routing would extend (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). None of those anchors is, by itself, a zoning or land-audit workflow — do not read them as one (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back).

Entity history: one continuous timeline per city thing. The backbone promise is that every city thing — a building, a parcel, a person, a crew, a vehicle, a sensor station — keeps one continuous timeline: the changes made to it, the other names it has carried (its aliases, in plain words the five-names-for-one-borehole problem from section 1), the photos and papers attached to it, and any time-limited permissions to use or look at it (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md; source: S-01 — Overview (plain language)). Every claim — every job, application, or dispute — is meant to resolve to one of those things, so the history accumulates under one name instead of scattering across folders (source: S-01 — Overview (plain language)). What is sourced is the pattern, not the full coverage: history is the product, every change leaves a receipt, lifelong vehicle and building identity is bundled in the claims pilot, and a building history summary exists — but one continuous timeline covering all six kinds of city thing, and the exact rule that resolves each claim to its thing, are UNKNOWN in the read sources (source: S-01 — Overview (plain language); source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back).

Why lifecycles matter to the buyer: "who owns what day by day" stays answerable. If the one name accumulates every change, every alias, every attachment, and every time-limited permission, then the question "who owned this, who used this, who approved this — on which day?" can be answered from the thing's own timeline instead of by hunting through five departments' folders (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md; source: S-01 — Overview (plain language)). That is the direct link to the unified ontology story: the shared dictionary names the thing once, and the timeline remembers it once (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md).

The zoning dispute story — illustrative, not a sourced workflow. Picture a parcel where a use-change application is filed today and the dispute is resolved tomorrow. In the backbone picture, both land on the same parcel file: the application and its receipts, the decision and its receipts, one after the other, so the parcel remembers both and the next officer does not start from zero (source: S-01 — Overview (plain language); source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). Whether a zoning-dispute workflow exists today, on those terms, is UNKNOWN in the read sources — treat the story as what the buyer should ask for, not as a current promise (source: S-01 — Overview (plain language)).

What this buys you today. Land records that update once and reach every desk: one entry updates all municipal desks at the same time, exactly as the pump example does (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). And history that makes audits straightforward: money is released only with a time-stamped photo, on-site position proof, and the inspector's signature, so audit defence is complete and weeks of manual audit assembly become an export (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md; source: S-01 — Overview (plain language)).

Open items / gaps

Who approves a new shared-dictionary name, and where that request queues, is UNKNOWN in the read sources; service-standard ceilings and board approvals are described, but they are not that name queue (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md; source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md).
Whether staff need new training when a name changes is UNKNOWN in the read sources (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md).
The rule lifecycle labels "draft, published, paused, reviewed" and the person who can pause a rule are UNKNOWN in the read sources; only practice-before-live, finalize-when-all-answer, and two-person rollback are described (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back; source: S-01 — Overview (plain language)).
Planned-maintenance rounds and preventive schedules, including any calendar or cadence, are UNKNOWN in the read sources and must not be assumed (source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md; source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md).
No price or savings figure is stated in this note, and no savings is promised; the claims pilot price is explicitly unpublished until a baseline is measured (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back).
Real money movement remains gated until finance keys, a human approver, and the payments ledger are ready, and packs run first as a practice check rather than declaring themselves live (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back).
The parcel space hierarchy (municipality, estate, block or building, unit or parcel), land-use types, parcel-attached applications, disputes and assessments, zoning checks, occupancy links, ground-service route planning, and public land audit are UNKNOWN in the read sources; only construction permits as a setting and building history are sourced (source: S-01 — Overview (plain language); source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back).
One continuous timeline covering buildings, parcels, people, crews, vehicles, and sensor stations together, and the exact rule resolving each claim to its thing, are UNKNOWN in the read sources (source: S-01 — Overview (plain language); source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back).