Getting the Words Right

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:

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

Operational Difference

Use this test when modeling:

• 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 status Idle
• the MachineStatusChangeEvent occurs
• after the event, the machine has status Running

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 event or 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 uses Endurant and Perdurant.
• BFO uses roughly corresponding terms: Continuant and 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-to-maintain schemas, because the model stops distinguishing stable entities from the events and processes they participate in.