---
slug: entity_centered_modeling
name: Entity-Centered Modeling
one_liner: "Making persistent things — people, places, objects — the primary nodes that carry state and relations, with events derived as transitions between entity states — the entity-primary dual of event-centered modeling."
type: prime
schema_version: 2
status: density_v2_draft
categories: [computational, epistemic, structural]
origin_domain: data_modeling
alternate_origin_domains: [knowledge_representation, database_design, ontology_engineering]
aliases: [entity_primary_modeling, thing_centered_modeling, object_centered_schema, entity_relationship_modeling]
review_flags:
- "OPERATOR-DERIVED (op-01 dualization, sub-flavor 1b) — the primary-node-choice dual of `event_centered_modeling` along the what-is-the-integration-hub axis (entity-primary vs event-primary). Discovered in the op-01 full sweep 2026-07-03. Verified absent via search_prime + slug check; near-neighbor is the input prime, no exact-slug collision. STATUS: HOLD — pending owner curation."
- "Created 2026-07-03; STUB ONLY (frontmatter + Core Idea + Notes). Did NOT go through Phase-A triage. SI/SF/similarity grades are PROPOSER ESTIMATES pending triangulation. Body sections (Structural Signature onward) NOT yet written."
- "Phase-C action: re-similarity check vs event_centered_modeling / entity_relationship (as a possible unmarked-default non-prime) / object-orientation / state_vs_process to confirm it names a marked structure and does not collapse into 'the ordinary way'; if kept, draw the sibling (event_centered_modeling) and shared-parent (integration-hub-choice / primary-node-selection) edges at incorporation. one_liner must be synced to a v1 draft per CLAUDE.md before merge."
substrate_independence:
  composite_substrate_independence: 3
  domain_breadth: 3
  structural_abstraction: 4
  transfer_evidence: 2
  reasoning: 'The relation — choose persistent entities as the primary integration nodes, attach state and relations to them, and derive happenings as transitions of entity state — is a schema-shape choice on a graph of nodes and is genuinely medium-neutral, so structural abstraction is 4. It recurs across data modeling, knowledge graphs, object-oriented design, and arguably substance-based ontology in philosophy, giving domain breadth 3. Transfer evidence is weak (2) and this is the honest liability: entity-primary is so often the *unmarked default* schema choice that its cross-domain appearances are rarely flagged as an instance of a named pattern, making documented transfer sparse compared to a canonical structural prime; much of the evidence is "this is just how modeling usually works," which is exactly the risk the manifest flags.'
similarity_to_nearest_existing_prime:
  slug: event_centered_modeling
  similarity: 0.66
structural_framed:
  label: mixed-structural
  aggregate: 0.3
  criteria: {vocab_travels: 0.3, evaluative_weight: 0.2, institutional_origin: 0.3, human_practice_bound: 0.4, import_vs_recognize: 0.3}
  rationale: 'Choosing entities as the primary integration nodes is a relational schema structure carrying little normative content, so evaluative_weight is low. It leans toward the structural end but not fully: the notion of an "entity" and the modeling act are somewhat human-practice-bound (a modeler decides what counts as a persistent thing) and the term has a database/KR institutional flavor, keeping institutional_origin and human_practice_bound off zero. The core structure — attach state to persistent nodes, derive happenings as their transitions — recognizes across data schemas, object systems, and substance ontologies, so vocab_travels and import_vs_recognize sit low-to-mid, landing a mixed-structural aggregate around 0.3.'
phase_b_passes_completed: []
---
# Entity-Centered Modeling

## Core Idea

Entity-centered modeling is the structural choice to make *persistent things* — people, places, objects, accounts, organizations — the *primary nodes* through which everything else is connected, attaching state and relationships directly to those entities, and treating happenings as *transitions of entity state* rather than as first-class nodes in their own right. It is one pole of a single axis — *what is the primary integration hub of the schema* — whose opposite pole is `event_centered_modeling`. Where event-centered modeling makes bounded happenings (with time, place, participants, and transformation) the hub and reads an entity as a *projection over the events it participated in*, entity-centered modeling inverts the primacy: the *thing* is the durable anchor that persists across time, carries its own attributes, and refers to other things directly, while an event is derived — read off as the difference between two states of an entity, or as an edge decorating the entity graph rather than the node the graph is built on.

