Paths as first-class artifacts

2026-03-02 01:08:24.861Z2026-03-02 01:17:45.499Z

A path is a named, purposeful journey through the
Event Model from a specific actor's perspective.
Paths are not informal descriptions or user stories
— they are typed design artifacts that exist in
LOGOS, are linked to the Event Model elements they
traverse, and carry their own lifecycle.

What a Path Is

A path traces a specific actor's journey through
the system to accomplish a specific goal. It is a
named sequence of slices — command slices and
projection slices — that together represent a
complete, meaningful interaction.

A path has:

A name — meaningful to the domain. Not
"user flow 3" but "Driver submits monthly
expense report" or "Admin reviews flagged
entry."
An actor — the swim lane persona whose
journey this is. The path belongs to that
actor.
A goal — what the actor is trying to
accomplish. The path is complete when the
goal is achieved or definitively not achieved.
A sequence of slices — the specific command
and projection slices traversed, in order, to
move from start to goal.
Example data — concrete values that flow
through every slice in the path.
A status — paths have a lifecycle. A path
can be identified, modeled, specified,
implemented, and verified.

Example Data

Adam Dymetrik's Event Modeling prescribes sample
data in the model. NEXUS extends this further —
example data is integral to every path, not
optional decoration.

Each path carries concrete, realistic values that
flow through every slice it traverses. Not abstract
placeholders like "username" and "amount" — real
named values: "location='Pilot Travel Center',
machine='Washer', qty=2, price=$3.75,
payment='Card'".

Example data serves several roles simultaneously:

Communication — concrete examples create a
shared vocabulary between everyone involved.
When a developer references "the driver submits
at a truck stop path," the example data makes
that path unambiguous. No interpretation needed.

Design validation — working through real
values during design reveals gaps and edge cases
that abstract modeling misses. If the example
data cannot flow cleanly through every slice,
the design has a problem.

Test data — the same example data used
during design becomes the given-when-then test
cases during implementation. The given clause
establishes state using path example data. The
when clause executes commands with path example
data. The then clause asserts events and state
match the path. Design and test are the same
artifact.

Minimal Path Coverage

Paths are not exhaustive walkthroughs of every
possible interaction. They are minimal — each
path exists only to cover something new. Like
minimal test cases for branch coverage: one
path per unique branch, no redundant paths.

For a simple entry form the paths might be:

Happy path — standard entry, all fields, submit
GPS auto-fill path — location filled by GPS
Validation failure path — submit with missing
required field
Quick-fill path — price selected from preset

Each path covers one unique branch. Together
they cover all designed behavior. No path
duplicates what another already covers.

The goal: as many paths as needed to cover all
designed cases, minimal enough to do only that.

Penpot as Path Documentation

Each path is documented as a Penpot prototype —
a linear sequence of screens connected by
prototype links, with one clickable action per
screen. The one action this path takes. The
example data visible in the UI.

Following the prototype is walking the path.

This makes the Penpot path prototype a single
source of truth for four things simultaneously:

Visual spec — what it looks like
Behavior spec — what happens at each step
Test data — the example values at each step
Test case — the path itself is the scenario

See: NEXUS → Penpot as dual source of truth —
Event Model and UI.

Why Paths Are First-Class

In conventional Event Modeling, paths are implicit.
The Event Model shows the slices. A reader infers
the journeys by tracing through the timeline. The
journeys are not named, not typed, not tracked —
they exist only as understanding in someone's head.

NEXUS makes paths explicit because:

Intent becomes traceable. A named path connects
a human goal to the specific slices that serve it.
Six months later, the question "why does this slice
exist?" has an answer — it serves this path, which
serves this actor trying to accomplish this goal.

Gaps become visible. If a path cannot be
completed because a slice is missing, that gap is
a named, findable gap — not an unnamed hole
discovered during implementation or testing.

Specs attach to paths. A Spec topic in LOGOS
is linked to the path it implements. The path is
the unit that connects design to implementation.

Testing has a target. A path with example data
is a testable unit. Does this actor, starting here,
following these slices with this data, reach this
goal? Path-based testing is behavioral testing at
the right level of abstraction.

The EMviewer

The EMviewer is a tool for navigating an Event
Model through its paths. It operates in two modes:

Predefined path mode — select a path from the
defined set. The viewer navigates through the
model automatically with sample data pre-filled,
showing the exact sequence of events generated.
This is documentation and test mode — walking
a designed, validated path.

Choose your own adventure mode — start at
initial state and navigate freely. Each decision
point shows the available branches. Events are
generated based on choices. This is exploration
and learning mode — discovering the system by
traversing it.

Fidelity Levels

The Event Model has selectable detail levels.
Different stakeholders need different amounts
of detail from the same model:

Executive level — the happy path through
the model showing business needs and outcomes.
This is closest to Adam Dymetrik's original
Event Modeling intent — the high-level story
of what the system does and why it matters.

UX level — screen interactions, click
sequences, form flows. The detail a UX designer
or product person needs to understand and
evaluate the user experience.

Domain level — the steps and events
relevant to a specific workflow or role. A
shipping clerk enables shipping workflow detail
and sees their domain clearly without needing
technical implementation detail.

Technical level — implementation detail
relevant to developers. Command handlers, event
types, projection logic, error paths.

Each viewer enables the fidelity level relevant
to them. The model is the same — the lens changes.
A new team member can learn the system at executive
level first, then progressively enable more detail
as their understanding deepens.

Paths and Bug Tracing

Paths enable a capability that transforms debugging:
exact reproduction through path playback.

When a user experiences an issue, their actual
event sequence — the literal path they took through
the system — is the bug report. Not a description
of what happened. The actual sequence of events
the system recorded as they traversed it.

A path viewer replays that sequence event by event.
The developer observes exactly what happened —
which command produced which event, which projection
consumed which events, which state the UI derived.
The exact failure point is observable, not inferred.

This requires the user's consent — it is their
event data and they share it willingly. With consent,
the developer loads the path and watches it play.

Cross-user pattern analysis extends this further.
Multiple users experiencing the same issue will
have paths that converge at the same failure point
even if they arrived there differently. Systemic
issues become visible across paths that individual
bug reports obscure.

The bug, once found, becomes a documented path in
LOGOS — linked to the failure point, linked to the
fix, permanently part of the knowledge base.

Path Lifecycle

A path moves through states:

Identified — named, actor and goal defined.
Slices not yet fully modeled.

Modeled — traced through the Event Model.
Every slice identified. Example data defined.
Gaps visible.

Specified — slices have Spec topics in LOGOS.
Ready for implementation.

Implemented — slices are built. Path can be
traversed in the running system.

Verified — tested end to end with example
data. Actor can accomplish the goal.

Paths in LOGOS

Each path is a topic in the relevant project
category in LOGOS. The topic contains the path
definition, example data, links to the Event
Model elements it traverses, links to the Spec
topics for each slice, and status. The path topic
is the thread that connects design intent to
implementation reality.

See: Specs and the design-before-implementation
discipline.