DEV Community

Cover image for Trajectory-Driven Development (T-DD): Development driven by semantic behavior trajectories
suissAI
suissAI

Posted on

Trajectory-Driven Development (T-DD): Development driven by semantic behavior trajectories

#programming #allascode #architecture #tdd

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

or:

requirement
 ↓
implementation
 ↓
test
Enter fullscreen mode Exit fullscreen mode

or even:

user story
 ↓
BDD scenario
 ↓
implementation
 ↓
acceptance test
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

A T-DD specification can be represented as:

Σ = ⟨D, I, B, E, C, S, A, K, T, X⟩
Enter fullscreen mode Exit fullscreen mode

where:

Symbol Concept Meaning
D Destiny desired business state/destination
I Intent semantic intent
B Behavior required behavior
E Evidence observable evidence
C Contract constraints and invariants
S State legal states and transitions
A Actor actors and authority
K Skill executable capabilities
T Trajectory temporal sequence of realization
X Exclusion prohibited behaviors

The implementation:

P
Enter fullscreen mode Exit fullscreen mode

is considered conformant when:

P ⊨ T
Enter fullscreen mode Exit fullscreen mode

and the trajectory satisfies the refinement relationships:

T ⊨ B
B ⊨ I
I ⊨ D
Enter fullscreen mode Exit fullscreen mode

Therefore:

P ⊨ T ⊨ B ⊨ I ⊨ D
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Formally:

D = {requested, paid, assigned, tracked, delivered, settled}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

or:

customer → deliver package from A to B
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

An intent may be:

"I want to make a delivery"
Enter fullscreen mode Exit fullscreen mode

without containing:

origin
destination
price
payment
courier
delivery code
Enter fullscreen mode Exit fullscreen mode

Therefore:

intent valid
≠
execution ready
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Therefore:

Intent = semantic starting point

Destination = desired terminal condition

Trajectory = evolution between them
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

where:

T = temporal domain
S = state space
τ(t) = state observed at instant t
Enter fullscreen mode Exit fullscreen mode

For software, we can enrich this definition:

τ = ⟨(s₀,a₀,e₀,t₀),
     (s₁,a₁,e₁,t₁),
     ...
     (sₙ,aₙ,eₙ,tₙ)⟩
Enter fullscreen mode Exit fullscreen mode

where:

s = state
a = action
e = evidence
t = time
Enter fullscreen mode Exit fullscreen mode

A trajectory therefore ceases to be simply:

A → B → C
Enter fullscreen mode Exit fullscreen mode

and becomes:

(state, actor, action, evidence, time)
Enter fullscreen mode Exit fullscreen mode

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
}
Enter fullscreen mode Exit fullscreen mode

And:

FLOW delivery {
    requested → collecting
    collecting → searching
    searching → assigned
    assigned → awaiting_payment
    awaiting_payment → paid
    paid → active
    active → arriving
    arriving → delivered
    delivered → settled
}
Enter fullscreen mode Exit fullscreen mode

This makes it possible to express:

awaiting_payment → paid
Enter fullscreen mode Exit fullscreen mode

only when:

payment.confirmed = true
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

and:

payment.confirmed
Enter fullscreen mode Exit fullscreen mode

It is not enough for both to be true.

We need to establish:

payment.requested
    precedes
payment.confirmed
Enter fullscreen mode Exit fullscreen mode

And:

delivery.released
Enter fullscreen mode Exit fullscreen mode

cannot occur before:

payment.confirmed
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

into a verifiable temporal property.

For example, conceptually:

G(release → previously(payment_confirmed))
Enter fullscreen mode Exit fullscreen mode

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
}
Enter fullscreen mode Exit fullscreen mode

can be conceptually approximated by:

{ payment.valid }
confirm_payment()
{ payment.confirmed }
Enter fullscreen mode Exit fullscreen mode

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

actor
evidence
trajectory position
temporal relation
business destiny
semantic intent
Enter fullscreen mode Exit fullscreen mode

Thus:

Hoare Logic
    ↓
correctness of program state transformation

T-DD
    ↓
correctness of semantic trajectory
Enter fullscreen mode Exit fullscreen mode

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
}
Enter fullscreen mode Exit fullscreen mode

This defines:

preconditions
postconditions
invariants
failure conditions
Enter fullscreen mode Exit fullscreen mode

The difference lies in the level of integration.

In T-DD:

Contract
Enter fullscreen mode Exit fullscreen mode

is not an isolated artifact.

It belongs to the trajectory:

Intent
 ↓
Behavior
 ↓
Contract
 ↓
State
 ↓
Trajectory
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Thus, instead of an external matrix:

Requirement → Design → Code → Test
Enter fullscreen mode Exit fullscreen mode

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

This makes it possible to ask:

Which code implements this Skill?
Enter fullscreen mode Exit fullscreen mode

or:

Which Skill realizes this Behavior?
Enter fullscreen mode Exit fullscreen mode

or:

Which Intent originated this Behavior?
Enter fullscreen mode Exit fullscreen mode

or:

Which Destiny depends on this Intent?
Enter fullscreen mode Exit fullscreen mode

or:

Which evidence proves that this intent was realized?
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

A goal can be:

deliver package
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode

This brings T-DD close to a combination of:

Goal-oriented RE
+
State-based modeling
+
Process modeling
+
Trace semantics
+
Conformance checking
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

While T-DD proposes:

DECLARED TRAJECTORY
        ↓
IMPLEMENTATION
        ↓
OBSERVED TRAJECTORY
        ↓
CONFORMANCE
Enter fullscreen mode Exit fullscreen mode

