The Architected Self 03
Decomposition: Mapping Items to Operational Buckets
*#architected_self, Post 3 of 10*
---
From Taxonomy to Operation
The taxonomy established in the previous post answers a philosophical question: what kind of thing is this data? The present post answers its operational counterpart: where does it go?
The distance between these two questions is not trivial. A taxonomy classifies data in the abstract; decomposition routes it to a specific organizational structure in a specific system. Without a principled mapping from one to the other, the taxonomy is an intellectual exercise — useful for thinking, useless for managing. The decomposition step is where the philosophy becomes practice.
In felixOrg, incoming data is routed through five operational buckets before it enters the DEVONthink repository. These buckets — `::actor_bucket`, `::facility_bucket`, `::org_bucket`, `::structural_bucket`, and `::temporal_bucket` — are not folders in the conventional sense. They are typed ingestion zones, each designed to receive a specific class of items as defined by the taxonomy, and each imposing a normalization discipline on whatever enters it. A sixth named group, `_data_lake`, sits alongside them for items that resist clean classification — a subject addressed at the end of this post.
Maintainability as the Primary Constraint
Before describing how the decomposition works, one design requirement must be stated explicitly, because it governs every decision that follows: the architecture must be easy to maintain.
An elaborate system that demands significant effort to operate is not an information architecture — it is a second job. The measures that distinguish deliberate architecture from ad hoc accumulation are worth adopting only if their cost at ingestion time is low enough to be sustained across a professional lifetime. If classifying an incoming document requires ten minutes of deliberation, the system will be abandoned within a year. If it requires thirty seconds, the system becomes habitual — and habits, unlike procedures, compound.
Every element of the felixOrg ingestion pipeline is optimized for this constraint. The five buckets are few enough to be memorized immediately; the naming convention reduces the decision to three elements; the data lake provides a legitimate exit for anything that resists quick classification. The architecture builds out the structural model — populating the ArchiMate context that later posts examine — not by demanding comprehensive annotation at the moment of capture, but by accumulating well-routed, consistently named items whose structure emerges from the routing discipline itself.
Reduced friction at ingestion and a growing, useful model are not competing goals. They are the same goal, approached from two directions.
The Five Buckets
The `::temporal_bucket` is the most straightforward mapping from the taxonomy. It receives date-anchored events and records: surgical procedures, provider encounters, financial transactions, dated communications, and any other item whose identity is constituted by when it occurred. Items in this bucket do not change after ingestion; they accumulate. The bucket is ordered chronologically rather than alphabetically, because time is the primary retrieval dimension for temporal items.
The `::org_bucket`, `::actor_bucket`, and `::facility_bucket` together receive the structural items from the taxonomy, split along distinctions that the taxonomy itself does not make explicit. `::org_bucket` receives organizational and institutional structural items: businesses, hospitals, government agencies, service providers, and other collective entities. `::actor_bucket` receives individual actors: named persons, agents, and roles held by identifiable individuals. The split between organizations and actors is operationally useful because they have different documentation profiles, different relationship types, and different retrieval patterns. A medical record of a specific encounter belongs under the relevant physician in `::actor_bucket`; an insurance policy belongs under a carrier in `::org_bucket`.
`::facility_bucket` receives physical spaces: rooms, buildings, addresses, campuses, and other locations that exist as named places in the operational environment. Facilities are structurally distinct from the organizations that occupy them and the actors who use them. A hospital is an organization in `::org_bucket`; the rehabilitation wing on the third floor of that hospital is a facility in `::facility_bucket`. Conflating the two produces retrieval failures when the question is specifically about a location rather than an institution — and those questions arise more often than one might expect in a system that tracks medical care, household management, and physical infrastructure simultaneously.
`::structural_bucket` receives standing configurations that are neither organizations, actors, nor facilities: system architectures, operational processes, physical assets, and records of system states that need to be preserved without being attributed to a specific person, institution, or location. In a personal information system of any complexity, there is always a residual class of structural items that resist personification — network topologies, operational procedures, device configurations, equipment owned by no single organization — and `::structural_bucket` is their home.
Knowledge items do not map exclusively to any single bucket. They are typically homed in whichever bucket their primary subject belongs to — a clinical synthesis document lives under the relevant physician in `::actor_bucket`; a reference document about a vendor lives in `::org_bucket` — or they reside in a dedicated area of DEVONthink outside the five-bucket ingestion pipeline, written directly into the repository rather than arriving through a scan or import workflow. The taxonomy distinguishes them by nature; the bucket system routes them pragmatically by association.
The Data Lake
Alongside the five buckets sits `_data_lake`: a named group for items that resist classification. The data lake is not a failure of the taxonomy. It is the taxonomy’s acknowledgment of its own limits — and of the practical limits of time.
Not every incoming item arrives with its classification obvious. A large batch of legacy documents inherited from a previous system, a raw production of records before review, a collection of scanned materials whose dates and subjects have not yet been verified: these are data lake items. They exist; they need to be preserved; their classification is deferred, not abandoned.
The discipline the data lake requires is the discipline of non-permanence. Items in `_data_lake` have an implicit time to live. They should be reviewed, classified, and migrated into the appropriate bucket on a regular cadence. The lake is a buffer, not a destination. A data lake that grows without bound is a taxonomy that is collapsing — items are going in and not coming out, and the residual category is slowly consuming the system it was meant to protect. The signal that the lake has become a problem is when it begins to be used as a retrieval source rather than a staging area.
Normalization at the Gate
The bucket assigns a destination; normalization disciplines the item before it arrives. Every item entering felixOrg through the ingestion pipeline is named according to a standard convention: *Name, DTG, 2-3 word Description.*
The DTG — date-time group, a compact integer string encoding date and time in the military convention — anchors every item temporally at the moment of capture or at the moment of the underlying event, depending on the item type. For a scanned document, the DTG reflects the date on the document rather than the scan date: a discharge instruction dated 29 March 2026 carries that date in its name regardless of when it was digitized. For a communication or system log entry, the DTG reflects the event. The discipline ensures that the temporal anchor is always the event’s date, not the filing date — a distinction that matters enormously when reconstructing a chronology years later.
The two-to-three-word description constrains naming precision. It forces a commitment to a characterization specific enough to be meaningful at retrieval but brief enough to remain scannable in a file listing. “Pre-Op Consult,” “Discharge Instructions,” “Firmware Procedure” — these are descriptions, not subjects. They say what the document does, not merely what it concerns. The distinction is not cosmetic: a subject is indexable by search; a description is legible in a file listing without opening the document. Both are necessary; the naming convention captures the description. Search captures the subject.
For scanned PDF documents specifically, tags can be assigned at scan time — at the moment the document enters the system through the scanner workflow. This is the only point in the pipeline where tagging and ingestion are simultaneous. Documents created or received digitally are tagged after ingestion, during a subsequent review step. Tagging at scan time is an efficiency measure for a high-volume intake workflow, not a different category of operation.
The Replication Rule
The taxonomy holds that temporal and structural items are genuinely different in nature. The bucket system enforces this difference — but it also acknowledges that real items sometimes have legitimate claims on both categories. A record of a specific medical encounter is a temporal item: it happened on a specific date, and that date is its identity. But it is also directly relevant to the structural record of the physician who conducted the encounter. A purely positional system would force a false choice: the record goes in `::temporal_bucket` or in `::actor_bucket`, not both.
DEVONthink’s replication feature resolves this without duplication. A replicated item appears in multiple groups simultaneously; it is one record with multiple locations. felixOrg governs replication with a directional rule: temporal items may be replicated into structural buckets, but structural items may not be replicated into `::temporal_bucket`.
The asymmetry is principled. A temporal record of a specific encounter is appropriately surfaced within an actor’s structural group — it provides provenance and context for the standing relationship. But a structural item — an actor’s profile, a standing role, a persistent configuration — has no place in a temporal bucket ordered by date, because the structural item is not an event. Placing it there misrepresents its nature and corrupts the temporal bucket’s chronological coherence.
The rule is simple to state and occasionally difficult to apply in practice. Its difficulty, when it arises, is usually diagnostic: the item resisting clean assignment often turns out to be a knowledge item misread as temporal or structural, and the right response is reclassification rather than relaxation of the rule.
The Ambiguity Principle
Tags — examined in depth in the next post — cannot always be assigned with confidence at ingestion time. The subject of an item may span categories; the appropriate classification may depend on context not yet available; the controlled vocabulary may not yet contain a term that fits precisely. felixOrg’s response to this situation is deliberate: when there is ambiguity about the appropriate tag category, no tag is applied.
This is a harder discipline than it sounds. The impulse in any classification system is to assign a best-guess category and move on. Best-guess categorization feels efficient; in practice, it produces a slow accumulation of misclassified items that degrade retrieval precision without any single visible failure. A document mistagged once is a minor error. A thousand documents mistagged over a decade is a classification system that no longer means what it says.
The ambiguity principle treats an untagged item as preferable to an incorrectly tagged one. An untagged item is still retrievable by its content and its normalized name; full-text search does not require a tag to surface it. An incorrectly tagged item is actively misleading: it appears in tag-scoped queries where it does not belong and fails to appear where it does. The discipline costs nothing at retrieval time and preserves everything at classification time.
Decomposition as Discipline
The five-bucket system, the data lake, and their normalization rules are not overhead imposed on a natural process. They are the mechanism by which the taxonomy becomes durable.
A folder system defers classification: the user creates a folder when they need one, names it according to the convention of the moment, and populates it with whatever seems to fit. The decisions are local and immediate; their consequences are systemic and long-term. Decomposition eliminates that deferral. Every incoming item must answer the same set of questions before it enters the repository: what type of thing is this, which bucket does it belong to — or does it go to `_data_lake` temporarily — what is its normalized name and DTG, and what tag, if any is unambiguously appropriate, applies?
The discipline is imposed at the gate, not retroactively. The payoff is a repository whose contents are searchable, browsable, and auditable in ways that an ad hoc accumulation cannot match. The cost is a moment of considered classification at ingestion. The benefit is every subsequent interaction with the repository for the life of the system.
*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 ArchiMat.*