Intent defines the starting semantic.
Trajectory defines the behavioral evolution.
Destination defines the expected terminal state.

Trajectory-Driven Development (T-DD) is a proposed software development method in which the central unit of specification is no longer exclusively the code, test, API, isolated requirement, or final system state, but instead the behavioral trajectory that leads an intent to a verifiable destination.

The implementation is treated as a technical projection of this specification.

The repository that currently contains the experimental implementation of this concept still uses the historical name Intent-Trajectory-Driven-Development. The current documentation already presents the formulation Trajectory-Driven Development (T-DD) and the chain:

DESTINY ↓ INTENT ↓ BEHAVIOR ↓ EVIDENCE ↓ CONTRACT ↓ STATE ↓ ACTOR ↓ SKILL ↓ TRAJECTORY ↓ DSL ↓ IMPLEMENTATION 

Current canonical source: suissa/Intent-Trajectory-Driven-Development

The objective of this document is to semantically formalize this proposal, relate it to existing disciplines, and establish which parts constitute a synthesis of existing knowledge and which parts constitute the specific contribution of T-DD.

1. The problem T-DD attempts to solve

A large part of traditional development practices starts from some intermediate technical artifact:

API ↓ schema ↓ database ↓ route ↓ service ↓ UI ↓ test 

or:

requirement ↓ implementation ↓ test 

or even:

user story ↓ BDD scenario ↓ implementation ↓ acceptance test 

These approaches are extremely useful, but there is a question that comes before them:

What exactly is the behavior we are trying to accomplish, through which trajectory, under which conditions, with which actors, producing which evidence, and reaching which terminal state?

This question becomes particularly important in systems that are:

• distributed;
• event-driven;
• conversational;
• multi-agent;
• autonomous;
• reactive;
• workflow-based;
• composed of multiple actors;
• required to explain decisions;
• required to historically reconstruct behavior;
• or in which the final state is not sufficient to determine whether the behavior was correct.

T-DD proposes that the specification be progressively constructed until the implementation can be considered a verifiable projection of the declared trajectory.

2. What T-DD is and what it is not

T-DD is not simply:

• TDD under another name;
• BDD;
• workflow engine;
• state machine;
• process mining;
• event sourcing;
• requirements engineering;
• model-driven development;
• formal verification;
• agent orchestration.

It uses ideas from these areas and seeks to integrate them around a common abstraction:

semantic trajectory 

The fundamental distinction is:

Traditional TDD: test → implementation → refactoring BDD: behavior → scenario → implementation → verification T-DD: destiny → intent → behavior → evidence → contract → state → authority → capability → trajectory → implementation → observation → comparison → conformance 

The test still exists.

The contract still exists.

The state machine still exists.

The events still exist.

The difference is that they cease to be independent artifacts and become different projections of the same semantic specification.

3. Semantic definition

A compact definition can be given as:

T-DD := Development(Declaration, Refinement, Execution, Observation, Conformance) 

where:

Declaration = desired semantic specification Refinement = monotonic increase in specificity Execution = realization of the specification Observation = evidence produced by execution Conformance = relationship between declared trajectory and observed trajectory 

A T-DD specification can be represented as:

Σ = ⟨D, I, B, E, C, S, A, K, T, X⟩ 

where:

The implementation:

P 

is considered conformant when:

P ⊨ T 

and the trajectory satisfies the refinement relationships:

T ⊨ B B ⊨ I I ⊨ D 

Therefore:

P ⊨ T ⊨ B ⊨ I ⊨ D 

This expression is one of the central formulations of T-DD.

It does not mean that a human intention can be mathematically proven in its entirety. It means that, once semantically operationalized, each layer must satisfy the constraints declared by the previous layer.

4. The distinction between Destiny, Intent, and Trajectory

One of the reasons for separating these concepts is that they answer different questions.

Destiny

Answers:

Where do we need to get?

Example:

customer requests delivery → delivery executed → courier paid 

Formally:

D = {requested, paid, assigned, tracked, delivered, settled} 

The destination is not necessarily a single state variable. It can be a conjunction of terminal conditions.

Intent