We therefore have two complementary operations:

Process Mining:

events → infer model


T-DD:

model → expected events
Enter fullscreen mode Exit fullscreen mode

And in the future:

T-DD + Process Mining

declared trajectory
        ↓
executed system
        ↓
observed trajectory
        ↓
alignment
        ↓
conformance / deviation / repair
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The literature of van der Aalst establishes three major activities:

discovery
conformance
enhancement
Enter fullscreen mode Exit fullscreen mode

and uses event logs to discover or analyze real processes.

In T-DD:

DECLARED TRAJECTORY
Enter fullscreen mode Exit fullscreen mode

is an expected process.

The system produces:

OBSERVED TRAJECTORY
Enter fullscreen mode Exit fullscreen mode

The comparison:

expected ↔ observed
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Event Sourcing can provide the raw material for:

ObservedTrajectory
Enter fullscreen mode Exit fullscreen mode

but does not itself define:

Intent
Destiny
Contract
Actor
Skill
ExpectedTrajectory
Enter fullscreen mode Exit fullscreen mode

Therefore:

T-DD
   +
Event Sourcing
   =
declared semantics + historical execution
Enter fullscreen mode Exit fullscreen mode

15. Current state is not trajectory

This distinction is fundamental.

Imagine two systems that ended like this:

delivery.status = settled
Enter fullscreen mode Exit fullscreen mode

Both have the same final state.

But:

Trajectory A 

requested
→ assigned
→ paid
→ active
→ delivered
→ settled
Enter fullscreen mode Exit fullscreen mode

Trajectory B 

requested
→ assigned
→ settled
Enter fullscreen mode Exit fullscreen mode

The final state is the same:

settled
Enter fullscreen mode Exit fullscreen mode

The semantics are completely different.

The second system may have violated:

payment.confirmed
delivery.completed
delivery.code.validated
Enter fullscreen mode Exit fullscreen mode

Therefore:

State(t_final)
Enter fullscreen mode Exit fullscreen mode

is not sufficient to determine:

CorrectTrajectory
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

payment.confirmed
    ↓
delivery.released
    ↓
courier.receives
Enter fullscreen mode Exit fullscreen mode

The difference is one of scope.

BDD
→ expected behavior in scenarios

T-DD
→ complete temporal evolution of an intent toward its destination
Enter fullscreen mode Exit fullscreen mode

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

Trajectory
   ↓
BDD Scenarios
Enter fullscreen mode Exit fullscreen mode

Just as:

Trajectory
   ↓
Tests
Enter fullscreen mode Exit fullscreen mode

or:

Trajectory
   ↓
State Machine
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

A test can verify:

assert payment.confirmed
Enter fullscreen mode Exit fullscreen mode

But a trajectory verifies:

request
→ payment.requested
→ payment.confirmed
→ delivery.released
Enter fullscreen mode Exit fullscreen mode

And also:

¬delivery.released
before payment.confirmed
Enter fullscreen mode Exit fullscreen mode

Therefore:

TDD verifies local behavior.

T-DD specifies and verifies behavioral evolution.
Enter fullscreen mode Exit fullscreen mode

The two can coexist:

T-DD
 ↓
generates/defines
 ↓
TDD tests
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

But the central object is not simply a structural model.

It is a trajectory:

semantic model
=
intent + behavior + state + actor + evidence + trajectory
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

with:

S₀ ⊆ S₁ ⊆ S₂ ⊆ ... ⊆ Sₙ
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

An API:

POST /delivery
Enter fullscreen mode Exit fullscreen mode

is not the behavior.

A table:

deliveries
Enter fullscreen mode Exit fullscreen mode

is not the behavior.

A function:

createDelivery()
Enter fullscreen mode Exit fullscreen mode

is not the behavior.

An agent:

DeliveryAgent
Enter fullscreen mode Exit fullscreen mode

is not the behavior.

All are possible implementations of a prior semantics.

Therefore:

semantic specification
        ↓
implementation projection
Enter fullscreen mode Exit fullscreen mode

and not:

implementation
        ↓
retroactive semantic interpretation
Enter fullscreen mode Exit fullscreen mode

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

21. Actor as semantic authority

T-DD explicitly introduces:

ACTOR
Enter fullscreen mode Exit fullscreen mode

because behavior cannot be separated from authority.

Example:

ACTOR customer
ACTOR courier
ACTOR payment
ACTOR system
Enter fullscreen mode Exit fullscreen mode

Then:

ALLOW customer {
    request
    address
    pay
}
Enter fullscreen mode Exit fullscreen mode

and:

ALLOW payment {
    confirm
    reject
}
Enter fullscreen mode Exit fullscreen mode

This makes it possible to distinguish:

technically executable
Enter fullscreen mode Exit fullscreen mode

from:

semantically authorized
Enter fullscreen mode Exit fullscreen mode

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
}
Enter fullscreen mode Exit fullscreen mode

A Skill has:

input
output
rule
invariants
evidence
actor
Enter fullscreen mode Exit fullscreen mode

It can then be used by:

agent
workflow
test
runtime
simulator
human
Enter fullscreen mode Exit fullscreen mode

This makes it possible to separate:

what can be done
Enter fullscreen mode Exit fullscreen mode

from:

who orchestrates it
Enter fullscreen mode Exit fullscreen mode

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

LLM
HTTP
CLI
WhatsApp
workflow
human
Enter fullscreen mode Exit fullscreen mode

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
}
Enter fullscreen mode Exit fullscreen mode

This means that observability is not:

"let's add logs later"
Enter fullscreen mode Exit fullscreen mode

