I liked the discomfort in the premise: a person could be standing in the city and still be legally dead because a record said so. From there the idea of Bureaucratic Reality Engine became more demanding. A correction to a name, parentage, marriage, office, or property could change the city’s treatment of someone, and several authorities might disagree about which record counted. The game needed to preserve that disagreement instead of smoothing it into one convenient answer.
The implementation conversations pushed that fictional question into C++ rules. I wanted events to remain the history, with official status derived from records and authority, so that revising a claim could change what the city currently believed without deleting what had happened. One contradiction report exposed a more concrete problem in the projection work: reporting a conflict was not enough if the derived view still presented a single false answer. The project grew by confronting those cases one at a time.
Events first, official reality second
The reported first slice included a headless CityIdentityEngine, typed IDs, event envelopes, deterministic event IDs, role-filtered queries, a contradiction registry, and JSON-lines event export.
The central model was event sourcing: keep the accepted events, then derive the current projection from them. The events included births, deaths, marriages, debts, and identity corrections. More consequential mutations—sealing a record, merging identities, or editing parentage retroactively—went through a dry-run and commit protocol with confirmation requirements.
That structure created concrete tests. Could a legally dead citizen still have a physically living body? Would a citizen’s query hide sealed records? Would a stale dry-run be rejected if the underlying state had changed? Would replaying the event log reproduce the same state?
The initial implementation report said nine tests passed. It also described a replay bug: accepted-commit audit entries were being added outside event replay. Moving their derivation into event application made the live and replayed states agree. These are historical implementation reports, not a fresh build of the package for this page.
The consequences grew in slices
Subsequent reports expanded the system through dependency-aware impact reports, canonical import, a host-facing API, public/private library boundaries, and additional consequence domains. Property and inheritance were followed by civic status, exile, criminal liability, office appointments, archive provenance, and source hierarchy.
The point of impact reporting was to show that changing one record could affect more than the field being edited. It also kept the dangerous operations tied to visible consequences and access rules.
Jurisdictions then introduced a harder question: which authority wins for a particular kind of claim? An external temple could outrank a district on marriage without automatically outranking it on property. Authority had to be specific to a domain, and unresolved conflicts needed to stay visible as conflicts.
A contradiction report was not enough
The most useful correctness problem appeared in the marriage model. The jurisdiction logic could identify the winning marriage claim while the person’s stored household still came from the last replayed marriage event. The explanation was correct, but the resulting official state was not.
The next feature slice was paused for a correction. MarriageRecorded would store a jurisdiction-local claim instead of immediately changing household membership. A resolver would compare claims and derive the household from the winning authority. Equal-rank conflicts would become disputed rather than silently becoming last-write-wins.
The reported patch also replaced substring-based relevance checks with exact affected-person IDs. That prevented an identifier such as L1 from accidentally matching L10. New tests covered claim order, authority overrides, disputed claims, and query consistency. The completion report listed 102 passing tests and an intentional sample-hash change caused by correcting the semantics.
Public memory without deleting history
Later slices separated public memory from legal state. A memory could be acknowledged, contested, or suppressed in the public projection while remaining present in the event history.
The reversible-decree work added suppression, restoration, contesting, and declassification, with authority checks and different views for citizens, magistrates, archivists, historians, and debug access. Rescinding a suppression decree could restore visibility. The decree should not rewrite identity, debt, property, criminal liability, or other legal consequences.
The Slice Fourteen report listed 124 passing tests, a host smoke test, replay compatibility checks, and tamper tests. It explicitly left irreversible erasure and faction/public-opinion simulation out of scope.
The fictional premise left me with a concrete coding test. If the city believes a record, I need to know which authority supplied it, how the consequence was derived, and whose view of the city is being shown. A contradiction that only appears in a report has not yet changed the city the player encounters.