Answers:

What is someone trying to accomplish?

Example:

customer wants delivery 

or:

customer → deliver package from A to B 

Ajzen's Theory of Planned Behavior provides an important foundation for separating intention from behavior: intentions are important antecedents of behavior, although they are not equivalent to behavior as performed. The literature also emphasizes the role of perceived control and other factors in the transition from intention to action.

T-DD makes use of this distinction, but transforms it into an engineering question:

Intent ≠ Behavior 

An intent may be:

"I want to make a delivery" 

without containing:

origin destination price payment courier delivery code 

Therefore:

intent valid ≠ execution ready 

This distinction is essential in conversational systems.

Trajectory

Answers:

How does intent become observable behavior over time?

Example:

Intent ↓ collect addresses ↓ discover couriers ↓ select courier ↓ request payment ↓ confirm payment ↓ release delivery ↓ track ↓ validate delivery ↓ settle courier 

Therefore:

Intent = semantic starting point Destination = desired terminal condition Trajectory = evolution between them 

5. Trajectory as a mathematical object

In dynamic systems, a trajectory can be understood as the evolution of a state over a temporal domain.

A simple abstraction:

τ : T → S 

where:

T = temporal domain S = state space τ(t) = state observed at instant t 

For software, we can enrich this definition:

τ = ⟨(s₀,a₀,e₀,t₀), (s₁,a₁,e₁,t₁), ... (sₙ,aₙ,eₙ,tₙ)⟩ 

where:

s = state a = action e = evidence t = time 

A trajectory therefore ceases to be simply:

A → B → C 

and becomes:

(state, actor, action, evidence, time) 

This structure is much closer to what distributed systems actually need to record.

6. Relationship with state machines

The State component of T-DD has a direct relationship with state machines and, particularly, with Statecharts.

Harel showed that statecharts can represent complex discrete systems by incorporating hierarchy, concurrency, and communication, making behavioral specification more compact and expressive.

A T-DD model can be:

STATE delivery { requested collecting searching assigned awaiting_payment paid active arriving delivered settled failed } 

And:

FLOW delivery { requested → collecting collecting → searching searching → assigned assigned → awaiting_payment awaiting_payment → paid paid → active active → arriving arriving → delivered delivered → settled } 

This makes it possible to express:

awaiting_payment → paid 

only when:

payment.confirmed = true 

T-DD therefore does not replace state machines.

It incorporates them as one dimension of the trajectory.

7. Relationship with temporal logic

A trajectory naturally introduces a temporal dimension.

Consider:

payment.requested 

and:

payment.confirmed 

It is not enough for both to be true.

We need to establish:

payment.requested precedes payment.confirmed 

And:

delivery.released 

cannot occur before:

payment.confirmed 

These relationships are close to temporal logic.

Linear temporal logic and model checking provide formal methods for verifying properties over sequences of states and computations. The work of Pnueli, Clarke, Emerson, and Sifakis established fundamental foundations of this field.

T-DD can therefore transform:

X: ¬release(payment≠confirmed) 

into a verifiable temporal property.

For example, conceptually:

G(release → previously(payment_confirmed)) 

where G can represent a property that must be true globally throughout the trajectory.

A future implementation of a T-DD verifier can transform these properties into formal temporal formulas.

8. Relationship with Hoare logic

Hoare logic introduced a formal way of reasoning about program properties using preconditions, commands, and postconditions. Hoare's seminal 1969 work established this axiomatic foundation for reasoning about program correctness.

A T-DD operation:

SKILL confirm_payment { in: payment inv: payment.valid out: payment.confirmed } 

can be conceptually approximated by:

{ payment.valid } confirm_payment() { payment.confirmed } 

But T-DD adds dimensions that a traditional Hoare triple does not directly represent:

actor evidence trajectory position temporal relation business destiny semantic intent 

Thus:

Hoare Logic ↓ correctness of program state transformation T-DD ↓ correctness of semantic trajectory 

Hoare logic can be a verification mechanism for parts of T-DD.

9. Relationship with Design by Contract

The Contract component has a direct relationship with Design by Contract.