but:

"what facts need to be observable to prove that the behavior occurred?"
Enter fullscreen mode Exit fullscreen mode

The difference is architectural.

A log:

"payment succeeded"
Enter fullscreen mode Exit fullscreen mode

is not necessarily reliable evidence.

Evidence must be linked to a verifiable semantic condition:

payment.confirmed
Enter fullscreen mode Exit fullscreen mode

and ideally:

actor
timestamp
correlation_id
state_before
action
state_after
provenance
Enter fullscreen mode Exit fullscreen mode

24. Provenance

Evidence can also have provenance:

Evidence =
    ⟨fact, actor, timestamp, source, provenance⟩
Enter fullscreen mode Exit fullscreen mode

For example:

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

This makes it possible to distinguish:

claim
Enter fullscreen mode Exit fullscreen mode

from:

observed fact
Enter fullscreen mode Exit fullscreen mode

This property becomes particularly important for agent systems.

An agent may say:

"the payment was confirmed"
Enter fullscreen mode Exit fullscreen mode

but the system must be able to answer:

what evidence supports this claim?
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The agent ceases to be simply:

LLM + tools
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

but should not be able to silently change:

which Destiny is being pursued
Enter fullscreen mode Exit fullscreen mode

nor:

which invariants are mandatory
Enter fullscreen mode Exit fullscreen mode

For example:

X:
¬release(payment ≠ confirmed)
Enter fullscreen mode Exit fullscreen mode

The agent may try several strategies to obtain confirmation.

But it cannot decide:

"I will release even without payment"
Enter fullscreen mode Exit fullscreen mode

unless the specification allows that transition.

This produces:

agent autonomy
within semantic boundaries
Enter fullscreen mode Exit fullscreen mode

and not:

agent autonomy
over system meaning
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

T-DD has a similar structure:

ACTOR
INTENT
CONTEXT
CONTRACT
ACTION
EVIDENCE
STATE
CONSEQUENCE
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

An intention may fail because of:

missing information
authorization denied
resource unavailable
provider failure
state invalid
contract violation
actor unavailable
timeout
Enter fullscreen mode Exit fullscreen mode

Therefore:

Intent
 ↓
possible trajectories
Enter fullscreen mode Exit fullscreen mode

and not:

Intent
 ↓
one guaranteed action
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Formally:

T = graph(S, A, E)
Enter fullscreen mode Exit fullscreen mode

rather than simply:

T = list(A)
Enter fullscreen mode Exit fullscreen mode

Therefore:

Trajectory
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

can be represented as a network.

The advantage would be to allow analysis of:

deadlocks
liveness
reachability
concurrency
soundness
Enter fullscreen mode Exit fullscreen mode

T-DD does not need to replace Petri nets.

A possible architecture is:

T-DD DSL
    ↓
semantic model
    ↓
Petri-net projection
    ↓
formal analysis
Enter fullscreen mode Exit fullscreen mode

This would be a natural evolution of the proposal.

31. Conformance as a formal relationship

We define:

T_expected
Enter fullscreen mode Exit fullscreen mode

as the declared trajectory.

And:

T_observed
Enter fullscreen mode Exit fullscreen mode

as the observed trajectory.

Conformance can be represented by:

Conforms(T_observed, T_expected)
Enter fullscreen mode Exit fullscreen mode

A simple form:

T_observed ⊨ T_expected
Enter fullscreen mode Exit fullscreen mode

But the actual relationship can be richer.

We can define:

Conformance =
    structural
    ∧ temporal
    ∧ contractual
    ∧ authorization
    ∧ evidential
Enter fullscreen mode Exit fullscreen mode

Then:

Conformance(To, Te)
=
Cstructural
∧ Ctemporal
∧ Ccontract
∧ Cactor
∧ Cevidence
Enter fullscreen mode Exit fullscreen mode

This makes it possible to classify deviations:

STRUCTURAL_DEVIATION
TEMPORAL_DEVIATION
CONTRACT_DEVIATION
AUTHORIZATION_DEVIATION
MISSING_EVIDENCE
UNEXPECTED_ACTION
INVALID_STATE_TRANSITION
Enter fullscreen mode Exit fullscreen mode

32. Trajectory Distance

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

For example:

d(T_expected, T_observed)
Enter fullscreen mode Exit fullscreen mode

could consider:

missing actions
extra actions
wrong ordering
wrong actor
wrong state
missing evidence
Enter fullscreen mode Exit fullscreen mode

A simplified function:

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

where:

M = missing actions
X = unexpected actions
O = ordering deviations
A = actor deviations
S = state deviations
E = evidence deviations
Enter fullscreen mode Exit fullscreen mode

The weights:

α β γ δ ε ζ
Enter fullscreen mode Exit fullscreen mode

can be defined according to the domain.

This opens space for:

trajectory similarity
trajectory clustering
trajectory anomaly detection
trajectory ranking
trajectory repair
Enter fullscreen mode Exit fullscreen mode

33. Conformance does not need to be binary

In complex systems:

conforms = true/false
Enter fullscreen mode Exit fullscreen mode

may be insufficient.

We can have:

ConformanceScore ∈ [0,1]
Enter fullscreen mode Exit fullscreen mode

For example:

0.98
Enter fullscreen mode Exit fullscreen mode

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

While:

0.20
Enter fullscreen mode Exit fullscreen mode

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

But some invariants must be absolute:

payment confirmed before release
Enter fullscreen mode Exit fullscreen mode

should not simply be transformed into:

97% compliant
Enter fullscreen mode Exit fullscreen mode