The load-bearing invariants are three. First, there is a *primary node type that persists*: entities are the objects with identity and continuity through time, so the schema's backbone is "what things exist and how do they relate," and querying "give me everything about *this thing*" is the cheap, native operation. Second, *state lives on the entity*: an entity's current attributes are stored directly and are immediately available, so the present is first-class and the past is derived (often lossily) rather than the other way round. Third, *change is a projection, not a primitive*: a happening is represented as a mutation, a relation, or a delta between states — the event does not have to carry its full role structure (time, place, participants, transformation) because it is subordinate to the entities it touches. The characteristic trade-off follows directly and is the exact inverse of the event-centered pole: entity-centered modeling makes *"the current state of a thing"* and *"everything about a thing"* fast, natural, and lossless, at the cost of making *history, provenance, and multi-participant happenings* awkward — the schema privileges *being* over *becoming*, so reconstructing "what happened, when, involving whom" requires extra machinery (audit logs, temporal tables, event sourcing) bolted onto a model whose native subject is the enduring thing, not the happening.

Read as a pattern rather than one field's convention, the same structure recurs wherever a representation must pick its primary node. In *database and information-system design* it is the classic entity-relationship / normalized-table schema, and in object-oriented design it is the object graph where behavior and state hang off persistent objects. In *knowledge representation* it is the entity-primary knowledge graph (nodes are things, edges are relations) as opposed to the reified-event graph. In *philosophical ontology* it is the substance-first stance — the world is fundamentally made of enduring things bearing properties, with events as derivative — set against a process-first ontology in which happenings are basic. Across these substrates the recognizable move is identical: elect the persistent thing as the node the model is organized around, gaining direct, lossless access to entities and their present state, and paying for it in the difficulty of representing time, history, and the many-participant happening as anything but a second-class citizen.

## Notes

**Provenance.** Produced by the op-01 dualization operator (sub-flavor 1b) as the primary-node-choice dual of `event_centered_modeling`, taken along the *what is the integration hub* axis (entity-primary vs event-primary). Single-flavor proposal (1b); the convergence signal is the tight, well-attested opposition in data-modeling and ontology practice (entity-first vs event-first is a live, named design fork), rather than multi-route independent rediscovery.

**For owner evaluation (keep/cut).** The manifest flags the decisive question directly and it should govern the decision: **this may be "the default view" rather than a named structure.** The case FOR keeping it: it is a clean pair-completion for `event_centered_modeling` — the corpus holds the marked, less-obvious event-primary pole, and an axis is only half-named while its default pole is unnamed; naming the default pole is often *precisely* what makes the axis visible as a choice rather than an assumption, and the sustaining content (state-on-entity, change-as-projection, being-over-becoming trade) is genuine and inverse-symmetric to the input. The case AGAINST / the risk: entity-primary modeling is the *unmarked, ambient default* — for most modelers it is simply "how you model," so it may fail the prime bar the way "the ordinary way of doing X" does: a prime should name a *structure you can recognize and choose against*, and if this candidate merely relabels the water everyone already swims in, it adds a slug without adding discriminating power. Two screens decide it. (1) **Default-collapse screen**: does the candidate carry content that a modeler could *not* already state as "the normal entity-relationship approach"? The strongest such content is the explicit *being-over-becoming trade* and the *history-is-second-class* consequence — if that survives as a nameable, chooseable property, keep; if it dissolves into "ER modeling," cut. (2) **Overlap screen**: check against any existing `entity_relationship`, object-orientation, or `state_vs_process` / substance-vs-process prime — this candidate must not duplicate an existing structural prime under a new name. Note the asymmetry with the disruptive/sustaining pair: there, both poles are marked; here, the risk is specifically that the *dual is the default*, which is a weaker case for primehood than the input prime enjoyed.

**At incorporation.** Re-run similarity vs `event_centered_modeling` (est. ~0.66) to confirm the sibling relation without collapse, and vs any entity-relationship / object-model / substance-vs-process slug to confirm this is not a rename of an existing prime or a non-prime default. If kept, draw the sibling edge to `event_centered_modeling` and a shared-parent edge to a primary-node-selection / integration-hub-choice parent (create it if absent — both poles are choices *of the same schema-shape decision*). Sync the `one_liner` to a v1 draft per CLAUDE.md before merge, keeping the entity/event one_liners mirror-symmetric so the hub-choice axis reads from either page.