Meyer formalized Design by Contract as an approach to building reliable software using contracts and assertions to make operating conditions explicit.

A T-DD contract can be:

CONTRACT delivery.complete { in: code, location inv: code = valid ∧ location = dropoff } 

This defines:

preconditions postconditions invariants failure conditions 

The difference lies in the level of integration.

In T-DD:

Contract 

is not an isolated artifact.

It belongs to the trajectory:

Intent ↓ Behavior ↓ Contract ↓ State ↓ Trajectory 

Consequently, a contract can be used by:

• runtime;
• agent;
• code generator;
• test generator;
• observability;
• verifier;
• simulator;
• process miner.

10. Relationship with Requirements Engineering

Requirements Engineering traditionally seeks to capture what the system must accomplish and preserve the relationship between requirements and technical artifacts.

The problem of traceability is old and well documented. Gotel and Finkelstein demonstrated that requirements traceability involves both the period before specification and the period after specification, and that important problems arise when initial traceability is lost.

T-DD can be interpreted as an attempt to make this traceability structural:

DESTINY ↕ INTENT ↕ BEHAVIOR ↕ EVIDENCE ↕ CONTRACT ↕ STATE ↕ ACTOR ↕ SKILL ↕ TRAJECTORY ↕ IMPLEMENTATION 

Thus, instead of an external matrix:

Requirement → Design → Code → Test 

we have a semantic chain in which each layer has its own identity.

This makes it possible to ask:

Which code implements this Skill? 

or:

Which Skill realizes this Behavior? 

or:

Which Intent originated this Behavior? 

or:

Which Destiny depends on this Intent? 

or:

Which evidence proves that this intent was realized? 

This chain is a direct application of the traceability principle, but elevated into an explicit semantic structure.

11. Relationship with Goal-Oriented Requirements Engineering

The Goal-Oriented Requirements Engineering literature has worked for decades with the idea of deriving requirements from goals.

Van Lamsweerde, for example, extensively developed the goal-oriented approach to requirements engineering. Goal-oriented Requirements Engineering: a guided tour

T-DD has a direct relationship:

Goal ↓ Destiny ↓ Intent ↓ Behavior 

The proposed difference lies in the treatment of the temporal dimension.

A goal can be:

deliver package 

T-DD additionally asks:

how will this goal be realized? what intermediate states exist? which actors can produce each transition? what evidence proves each step? which trajectories are allowed? which trajectories are forbidden? 

This brings T-DD close to a combination of:

Goal-oriented RE + State-based modeling + Process modeling + Trace semantics + Conformance checking 

12. A particularly important connection: Intent Mining

There is a research line surprisingly close to the concept.

Research on intentional process mining seeks to discover intentions and strategies from process logs.

Khodabandelou et al. presented work on discovering intentional models from logs, including the use of Hidden Markov Models to infer participants' intentions and strategies. Unsupervised discovery of intentional process models from event logs

Another systematic review explicitly connects:

event logs → processes → goals 

and documents the relationship between process mining, intention mining, and goal-oriented requirements engineering. From event logs to goals: a systematic literature review of goal-oriented process mining

This is extremely relevant to T-DD.

The traditional direction of process mining is:

OBSERVED TRAJECTORIES ↓ PROCESS MODEL 

While T-DD proposes:

DECLARED TRAJECTORY ↓ IMPLEMENTATION ↓ OBSERVED TRAJECTORY ↓ CONFORMANCE 

We therefore have two complementary operations:

Process Mining: events → infer model T-DD: model → expected events 

And in the future:

T-DD + Process Mining declared trajectory ↓ executed system ↓ observed trajectory ↓ alignment ↓ conformance / deviation / repair 

This is one of the strongest scientific foundations for the concept.

13. Relationship with Process Mining

Process mining operates at the intersection of:

process models + event data 

The literature of van der Aalst establishes three major activities:

discovery conformance enhancement 

and uses event logs to discover or analyze real processes.

In T-DD:

DECLARED TRAJECTORY 

is an expected process.

The system produces:

OBSERVED TRAJECTORY 

The comparison:

expected ↔ observed 