Therefore, T-DD must distinguish:

soft constraints
Enter fullscreen mode Exit fullscreen mode

from:

hard invariants
Enter fullscreen mode Exit fullscreen mode

34. Hard and Soft Semantics

We can define:

C = Chard ∪ Csoft
Enter fullscreen mode Exit fullscreen mode

Example:

HARD:
¬release(payment≠confirmed)

SOFT:
select courier with minimal distance
Enter fullscreen mode Exit fullscreen mode

Thus:

payment confirmation
Enter fullscreen mode Exit fullscreen mode

is mandatory.

While:

nearest courier
Enter fullscreen mode Exit fullscreen mode

may allow:

second nearest
Enter fullscreen mode Exit fullscreen mode

when the first is unavailable.

This is particularly important for agents.

The agent may optimize:

soft constraints
Enter fullscreen mode Exit fullscreen mode

but may not violate:

hard constraints
Enter fullscreen mode Exit fullscreen mode

35. Replanning

When a trajectory fails, the system does not necessarily need to declare the intent impossible.

Example:

Intent:
deliver package
Enter fullscreen mode Exit fullscreen mode

First trajectory:

select courier A
→ courier rejects
Enter fullscreen mode Exit fullscreen mode

A second trajectory may be:

select courier B
→ accept
→ pay
→ release
Enter fullscreen mode Exit fullscreen mode

Therefore:

Intent
   ↓
Trajectory₁
   ↓
failure
   ↓
replanning
   ↓
Trajectory₂
   ↓
Destination
Enter fullscreen mode Exit fullscreen mode

The intent remains.

The trajectory changes.

This distinction is especially important in agent systems.

36. Persistent intent, mutable trajectory

An important formulation:

Intent = relatively stable semantic objective

Trajectory = mutable realization strategy
Enter fullscreen mode Exit fullscreen mode

This means:

same intent
+
different trajectory
=
valid adaptation
Enter fullscreen mode Exit fullscreen mode

provided that:

trajectory ⊨ intent
Enter fullscreen mode Exit fullscreen mode

This property allows an agent to perform adaptive planning without arbitrarily modifying the semantic objective.

37. The relationship with "Situated Action"

Research in human-computer interaction and the social sciences has also shown limitations in treating human action as simple execution of predefined plans.

Lucy Suchman's work on Plans and Situated Actions became an important reference for understanding how actions are produced in concrete situations rather than simply executing abstract plans.

The parallel for T-DD is:

declared trajectory
Enter fullscreen mode Exit fullscreen mode

does not need to mean:

fixed deterministic script
Enter fullscreen mode Exit fullscreen mode

It can represent:

semantic constraints
Enter fullscreen mode Exit fullscreen mode

within which execution can adapt to context.

This suggests a distinction:

Trajectory Specification
≠
Execution Script
Enter fullscreen mode Exit fullscreen mode

The former defines:

what must remain true
Enter fullscreen mode Exit fullscreen mode

The latter defines:

how one execution currently proceeds
Enter fullscreen mode Exit fullscreen mode

This distinction is particularly useful for agents.

38. T-DD as a "semantic constraint system"

A more precise way of defining T-DD is:

T-DD is a development system in which a declared trajectory functions as a structure of progressively refined semantic constraints, against which implementations and executions can be verified.

In this sense:

T-DD ≈ semantic constraint refinement
Enter fullscreen mode Exit fullscreen mode

and:

Implementation = realization
Execution = instantiation
Observation = evidence
Conformance = verification
Enter fullscreen mode Exit fullscreen mode

39. The DSL as semantic compression

The DSL should not be the first artifact.

It is the result of the specification.

For example:

DESTINY
INTENT
BEHAVIOR
CONTRACT
STATE
ACTOR
EVIDENCE
TRAJECTORY
Enter fullscreen mode Exit fullscreen mode

can be compressed into:

@delivery

D: delivery→requested paid assigned tracked delivered settled

I: customer→deliver

B:
  request
  →collect
  →discover(courier*)
  →select(min distance)
  →charge
  →confirm
  →release
  →track*
  →validate(code)
  →settle

S:
  requested
  →collecting
  →searching
  →assigned
  →awaiting_payment
  →paid
  →active
  →arriving
  →delivered
  →settled

X:
  ¬release(payment≠confirmed)
  ¬settle(code≠valid)
Enter fullscreen mode Exit fullscreen mode

A DSL does not invent these meanings.

It encodes them.

Therefore:

Semantic Model
      ↓
DSL
Enter fullscreen mode Exit fullscreen mode

and not:

DSL
 ↓
invent semantic meaning
Enter fullscreen mode Exit fullscreen mode

40. Semantic Source of Truth

A desirable property is:

DSL = semantic source of truth
Enter fullscreen mode Exit fullscreen mode

while:

TypeScript
Python
Zig
SQL
OpenAPI
routes
schemas
tests
agent tools
Enter fullscreen mode Exit fullscreen mode

are projections.

For example:

T-DD DSL
    ├──→ TypeScript
    ├──→ Python
    ├──→ OpenAPI
    ├──→ JSON Schema
    ├──→ tests
    ├──→ state machine
    ├──→ agent tools
    └──→ documentation
Enter fullscreen mode Exit fullscreen mode

This architecture brings T-DD closer to:

Model-Driven Engineering
+
Schema-Driven Development
+
Code Generation
Enter fullscreen mode Exit fullscreen mode

but uses trajectory-centered semantics.

41. Relationship with Design Science Research

T-DD can also be studied as a Design Science Research artifact.

