The Architected Self 02
The Ontology of Personal Data: Temporal, Structural, and Knowledge Items
*#architected_self, Post 2 of 10*
---
Before the Tools
Every information architecture project I have seen — personal or institutional — makes the same initial mistake: it begins with the tools. A database is selected, a folder structure is sketched, a tagging convention is adopted, and the data is poured in. The resulting system reflects the logic of the tool rather than the logic of the data. When the tool changes, or when the data’s requirements exceed what the tool assumed, the system must be rebuilt from scratch — because it was never grounded in anything more durable than a software choice.
The correct starting point is not a tool. It is a taxonomy: a principled classification of data by its fundamental nature. Not by subject matter — “medical,” “financial,” “legal” — which is a retrieval convenience, not an ontological distinction. But by what kind of thing the data is, and how that nature determines how it should be stored, related, and retrieved.
felixOrg uses a three-part taxonomy: temporal items, structural items, and knowledge items. These are not categories I invented; they reflect distinctions that have always been implicit in how information systems are designed and how professionals think about records. Making them explicit is what transforms an ad hoc file system into an architecture.
Temporal Items: The Immutable Record
A temporal item is a representation of something that happened. A dated transaction, a medical event, a signed agreement, a communication, a system change, a financial entry: these are records of specific occurrences in the world, tied to a moment in time that cannot be altered.
The defining characteristic of a temporal item is its *immutability*. The event it records has already occurred. A surgical procedure scheduled for 20 March 2026 either happened or it did not; once it happened, that fact is fixed. The record can be annotated, supplemented, corrected, or contextualized — but the event itself is outside the reach of revision. This is what distinguishes a temporal item from a structural item that merely carries a creation date: the date is not an attribute of the record’s administrative metadata but the essential identity of the thing the record represents.
In felixOrg, temporal items include the surgical events of March 2026, discharge instructions tied to specific dates, provider interactions anchored to specific encounters, dated financial entries, and the Aeon Timeline events that mirror significant occurrences alongside the DEVONthink record. Each is anchored to a moment. Each will never become a different moment. Their retrieval logic follows from this: you find them by *when* they occurred, by *who* was involved, by *what* event class they belong to. They do not change; they accumulate.
The practical consequence is significant. Temporal items age in a specific way: they become more valuable as evidence and less valuable as operational guides. A discharge instruction from 2026 is irrelevant to a clinical decision in 2029, but it may be crucial to a legal or administrative proceeding. An architecture that treats temporal items the same as structural or knowledge items will fail to preserve them with appropriate fidelity and will fail to surface them with appropriate precision.
Structural Items: The Standing Configuration
A structural item is a representation of something that exists — not at a moment, but over time. Actors, organizations, roles, facilities, devices, services, relationships: these are the entities and configurations that constitute an operating environment. They persist across events. They predate specific transactions and will outlast them. They change, but their change is not an event; it is a revision of standing fact.
The distinction from temporal items is subtle but important. A physician is a structural item — my surgeon is an actor who exists in the model independent of any particular appointment. The appointment itself — a consultation on a specific date — is a temporal item. The physician persists; the appointment is fixed in time. The relationship between them (physician performs consultation) is a structural relationship that exists as a pattern, while each instance of that pattern is a temporal event.
In felixOrg, structural items populate the ArchiMate model in significant depth: the network of physicians, institutions, and care facilities involved in a surgical episode; the devices and infrastructure of the primary workstation; the applications and data objects that constitute the software stack; the household facilities and equipment managed under felixOrg’s operational scope. These entities were modeled not because they participated in a specific event but because they constitute the standing architecture of a life that are useful for understanding and communication. They require a different representation from temporal items — typed, related, layered — because their nature is relational rather than evidentiary.
Structural items do change. A device is retired; a provider relationship ends; a household configuration is updated. When they change, the model is revised — not by adding a new record alongside the old one, as with temporal items, but by updating the standing representation. This revisability is precisely what distinguishes them from temporal items: the past state of a structural item is generally less important than its current state, while the past state of a temporal item is its permanent and irreducible content.
Knowledge Items: The Synthesized Understanding
A knowledge item is a representation of something that is understood — not observed directly (temporal) or configured as standing fact (structural), but synthesized from research, analysis, reflection, or expertise. Research notes, analytical frameworks, reference documents, strategic syntheses, clinical assessments: these are records of conclusions reached, not events that occurred or entities that exist.
Knowledge items are the most intellectually complex of the three types, and the most prone to misclassification. A clinical assessment — the formal finding of a spinal condition — might appear to be a temporal item (it was produced on a specific date) or a structural item (it describes a persistent anatomical condition). In felixOrg, it is classified as a knowledge item: it synthesizes diagnostic imaging and clinical examination into a standing medical understanding that informs subsequent decisions. The date of the assessment is an attribute, not the identity of the item; the condition it describes is structural, but the assessment itself is a physician’s synthesis. What matters for retrieval is not when it was written or who is the subject, but what it concludes and what decisions it informs.
The distinguishing features of knowledge items are their *constructedness* and their *revisability*. Unlike temporal items, they can and should be revised when understanding deepens or evidence changes. Unlike structural items, they are not simply facts about entities; they are conclusions drawn by an intelligence — human or artificial — from evidence. In felixOrg, knowledge items include reference documents authored by Plato, research notes assembled in DEVONthink, and the written output of analytical sessions: text that will outlive the specific context that produced it and continue to inform decisions long after the session that generated it is archived.
Three Types, Three Temporalities
The taxonomy is not merely a filing convenience. The three types differ in their fundamental relationship to time, and that difference has consequences for how they must be stored, related, and retrieved.
Temporal items are *point-in-time*: they record events that exist at a specific location in the past and do not move. Their retrieval is chronological, associative, and evidentiary. They accumulate without revision; any correction is itself a new temporal record appended to the original, not a replacement of it.
Structural items are *continuant*: they represent entities that persist through time, acquiring attributes and relationships as time passes. Their retrieval is by identity and role — by who or what something is, not when it happened. They are revised as facts change, and only the current state ordinarily needs to be preserved.
Knowledge items are *constructed*: they emerge from synthesis and can be revised as understanding improves. Their retrieval is thematic and conceptual — by what they say and what questions they answer. They improve with iteration; an earlier version is superseded by a later one rather than preserved alongside it as an independent record.
A system that conflates these types — storing a surgical event as if it were a standing entity, or treating a synthesized reference document as if it were an immutable record — will produce confusion that compounds over time. The folder system fails partly for this reason: it provides no mechanism for making the distinction. Everything is a file, and all files are equal. The taxonomy reasserts the differences that the data itself demands.
The Taxonomy as First Constraint
Why does this taxonomy precede tooling? Because every tool embodies assumptions about the nature of the data it manages, and those assumptions must be tested against the taxonomy before a tool is selected or configured.
DEVONthink, as I will examine in later posts, is a strong store for temporal and knowledge items: its full-text search, flexible tagging, and replication features serve documents whose retrieval is evidentiary and thematic. It is a less natural fit for structural items — entities and their typed, directed relationships — which require a modeling language rather than a document database. ArchiMate fills that role. The selection of both tools, and the principled decision about what each one holds, follows directly from the taxonomy. Without the taxonomy, the tool selection is a preference; with it, the tool selection is constrained and justified.
The taxonomy also constrains tagging, naming conventions, and the decomposition of data into operational storage zones. Before a tag can be applied, before a bucket can be assigned, before a database can receive an item, one must answer the prior question: what kind of thing is this?
*The next post examines tagging in depth — how the `::` prefix convention establishes a controlled vocabulary distinct from freeform labeling, how tags interact with the bucket structure to enable precision retrieval, and what it means to distinguish tagging from the relational architecture maintained in ArchiMate