is a conformance problem.

Van der Aalst and collaborators specifically studied replaying historical traces over process models for conformance and performance analysis. Replaying history on process models for conformance checking and performance analysis

Therefore, a future implementation of T-DD can use process mining techniques to answer:

Does the actual trajectory correspond to the declared trajectory? 

14. Relationship with Event Sourcing

Event Sourcing records state changes as a sequence of events, making it possible to reconstruct previous states and answer not only "where are we?" but also "how did we get here?" Fowler describes precisely this difference between querying the current state and preserving the historical sequence of changes.

This is extremely close to the idea of trajectory.

However:

Event Sourcing = historical persistence mechanism T-DD = specification and development method 

Event Sourcing can provide the raw material for:

ObservedTrajectory 

but does not itself define:

Intent Destiny Contract Actor Skill ExpectedTrajectory 

Therefore:

T-DD + Event Sourcing = declared semantics + historical execution 

15. Current state is not trajectory

This distinction is fundamental.

Imagine two systems that ended like this:

delivery.status = settled 

Both have the same final state.

But:

Trajectory A

requested → assigned → paid → active → delivered → settled 

Trajectory B

requested → assigned → settled 

The final state is the same:

settled 

The semantics are completely different.

The second system may have violated:

payment.confirmed delivery.completed delivery.code.validated 

Therefore:

State(t_final) 

is not sufficient to determine:

CorrectTrajectory 

This is one of the central reasons to treat trajectory as a first-class artifact.

16. Relationship with Behavior-Driven Development

BDD brings business, development, and testing closer through executable behavior.

The BDD literature describes precisely the intention of expressing behavior in a way that is understandable to different participants and associating behaviors with executable scenarios. Behaviour-Driven Development of Foundational UML Components

A typical BDD scenario:

Given payment was confirmed When delivery is released Then courier receives delivery data 

T-DD can represent this as part of a larger trajectory:

payment.confirmed ↓ delivery.released ↓ courier.receives 

The difference is one of scope.

BDD → expected behavior in scenarios T-DD → complete temporal evolution of an intent toward its destination 

BDD can therefore be a projection of a T-DD trajectory:

Trajectory ↓ BDD Scenarios 

Just as:

Trajectory ↓ Tests 

or:

Trajectory ↓ State Machine 

17. Relationship with Test-Driven Development

Traditional TDD begins with a test that expresses a desired change, implements code to satisfy it, and subsequently refactors the implementation.

This cycle is extremely effective for guiding local software construction.

T-DD changes the primary object:

TDD: test is primary artifact T-DD: trajectory is primary semantic artifact 

A test can verify:

assert payment.confirmed 

But a trajectory verifies:

request → payment.requested → payment.confirmed → delivery.released 

And also:

¬delivery.released before payment.confirmed 

Therefore:

TDD verifies local behavior. T-DD specifies and verifies behavioral evolution. 

The two can coexist:

T-DD ↓ generates/defines ↓ TDD tests 

18. Relationship with Model-Driven Development

Model-driven approaches use models as fundamental artifacts and frequently derive technical artifacts from these models.

T-DD follows a similar idea:

semantic model ↓ DSL ↓ generated artifacts ↓ implementation 

But the central object is not simply a structural model.

It is a trajectory:

semantic model = intent + behavior + state + actor + evidence + trajectory 

This brings T-DD closer to a form of trajectory-centered model-driven development.

The DSL becomes a compact representation of a previously defined semantic model.

19. The monotonic ladder of specificity

An important property of T-DD is the idea of monotonic refinement.

We define:

S₀ = Destiny S₁ = Intent S₂ = Behavior ... Sₙ = Implementation 

with:

S₀ ⊆ S₁ ⊆ S₂ ⊆ ... ⊆ Sₙ 

The symbol ⊆ should be interpreted semantically:

each stage adds constraints without invalidating the meaning established previously.

For example:

Destiny: "delivery must be completed" Intent: "customer wants to deliver package from A to B" Behavior: "find courier and execute delivery" Contract: "payment must be confirmed before release" State: "awaiting_payment → paid → active" Actor: "only payment can confirm payment" Skill: "confirm_payment" Trajectory: "request → collect → select → pay → release → track → deliver" Implementation: "WhatsApp + PostgreSQL + NATS + provider X" 