The DSR literature characterizes this type of research through the construction and evaluation of artifacts, following the transformation of problems into requirements, artifacts, and evaluation evidence.

This is particularly relevant to the evolution of T-DD because it makes it possible to separate:

claim
Enter fullscreen mode Exit fullscreen mode

from:

implementation
Enter fullscreen mode Exit fullscreen mode

and:

evidence
Enter fullscreen mode Exit fullscreen mode

The research of the method can then follow:

Problem
 ↓
Concept
 ↓
Formalization
 ↓
DSL
 ↓
Implementation
 ↓
Execution
 ↓
Evaluation
 ↓
Conformance
 ↓
Revision
Enter fullscreen mode Exit fullscreen mode

This turns the development of T-DD itself into an instance of T-DD.

42. Self-application

An interesting property of the methodology is that it can specify itself.

Example:

DESTINY:
produce a system whose implementation conforms
to declared semantic trajectories
Enter fullscreen mode Exit fullscreen mode

Intent:

define trajectory-driven development
Enter fullscreen mode Exit fullscreen mode

Behavior:

research
→ formalize
→ define vocabulary
→ define grammar
→ implement parser
→ implement validator
→ generate artifacts
→ execute
→ observe
→ compare
Enter fullscreen mode Exit fullscreen mode

Evidence:

specification.valid
grammar.valid
examples.valid
implementation.generated
tests.pass
trajectory.conforms
Enter fullscreen mode Exit fullscreen mode

Thus:

T-DD
Enter fullscreen mode Exit fullscreen mode

can be used to develop:

T-DD itself
Enter fullscreen mode Exit fullscreen mode

43. A complete example

Consider:

"I need a delivery."

The message is:

"I need a delivery"
Enter fullscreen mode Exit fullscreen mode

Destiny 

delivery.requested
delivery.paid
delivery.assigned
delivery.tracked
delivery.delivered
delivery.settled
Enter fullscreen mode Exit fullscreen mode

Intent 

customer → deliver(package, origin, destination)
Enter fullscreen mode Exit fullscreen mode

Missing semantic information 

origin
destination
Enter fullscreen mode Exit fullscreen mode

Behavior 

request
→ collect
→ discover
→ select
→ charge
→ confirm
→ release
→ track
→ validate
→ settle
Enter fullscreen mode Exit fullscreen mode

Contract 

release requires payment.confirmed
Enter fullscreen mode Exit fullscreen mode

State 

requested
→ collecting
→ searching
→ assigned
→ awaiting_payment
→ paid
→ active
→ delivered
→ settled
Enter fullscreen mode Exit fullscreen mode

Actor 

customer:
    request
    pay
    validate

system:
    classify
    collect
    discover
    select
    release
    route
    settle

courier:
    accept
    locate
    deliver

payment:
    confirm
    reject
Enter fullscreen mode Exit fullscreen mode

Evidence 

intent.recognized
addresses.collected
courier.selected
payment.confirmed
delivery.released
location.received
code.validated
settlement.completed
Enter fullscreen mode Exit fullscreen mode

Trajectory 

customer.request
→ system.collect
→ system.discover
→ system.select
→ customer.pay
→ payment.confirm
→ system.release
→ courier.locate*
→ system.relay*
→ customer.code
→ system.validate
→ system.settle
Enter fullscreen mode Exit fullscreen mode

Implementation

Only now:

WhatsApp
→ classifier
→ orchestrator
→ skill runtime
→ payment provider
→ courier service
→ PostgreSQL
→ event stream
→ observability
Enter fullscreen mode Exit fullscreen mode

Technology is a realization of the trajectory, not its definition.

44. T-DD and the "happy path" problem

An important consequence is that the trajectory should not represent only:

happy path
Enter fullscreen mode Exit fullscreen mode

It should represent:

valid trajectories
+
invalid trajectories
+
recovery trajectories
Enter fullscreen mode Exit fullscreen mode

For example:

payment rejected
Enter fullscreen mode Exit fullscreen mode

may produce:

awaiting_payment
→ payment_rejected
→ retry_payment
→ payment_confirmed
Enter fullscreen mode Exit fullscreen mode

While:

courier unavailable
Enter fullscreen mode Exit fullscreen mode

may produce:

searching
→ no_courier
→ expand_search
→ searching
Enter fullscreen mode Exit fullscreen mode

Therefore:

T-DD specification
Enter fullscreen mode Exit fullscreen mode

must be capable of representing a space of trajectories.

45. Trajectory Space

We can define:

𝒯(I)
Enter fullscreen mode Exit fullscreen mode

as the set of admissible trajectories for an intent I.

Then:

τ ∈ 𝒯(I)
Enter fullscreen mode Exit fullscreen mode

means:

τ is a semantically valid trajectory for realizing I.

An implementation may produce:

τ₁
Enter fullscreen mode Exit fullscreen mode

and another:

τ₂
Enter fullscreen mode Exit fullscreen mode

without both being identical.

What matters is:

τ₁ ∈ 𝒯(I)
τ₂ ∈ 𝒯(I)
Enter fullscreen mode Exit fullscreen mode

This provides a mathematical foundation for not confusing:

semantic equivalence
Enter fullscreen mode Exit fullscreen mode

with:

implementation equality
Enter fullscreen mode Exit fullscreen mode

46. Trajectory equivalence

Two trajectories may be different and semantically equivalent.

Example:

Trajectory A:

discover courier
→ select courier
→ charge
Enter fullscreen mode Exit fullscreen mode

and:

Trajectory B:

discover courier
→ reserve courier
→ charge
→ confirm reservation
Enter fullscreen mode Exit fullscreen mode

