# Journey structures
The third stage of the pipeline, run by the Architect. This page explains what a journey structure is and how it is expressed.
TIP
Part 4 of the step-by-step guide generates a structure from a requirement and creates it.
A journey structure is the outline of a test: an ordered set of checkpoints, each carrying an objective describing what that checkpoint must achieve, rather than the finished steps that achieve it. Objectives usually read as concise instructions ("click the 'Add to cart' button", "look for the heading with the product name") and may reference data-table columns. What they leave out is the part that depends on the live application: which element on the page satisfies the instruction, how to identify it reliably, and how long to wait for it. Working that out against the running application is Autopilot's job.
A journey structure also carries a one-line summary of what the journey proves, and a plain-language statement of overall intent that Autopilot falls back on where an individual objective doesn't capture the nuance.
How a structure is expressed. Rather than storing a finished list of steps, a journey structure is an ordered list of operations describing how its checkpoints are built or changed. Five operations exist:
| Operation | What it does | Used when |
|---|---|---|
| Checkpoint | Define a new checkpoint, carrying the intent it must satisfy | Creating and updating |
| Library checkpoint | Reuse an existing shared checkpoint, with the reason it applies here | Creating and updating |
| Keep | Leave an existing checkpoint untouched | Updating only |
| Modify | Change an existing checkpoint's intent | Updating only |
| Remove | Drop a checkpoint from the journey | Updating only |
Building a new journey uses only the two that introduce checkpoints: new and library. Updating an existing one uses all five, so every existing checkpoint is accounted for explicitly: kept, modified or removed, each with a stated reason. That's what makes a modification reviewable as a precise delta rather than an opaque rewrite. You see exactly which steps survive, which change, which go, and which are new, before anything is written.
Only some operations reach Autopilot. Adding a library checkpoint, keeping one, or removing one are structural changes the platform applies directly. There's nothing for an agent to work out. It's the inline and modify operations that carry intent, and those are what Autopilot acts on.
The order of the list is the order of the journey; there's no separate re-ordering step, and removing a checkpoint simply drops it from the sequence.
Further actions on a structure are coming: converting a checkpoint into a library one and back, and comparing a checkpoint's previous intent against its revised intent. Until those land, expect a generation to produce newly created checkpoints, each badged NEW.
Generating a journey structure also creates or reuses the supporting Virtuoso assets:
- Goals. New, or an existing goal you select; you provide the starting URL. Every journey begins by navigating to it, or reuses a checkpoint that does.
- Data tables. Scenario data as named columns and rows, referenced from checkpoints by column name rather than hardcoded into steps. Once a journey is created you can see which table it's associated with, and the attributes that table provides, from the journey's own panel in the goal. Generation tends to give each journey its own table rather than sharing one, even where several journeys need the same columns; a table is marked with the journey that references it. Submit an Agent Instruction in the Chat if you'd rather they were consolidated. Tables remain adjustable in the Chat.
- Environment variables. The recommended home for environment-specific values such as base URLs and credentials, rather than data tables.
- Library checkpoints. Reuse of existing shared checkpoints is being introduced. Generation currently produces new checkpoints, badged NEW in the structure. Where a familiar step has been recreated rather than reused, say so in the Chat.
Where the source material is ambiguous, Touchstone raises explicit questions or states the assumption it's making, rather than inventing behaviour to fill the gap.