The last layer has much more technical information, but it should not alter the meaning of the previous layers.

20. The principle of semantic separation

T-DD establishes:

technology ≠ semantics 

An API:

POST /delivery 

is not the behavior.

A table:

deliveries 

is not the behavior.

A function:

createDelivery() 

is not the behavior.

An agent:

DeliveryAgent 

is not the behavior.

All are possible implementations of a prior semantics.

Therefore:

semantic specification ↓ implementation projection 

and not:

implementation ↓ retroactive semantic interpretation 

This inversion is one of the most important characteristics of the proposal.

21. Actor as semantic authority

T-DD explicitly introduces:

ACTOR 

because behavior cannot be separated from authority.

Example:

ACTOR customer ACTOR courier ACTOR payment ACTOR system 

Then:

ALLOW customer { request address pay } 

and:

ALLOW payment { confirm reject } 

This makes it possible to distinguish:

technically executable 

from:

semantically authorized 

The fact that a function can be called by code does not mean that the current actor is authorized to execute it.

This separation is especially important for:

• agents;
• multi-user systems;
• distributed systems;
• security;
• compliance;
• human-in-the-loop;
• enterprise workflows.

22. Skill as an executable unit

The Skill represents a semantically bounded capability.

Example:

SKILL select_nearest { in: couriers, origin rule: min(distance(courier, origin)) out: courier emit: courier.selected } 

A Skill has:

input output rule invariants evidence actor 

It can then be used by:

agent workflow test runtime simulator human 

This makes it possible to separate:

what can be done 

from:

who orchestrates it 

A Skill does not need to know whether it was called by:

LLM HTTP CLI WhatsApp workflow human 

The semantics remain the same.

23. Evidence as a first-class citizen

One of the most important points of T-DD is placing evidence before implementation.

Example:

EVIDENCE delivery { request.received intent.recognized addresses.collected courier.selected payment.confirmed delivery.released location.received* code.validated settlement.completed } 

This means that observability is not:

"let's add logs later" 

but:

"what facts need to be observable to prove that the behavior occurred?" 

The difference is architectural.

A log:

"payment succeeded" 

is not necessarily reliable evidence.

Evidence must be linked to a verifiable semantic condition:

payment.confirmed 

and ideally:

actor timestamp correlation_id state_before action state_after provenance 

24. Provenance

Evidence can also have provenance:

Evidence = ⟨fact, actor, timestamp, source, provenance⟩ 

For example:

payment.confirmed actor: payment-provider timestamp: 2026-10-07T10:32:12Z source: provider-event 

This makes it possible to distinguish:

claim 

from:

observed fact 

This property becomes particularly important for agent systems.

An agent may say:

"the payment was confirmed" 

but the system must be able to answer:

what evidence supports this claim? 

25. T-DD and agent systems

The model becomes particularly interesting for agents because agents frequently operate in loops:

observe → reason → act → observe → reason → act 

A traditional agent may produce a sequence of tool calls without having a formal representation of the trajectory.

T-DD proposes:

Intent ↓ Expected Trajectory ↓ Agent Actions ↓ Observed Evidence ↓ Trajectory Update ↓ Conformance 

The agent ceases to be simply:

LLM + tools 

and becomes a participant in a semantically defined trajectory.

26. Agent does not define semantics

This distinction is essential.

The agent may choose:

which Skill to execute 

but should not be able to silently change:

which Destiny is being pursued 

nor:

which invariants are mandatory 

For example:

X: ¬release(payment ≠ confirmed) 

The agent may try several strategies to obtain confirmation.

But it cannot decide:

"I will release even without payment" 

unless the specification allows that transition.

This produces:

agent autonomy within semantic boundaries 

and not:

agent autonomy over system meaning 

27. Relationship with sociology: action, intention, and trajectory

The word "action" in software systems has a much greater conceptual heritage than simply calling a function.

In the social sciences, an action can be studied by considering:

actor intention context norms resources action consequence 

T-DD has a similar structure:

ACTOR INTENT CONTEXT CONTRACT ACTION EVIDENCE STATE CONSEQUENCE 

But this does not mean that T-DD is proposing a new sociological theory.

The contribution is to transport a useful distinction into computational systems:

technical action ≠ semantically situated action 

In multi-agent and conversational systems, this becomes particularly important because the same technical command can have different meanings depending on actor, context, and state.

28. Intention does not automatically determine action

The psychological literature provides an important warning.

Ajzen's Theory of Planned Behavior shows that intention is an important determinant, but not sufficient to guarantee behavior; perceived control and other factors also matter.

This can be translated architecturally:

Intent ≠ Guaranteed Execution 

An intention may fail because of:

missing information authorization denied resource unavailable provider failure state invalid contract violation actor unavailable timeout 

Therefore:

Intent ↓ possible trajectories 

and not:

Intent ↓ one guaranteed action 

This observation establishes the need to represent failures and replanning as legitimate parts of the trajectory.

29. Trajectory can branch

A real trajectory does not need to be linear.

We may have:

request ↓ payment ├── confirmed │ ↓ │ release │ └── rejected ↓ retry 

Formally:

T = graph(S, A, E) 

rather than simply:

T = list(A) 

Therefore:

Trajectory 

can be:

• linear;
• branched;
• concurrent;
• iterative;
• recursive;
• partially ordered.

This brings T-DD closer to:

• statecharts;
• Petri nets;
• process calculi;
• workflow models;
• temporal logic;
• process mining.

30. Relationship with Petri Nets

Petri nets are one of the most important formal foundations for workflow modeling.

Van der Aalst demonstrated their application to workflow management, highlighting both their specification capabilities and the possibilities for formal analysis of procedures.

A T-DD trajectory can eventually be compiled into a similar structure.

For example:

requested ↓ collecting ↓ searching ↓ assigned 

can be represented as a network.

The advantage would be to allow analysis of:

deadlocks liveness reachability concurrency soundness 

T-DD does not need to replace Petri nets.

A possible architecture is:

T-DD DSL ↓ semantic model ↓ Petri-net projection ↓ formal analysis 

This would be a natural evolution of the proposal.

31. Conformance as a formal relationship

We define:

T_expected 

as the declared trajectory.

And:

T_observed 

as the observed trajectory.

Conformance can be represented by:

Conforms(T_observed, T_expected) 

A simple form:

T_observed ⊨ T_expected 

But the actual relationship can be richer.

We can define:

Conformance = structural ∧ temporal ∧ contractual ∧ authorization ∧ evidential 

Then:

Conformance(To, Te) = Cstructural ∧ Ctemporal ∧ Ccontract ∧ Cactor ∧ Cevidence 

This makes it possible to classify deviations:

STRUCTURAL_DEVIATION TEMPORAL_DEVIATION CONTRACT_DEVIATION AUTHORIZATION_DEVIATION MISSING_EVIDENCE UNEXPECTED_ACTION INVALID_STATE_TRANSITION 

32. Trajectory Distance

A natural mathematical evolution is to define a distance between trajectories.

For example:

d(T_expected, T_observed) 

could consider:

missing actions extra actions wrong ordering wrong actor wrong state missing evidence 

A simplified function:

d(Tₑ,Tₒ) = αM + βX + γO + δA + εS + ζE 

where:

M = missing actions X = unexpected actions O = ordering deviations A = actor deviations S = state deviations E = evidence deviations 

The weights:

α β γ δ ε ζ 

can be defined according to the domain.

This opens space for:

trajectory similarity trajectory clustering trajectory anomaly detection trajectory ranking trajectory repair 

33. Conformance does not need to be binary

In complex systems:

conforms = true/false 

may be insufficient.

We can have:

ConformanceScore ∈ [0,1] 

For example:

0.98 

may mean that the trajectory has a small non-critical divergence.

While:

0.20 

may indicate that the system has practically abandoned the declared trajectory.

But some invariants must be absolute:

payment confirmed before release 

should not sim...