If both preserve the same invariants and produce the same destination:

A ≈ B
Enter fullscreen mode Exit fullscreen mode

they may be considered semantically equivalent under an equivalence relation defined by the domain.

This opens a research area:

trajectory equivalence
Enter fullscreen mode Exit fullscreen mode

analogous to equivalence relations in formal systems, languages, and concurrent processes.

47. Conformance as refinement

We can interpret implementation as refinement:

Specification
      ↓
Refinement
      ↓
Implementation
Enter fullscreen mode Exit fullscreen mode

A correct implementation should not introduce prohibited behaviors.

Therefore:

Allowed(T)
Enter fullscreen mode Exit fullscreen mode

must contain the observed behavior:

Observed(T) ⊆ Allowed(T)
Enter fullscreen mode Exit fullscreen mode

with additional coverage conditions:

Required(T) ⊆ Observed(T)
Enter fullscreen mode Exit fullscreen mode

An implementation ideally satisfies:

Required(T)
    ⊆
Observed(T)
    ⊆
Allowed(T)
Enter fullscreen mode Exit fullscreen mode

This formula compactly summarizes an important T-DD property:

execution must realize what is required without producing what is prohibited.

48. Required, Allowed, and Forbidden

We can formalize:

R = required behavior
A = allowed behavior
F = forbidden behavior
Enter fullscreen mode Exit fullscreen mode

with:

R ⊆ A
F ∩ A = ∅
Enter fullscreen mode Exit fullscreen mode

And:

Observed ⊆ A
Enter fullscreen mode Exit fullscreen mode

and:

R ⊆ Observed
Enter fullscreen mode Exit fullscreen mode

for a fully conformant trajectory.

When:

Observed ∩ F ≠ ∅
Enter fullscreen mode Exit fullscreen mode

we have an explicit violation.

When:

R - Observed ≠ ∅
Enter fullscreen mode Exit fullscreen mode

we have missing behavior.

This provides a simple formal foundation for a future T-DD Conformance Engine.

49. The complete loop

The methodology can be represented as:

DESTINY
   ↓
INTENT
   ↓
BEHAVIOR
   ↓
EVIDENCE
   ↓
CONTRACT
   ↓
STATE
   ↓
ACTOR
   ↓
SKILL
   ↓
TRAJECTORY
   ↓
DSL
   ↓
IMPLEMENT
   ↓
EXECUTE
   ↓
OBSERVE
   ↓
RECONSTRUCT
   ↓
COMPARE
   ↓
CONFORMANCE
   ↓
REPLAN / REPAIR
   └───────────────────↺
Enter fullscreen mode Exit fullscreen mode

Or, more abstractly:

declare
   ↓
refine
   ↓
project
   ↓
execute
   ↓
observe
   ↓
compare
   ↓
adapt
Enter fullscreen mode Exit fullscreen mode

50. What differentiates T-DD from existing methodologies

Approach Central artifact Main question
TDD Test Does the code satisfy the test?
BDD Behavior/scenario Does the system exhibit the expected behavior?
DDD Domain model What is the domain model?
MDD Model How can implementation be generated/derived from the model?
Design by Contract Contract Which conditions must be true?
Statecharts State machine Which states/transitions are possible?
Event Sourcing Event history How did we reach the current state?
Process Mining Event log/process model How does the process actually occur?
Goal-oriented RE Goal Which objective needs to be accomplished?
T-DD Trajectory How does a valid intent evolve toward a destination under verifiable constraints?

This table does not claim that T-DD replaces the others.

The proposal is that these techniques can become projections or auxiliary mechanisms within a trajectory specification.

51. The role of trajectory as a new first-class artifact

The central proposition can be reduced to:

Software system
=
implementation
+
semantic trajectory
Enter fullscreen mode Exit fullscreen mode

and not simply:

Software system
=
code
Enter fullscreen mode Exit fullscreen mode

or:

Software system
=
current state
Enter fullscreen mode Exit fullscreen mode

The trajectory represents:

what was intended
+
what was allowed
+
what was done
+
by whom
+
when
+
under which state
+
with what evidence
+
toward which destination
Enter fullscreen mode Exit fullscreen mode

This is an amount of information that a final state alone cannot represent.

52. The conceptual contribution

It is important to separate the contribution of T-DD from what already exists.

It would not be correct to claim:

"No one has previously studied trajectories, intentions, states, contracts, or processes."

That would be false.

There are decades of research on:

  • intention;
  • goals;
  • processes;
  • workflows;
  • state machines;
  • temporal logic;
  • contracts;
  • traceability;
  • process mining;
  • intention in software engineering;
  • behavior;
  • event sourcing.

Recent work even explicitly proposes a view of intentions in software engineering, arguing that features, requirements, issues, changes, and bugs can be understood as different abstractions related to stakeholder intentions. A Vision on Intentions in Software Engineering

The specific contribution of T-DD lies in the composition:

Destiny
+
Intent
+
Behavior
+
Evidence
+
Contract
+
State
+
Actor
+
Skill
+
Trajectory
+
DSL
+
Conformance
Enter fullscreen mode Exit fullscreen mode

as a single methodological chain in which each layer refines the previous one.

53. A particularly important relationship with contemporary research on intentions

The research A Vision on Intentions in Software Engineering is especially close to T-DD.

The authors argue that several artifacts used in software development implicitly carry stakeholder intentions and propose mechanisms for declaring, tracking, and verifying these intentions throughout software evolution. A Vision on Intentions in Software Engineering

This strongly converges with:

Intent
 ↓
Specification
 ↓
