Occupancy Ledger¶
Record ledger — instantiates Persistent Site Framing
Records who occupied which site, when, and under what authority — an append-only history of each site's succession of occupants.
An Occupancy Ledger is the archetype's memory: for each site it keeps the time-bounded record of every occupant that has held it — occupant X occupied site Y from A to B under authority Z in status S — and preserves those records in sequence so the succession can be read back later. Its defining move is modeling occupancy as an explicit, append-only relation rather than a mutable "current occupant" field: nothing is overwritten, so the site's history is reconstructable, and the site's identity never collapses into whoever happens to hold it now. The ledger's whole value is durability and completeness of the past; it is the answer to "who was here, when, and who said they could be."
Example¶
A downtown coworking space assigns hot-desks by the hour, and its old spreadsheet only ever showed today's occupant — so when a member reported a laptop stolen from "desk 34 last Tuesday afternoon," nobody could say who had been at that desk, or who had booked the two-hour slot before. The space switches to an Occupancy Ledger. Every booking writes an immutable record: member, desk-site, start and end timestamp, the booking authority (self-serve app or front-desk override), and status (reserved, checked-in, no-show). Desk 34's row is no longer a single name that gets overwritten each session; it is a stack of intervals stretching back months.
Now the security question is answerable in seconds: desk 34, last Tuesday, 2–4pm, member #812, checked in via the app. The ledger did not control the booking or display the room's live status — it simply remembered, faithfully and in order, so the succession of occupants survived the turnover.
How it works¶
The ledger is an append-only store of occupancy tuples. Each record binds a site to an occupant over a closed or open interval, tagged with the authority under which the occupancy was granted and the status it ended in. Two disciplines make it trustworthy. Immutability: records are added, never edited in place; a correction is a new record that supersedes, so the trail of what was believed and when is itself preserved. Interval integrity: a site's records form a coherent timeline — overlaps are either forbidden (a single-occupant site) or explicitly modeled (a shared site), and gaps are legible as genuine vacancy. The ledger receives its records from the assignment process and serves them to anything that needs to know the past; it does not itself decide placements, enforce fit, or render current status.
Tuning parameters¶
- Temporal resolution — day-level versus second-level timestamps. Fine resolution answers precise "who was here at 2:14" questions but multiplies volume; coarse resolution is compact but blurs short occupancies.
- Retention depth — how far back history is kept before archival. Deep retention supports long-range audit and pattern analysis but grows unbounded and raises exposure of sensitive histories.
- Correction model — edit-in-place versus supersede-with-new-record. Supersession preserves the audit trail (and is the point) but makes the store larger and queries more careful.
- Attribute richness — how much context each record carries (authority, status, reason). Richer records answer more questions but cost more to capture and can encode sensitive detail.
When it helps, and when it misleads¶
The ledger's strength is that it makes turnover reconstructable: because it is an append-only log[n1], it answers retrospective questions — succession, dwell time, who authorized what — that a last-writer-wins field destroys. It is the archetype's defense against broken histories and false continuity.
Its failure mode is quiet mutation: the moment records are edited or deleted in place "to fix a typo," the ledger stops being a reliable history and becomes just a fancier current-state store. A second, serious misuse is over-exposure — a complete occupancy history is sensitive (it can reveal who was where, when), and a ledger that is too readable naturalizes surveillance the system never intended. The guarding discipline is strict append-only writes with supersession for corrections, retention and access policies proportionate to the sensitivity of the histories, and a clear boundary that the ledger records but never decides.
How it implements the components¶
The ledger fills the archetype's memory components:
occupancy_relation_record— it stores each occupancy as an explicit time-bounded relation (occupant, site, interval, authority, status), never as a mutable current-occupant field.occupancy_history_ledger— it preserves those records in sequence, append-only, so the full succession of occupants is reconstructable.
It remembers occupant turnover *within live sites; it does not record the fate of the site itself. When a site is retired, split, or superseded, that site_supersession_record is the Site Lineage Tombstone's. And it does not check its records against physical reality — the reconciling conflict_resolution_rule is the Site Audit Walkthrough's, its nearest twin (both handle the occupancy relation, but the ledger stores it and the audit verifies it).*
Related¶
- Instantiates: Persistent Site Framing — the ledger is the archetype's durable memory of occupant succession.
- Consumes: Assignment and Release Workflow — supplies the placement and release events the ledger records.
- Sibling mechanisms: Site Registry · Physical or Virtual Labeling System · Site Map or Plan · Capacity-Fit Matrix · Assignment and Release Workflow · Site Lineage Tombstone · Vacancy Status Dashboard · Site Audit Walkthrough
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Occupancy Ledger operates as a persistent ledger, log, register, or case record that preserves history and traceability because it records who occupied which site, when, and under what authority — an append-only history of each site's succession of occupants.
Independent corroboration: The frozen evidence defines Occupancy Ledger as 'Records who occupied which site, when, and under what authority — an append-only history of each site's succession of occupants', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Event sourcing and append-only logs developed reconstruction of current and historical state by replaying immutable occupancy events.
Related originating lineages:
- Law & Governance — Property, office, and custody registers supplied the older institutional practice of recording who held a site, when, and under what authority.
- Organizational & Management Science — Facilities management supplies the practical succession and utilization workflow.
Review resolution: Both independent reviews agree on primary origin computer_science; reconciliation resolves reported_ambiguity, alternate_origin_disagreement. Formative alternate lineages retained: law_governance, organizational_management. The broader reach of later applications is kept separate as domain_reach=multi_domain; origin_mode=cross_disciplinary_synthesis describes the historical relationship among lineages. Confidence is conservatively reconciled to medium, and encyclopedia_synthesis=true preserves the reviewers' boundary judgment.
Attribution caveat: The append-only implementation and institutional subject have distinct lineages; computing is primary because it defines the tracker behavior. Occupancy records long predate computing, but immutability, replay, and explicit intervals make this formulation distinctly event-sourced.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
[n1] An append-only log records events by adding immutable entries rather than overwriting state; the current picture is derived by replaying the entries. The idea is the backbone of event sourcing (popularized by Martin Fowler), and it is exactly what lets an occupancy ledger answer "what was true at time T" long after the fact. ↩