Getting the Words Right

Summary: Product development is not best understood as a collection of fixed artifacts moving through fixed stages. It is better understood as something unfolding over time.

We tend to model software product development as a collection of things,

passed across a fixed set of stages: goals, initiatives, epics, tickets. But the work does not behave that way. It unfolds. Discovery overlaps with delivery. Feedback reshapes priorities. What we are building, and why, changes as we learn. The process does not just move forward. It changes as it progresses. Even the context needed to understand the work is not fixed. It is produced through interaction, through the back-and-forth of people working through the situation together. This requires a different orientation. Instead of organizing around static artifacts, we focus on what is unfolding over time. Instead of fixed stages, we look at loops, interactions, and shifts in state. The goal is not to remove structure, but to use it in a way that stays closer to reality. To support learning, not mask it. To make work more legible without flattening it. To build representations that evolve with the system they describe.

Endurant vs. Perdurant

Summary: Use endurant for the thing that exists at a time, and perdurant for the process, event, or history that unfolds over time.

In ontology terms, an endurant is an entity that is wholly present whenever it exists. A perdurant is an entity that unfolds through time and therefore has temporal parts or phases rather than being wholly present at any one instant. (Note: If you are French, or speak another Romance language where endurant and perdurant already sound like they ought to mean something, this may start to feel almost too semantic. Fair enough. But this is not just wordplay. Some serious ontology people really did adopt these as technical terms. Here, they name a specific distinction between entities that are wholly present at a time and entities that unfold through time.) Other Names You May Hear Different modeling traditions use different words for roughly similar ideas. The mapping is not exact, but it helps orient readers: Ontology termRoughly similar names Endurantcontinuantin BFO, or everyday modeling terms likething, entity, object, asset, or resource Perdurantoccurrentin BFO, or terms like process, activity, occurrence, workflow, or episode Transition eventdomain event, state change event, orstatus change

Ontology termRoughly similar names Event historyevent log, audit trail, or event stream Statestatus, condition, ormode If you come from EventStorming or event-driven design, the easiest mental model is:

•the enduring business thing is the endurant •the process unfolding over time is the perdurant •the orange sticky-style business event is usually an event or transition event Diagram

•If you can take a time-slice or snapshot and still say “the whole thing is here now,” model it as an endurant.

•If the thing only exists by happening over an interval and can be divided into before/during/after, stages, or episodes, model it as a perdurant.

In Practical Modeling Terms Endurant An endurant is usually a thing, object, agent, artifact, or role-bearer. It is the kind of entity you can point to at a given moment, even if some of its properties change over time.

• It persists through time while remaining the same entity.

• It may change properties over time.

•It participates in events and processes, but is not itself the event or process.

•It is typically modeled as something you can identify at a given moment. Examples:

•a person •a forklift •a warehouse •a contract document •a customer account Perdurant A perdurant is usually an event, process, activity, episode, or occurrence. It is the kind of entity that only makes sense as something unfolding through time.

• It happens over time.

• It has temporal extent: a start, duration, and often an end.

• It can often be decomposed into phases, steps, or sub-events.

•Other entities participate in it. Examples:

•a delivery •a maintenance visit •a hiring process •a customer support call •a system outage Short Rule of Thumb •Endurant: “What is it?”

•Perdurant: “What happens?” Or:

• Endurant: exists at a time.

•Perdurant: occurs over time. Example Pair •Technician= endurant •Repair job= perdurant The technician is wholly present at each time at which the technician exists. The repair job is not wholly present at a single instant; it unfolds across diagnosis, parts replacement, testing, and completion. Events, States, and Transitions It is useful to distinguish the enduring thing from the events that affect it, because many modeling mistakes come from treating the entity and its unfolding history as if they were the same kind of thing.

• The endurant is the entity that has properties or states.

•The perdurant is the larger activity, process, or history unfolding over time.

• An event is a bounded occurrence within that history.

•A transition event is an event that changes the state of an endurant. Manufacturing Example •CNC machine= endurant •Production run= perdurant •Machine status change= event, more specifically a transition event •Idle,Running,Stopped,Maintenance= states or status values of the machine So the machine exists at a time, the production run unfolds over time, and the status change occurs at a specific time or over a very short interval. That distinction is what lets the model separate the thing being tracked from the change that happened to it.

Practical Modeling Rule

When something “changes at a certain time”, do not treat the change

itself as a property. Treat it as an event that results in a new property

value, so the model can preserve both the current state and the transition that produced it. For example:

•before the event, the machine has statusIdle •theMachineStatusChangeEventoccurs •after the event, the machine has statusRunning This lets you represent:

•when the change became effective •what the old value was •what the new value is •who made the change •why the change happened Useful Terms Depending on how formal or business-oriented you want to be, the “actual thing that happens” can be named in several different ways:

•event •sub-event •occurrence •state change event •transition event In most operational models, state change eventor transition event is the clearest term for a point-like change such as a status update, because those labels emphasize that something happened and that it changed the state of an enduring thing. Ontology Mapping In common foundational ontologies:

• DOLCE usesEndurantandPerdurant.

•BFO uses roughly corresponding terms:Continuantand Occurrent.

Why This Matters Operationally If you confuse the two, your model tends to blur:

•stable entities vs. time-bound activities •participants vs. the events they participate in •object attributes vs. process states That usually leads to poor queries, unclear event histories, and hard-tomaintain schemas, because the model stops distinguishing stable entities from the events and processes they participate in. Try This Now:

•Write down one thing in your organization that passes the endurant test: you can point to it at a moment in time and still say “the whole thing is here.” •Then write down one thing your organization talks about as if it were a thing, but that really makes more sense as something unfolding over time.

•Ask: what gets distorted when we treat the second one like the first?