Change
 ↓
Verification
Enter fullscreen mode Exit fullscreen mode

in T-DD.

The difference is that T-DD introduces an additional dimension:

Intent
 ↓
Trajectory
 ↓
Observed realization
Enter fullscreen mode Exit fullscreen mode

In other words, not only:

"does this change correspond to the intent?"
Enter fullscreen mode Exit fullscreen mode

but:

"did this execution realize the intent through a semantically valid trajectory?"
Enter fullscreen mode Exit fullscreen mode

54. T-DD as a bridge between intent and execution

We can finally formulate:

Intent
    ↓
semantic constraints
    ↓
trajectory space
    ↓
execution
    ↓
observed trajectory
    ↓
conformance
Enter fullscreen mode Exit fullscreen mode

This provides a bridge between levels that traditionally remain separated:

Human meaning
       ↓
Requirements
       ↓
Design
       ↓
Code
       ↓
Runtime
       ↓
Telemetry
Enter fullscreen mode Exit fullscreen mode

T-DD attempts to transform this chain into:

Human intention
       ↓
Semantic trajectory
       ↓
Executable specification
       ↓
Runtime execution
       ↓
Observable trajectory
       ↓
Formal comparison
Enter fullscreen mode Exit fullscreen mode

55. Normative principles of T-DD

An implementation that follows T-DD should ideally observe the following principles.

55.1 Semantics before technology 

meaning → implementation
Enter fullscreen mode Exit fullscreen mode

and not:

technology → inferred meaning
Enter fullscreen mode Exit fullscreen mode

55.2 Intent is not execution 

intent ≠ behavior
Enter fullscreen mode Exit fullscreen mode

55.3 Final state is not history 

state ≠ trajectory
Enter fullscreen mode Exit fullscreen mode

55.4 Evidence is part of the specification 

behavior without evidence
Enter fullscreen mode Exit fullscreen mode

is incomplete when verifiability is required.

55.5 Authority must be explicit 

actor → capability
Enter fullscreen mode Exit fullscreen mode

55.6 Contracts are semantic constraints 

contract → legal execution boundary
Enter fullscreen mode Exit fullscreen mode

55.7 Trajectories may be alternatives 

one intent
→ multiple valid trajectories
Enter fullscreen mode Exit fullscreen mode

55.8 Failures are part of the model 

failure
→ trajectory branch
Enter fullscreen mode Exit fullscreen mode

55.9 Implementation is a projection 

semantic model → implementation
Enter fullscreen mode Exit fullscreen mode

55.10 Execution must be comparable with the declaration 

declared trajectory
↔
observed trajectory
Enter fullscreen mode Exit fullscreen mode

56. The final definition

A summarized formal definition can be:

Trajectory-Driven Development is a software development method in which the system is progressively refined from semantic destinations and intents into behaviors, evidence, contracts, states, authorities, capabilities, and declared trajectories, from which executable implementations are derived and against which observed trajectories can be verified for conformance.

In notation:

T-DD =
    Semantic Declaration
    +
    Monotonic Refinement
    +
    Executable Projection
    +
    Runtime Observation
    +
    Trajectory Conformance
Enter fullscreen mode Exit fullscreen mode

And its fundamental property:

Implementation ⊨ ObservedTrajectory
             ⊨ DeclaredTrajectory
             ⊨ Behavior
             ⊨ Intent
             ⊨ Destiny
Enter fullscreen mode Exit fullscreen mode

57. The central thesis

T-DD can be summarized in a single statement:

Software should not be specified only by what it contains or by the state in which it ends, but also by the semantically valid trajectory through which it realizes an intent and reaches a destination.

Or, even more briefly:

Don't only specify the state.

Specify the trajectory.
Enter fullscreen mode Exit fullscreen mode

And, for agent systems:

Don't only constrain what the agent can do.

Constrain the trajectory through which
the agent may realize the intent.
Enter fullscreen mode Exit fullscreen mode

58. Fundamental scientific relationships

The foundation of T-DD can be organized as follows:

PSYCHOLOGY
    Intentions
    ↓
    Behavior
    ↓
    Goal pursuit

SOCIOLOGY
    Actor
    ↓
    Action
    ↓
    Context
    ↓
    Consequence

REQUIREMENTS ENGINEERING
    Goal
    ↓
    Requirement
    ↓
    Traceability

FORMAL METHODS
    State
    ↓
    Transition
    ↓
    Contract
    ↓
    Temporal Logic

PROCESS SCIENCE
    Process Model
    ↓
    Event Log
    ↓
    Conformance

COMPUTER SCIENCE
    Trace
    ↓
    Execution
    ↓
    Verification

T-DD
    Destiny
    ↓
    Intent
    ↓
    Behavior
    ↓
    Evidence
    ↓
    Contract
    ↓
    State
    ↓
    Actor
    ↓
    Skill
    ↓
    Trajectory
    ↓
    Implementation
    ↓
    Observed Trajectory
    ↓
    Conformance
Enter fullscreen mode Exit fullscreen mode

The proposal therefore does not emerge in isolation. It functions as an architectural synthesis of research lines that normally appear separately.

59. Fundamental references

Software engineering and formal methods

Hoare, C. A. R. — An Axiomatic Basis for Computer Programming (1969).
Foundation of Hoare logic and formal reasoning about program properties. ACM / bibliographic reference

Meyer, Bertrand — Applying "Design by Contract" (1992).
Foundation of contracts, invariants, preconditions, and postconditions.

Harel, David — Statecharts: A Visual Formalism for Complex Systems (1987).
Foundation for specifying complex behavioral systems using states, hierarchy, concurrency, and communication.

Pnueli / Clarke / Emerson / Sifakis — Temporal Logic and Model Checking.
Formal foundation for verifying properties over sequences of states and temporal behaviors.

Requirements Engineering

Gotel, O.; Finkelstein, A. — An Analysis of the Requirements Traceability Problem (1994).
Foundation of the traceability problem between intent/requirement and subsequent artifacts.

van Lamsweerde, Axel — Goal-Oriented Requirements Engineering.
Foundation for goal-oriented derivation. Goal-Oriented Requirements Engineering

Horkoff et al. — Goal-oriented requirements engineering: an extended systematic mapping study.
Systematic mapping of the goal-oriented requirements engineering field. Requirements Engineering / DOI

Process Mining

van der Aalst, W.; Weijters, T.; Maruster, L. — Workflow Mining: Discovering Process Models from Event Logs (2004).
Foundation of process discovery from logs.

van der Aalst, W. — Process Mining: Discovery, Conformance and Enhancement of Business Processes.
Fundamental work on process discovery, conformance, and evolution. Process Mining — Springer

van der Aalst, Adriansyah, van Dongen — Replaying History on Process Models for Conformance Checking and Performance Analysis.
Particularly relevant to the concept of comparing an observed trajectory against a declared trajectory. Article on conformance checking

Ghasemi; Amyot — From Event Logs to Goals: A Systematic Literature Review of Goal-Oriented Process Mining.
Directly connects event logs, goals, and process mining. Article / DOI

Khodabandelou et al. — Unsupervised Discovery of Intentional Process Models from Event Logs.
Particularly relevant to the relationship between intentions and observed trajectories. ACM Digital Library

Psychology and behavior

Ajzen, Icek — The Theory of Planned Behavior (1991).
Foundation for the distinction between intention, behavior, and perceived control.

This reference is important for T-DD because it prevents a dangerous simplification:

intent → guaranteed action
Enter fullscreen mode Exit fullscreen mode

The literature supports a more careful formulation:

intent → propensity toward behavior
Enter fullscreen mode Exit fullscreen mode

T-DD transforms this distinction into a computational concern:

intent
→ admissible behavior
→ executable trajectory
→ observed behavior
Enter fullscreen mode Exit fullscreen mode

Sociology, interaction, and situated action

Suchman, Lucy — Plans and Situated Actions.

The work is relevant to the distinction between an abstract specification and the situated realization of that specification. For T-DD, this reinforces:

Trajectory specification
≠
fixed execution script
Enter fullscreen mode Exit fullscreen mode

A trajectory can define invariants and conditions of realization without requiring a single operational strategy.

Event Sourcing

Fowler, Martin — Event Sourcing.

Event Sourcing provides a mechanism for preserving the historical sequence of changes and reconstructing previous states.

The relationship with T-DD is:

Event Sourcing
→ observed execution history

T-DD
→ semantic expected trajectory
Enter fullscreen mode Exit fullscreen mode

The combination of the two enables:

ExpectedTrajectory
        ↕
ObservedEventHistory
        ↓
Conformance
Enter fullscreen mode Exit fullscreen mode

60. Canonical implementation source

The experimental implementation and current evolution of the DSL are in the repository:

Intent-Trajectory-Driven-Development — GitHub

The current documentation already contains:

Destiny
Intent
Behavior
Evidence
Contract
State
Actor
Skill
Trajectory
DSL
Execution
Enter fullscreen mode Exit fullscreen mode

as well as .itdsl examples and RFC/SRFC areas. Current README.md

61. The next conceptual frontier

From this definition, the natural next step is not simply to create more syntax.

It is to formalize:

Trajectory Algebra
Enter fullscreen mode Exit fullscreen mode

with operations such as:

compose(T₁,T₂)
branch(T₁,T₂)
merge(T₁,T₂)
repeat(T)
optional(T)
alternative(T₁,T₂)
refine(T)
observe(T)
compare(T₁,T₂)
repair(T₁,T₂)
Enter fullscreen mode Exit fullscreen mode

and properties:

trajectory equivalence
trajectory refinement
trajectory conformance
trajectory distance
trajectory completeness
trajectory validity
trajectory authorization
trajectory temporal consistency
Enter fullscreen mode Exit fullscreen mode

From there, T-DD ceases to be merely a textual methodology and begins to become a computational theory of behavioral trajectories.

The final architecture can then be expressed as:

                 ┌───────────────┐
                 │    DESTINY    │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │    INTENT     │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │   BEHAVIOR    │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │   CONTRACT    │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │     STATE     │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │     ACTOR     │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │     SKILL     │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │  TRAJECTORY   │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │      DSL      │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │ IMPLEMENTATION│
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │   OBSERVED    │
                 │   TRAJECTORY  │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │  CONFORMANCE  │
                 └───────┬───────┘
                         │
                ┌────────┴────────┐
                ↓                 ↓
             CONFORM           DEVIATE
                                  ↓
                             REPLAN / REPAIR
                                  │
                                  └──────↺
Enter fullscreen mode Exit fullscreen mode

The central hypothesis of T-DD can finally be expressed in a single formula:

Correct Software
=
Implementation
⊨
Observed Trajectory
⊨
Declared Trajectory
⊨
Behavior
⊨
Intent
⊨
Destiny
Enter fullscreen mode Exit fullscreen mode

Or, in engineering terms:

Code is only a realization. The trajectory is the object that makes it possible to relate intent, behavior, state, authority, evidence, and destination in a structure that can be executed, observed, compared, and formally verified.

Top comments (0)