# Building blocks
Four things run through every stage of the Touchstone pipeline rather than belonging to one of them: the directives that carry your standards into generation, the proposals every generation produces and how you review them, the notifications that tell you what finished while you were away, and the sequence each Chat response goes through. This page covers those. The stages themselves each have their own page: Knowledge Base, Requirements, Journey structures and Autopilot.
# Directives
TIP
Part 2 of the step-by-step guide sets a directive up from scratch.
Directives are persistent instructions injected into generation: the mechanism for encoding your team's standards once rather than repeating them per conversation. Each directive belongs to one of three targets, and only reaches the stage it was written for. Three types are supported:
- Instructions. Shape the logic of what's generated. For example: produce a test case for each realistic failure mode in addition to the happy path.
- Conventions. Enforce naming and structural rules, such as prefixes or naming schemes for requirements.
- Templates. Define the output format of generated requirements: the sections, structure and acceptance-criteria layout you expect. Templates apply to requirements only; journey and Autopilot directives offer instructions and conventions.
Instructions and conventions are placed together, but Touchstone tells the analysis to read each for a different purpose, so the same text has a different effect depending on which you file it under. Put naming and formatting rules in conventions and domain knowledge in instructions, and each will be applied as intended; mix them up and both get weaker.
Each directive targets one stage of the pipeline, and is given a name. There are three targets, managed separately:
- Analyst directives. Shape how requirements are analysed and written. The only target that offers templates.
- Architect directives. Shape how journey structures are generated from requirements.
- Autopilot directives. Shape how Autopilot implements a journey: the conventions your generated steps should follow, and the standing context it should apply on every run. Use these for the guidance you'd otherwise repeat in the Chat before each run.
Directives exist at organisation level (inherited by all projects) and project level. Organisation directives are marked Inherited when viewed from a project, so it's clear which rules came from where. A project directive replaces the organisation directive of the same name. Directives with different names stack, so a project adds to the organisation's set rather than replacing it wholesale, and you can override a single organisation rule for one project without disturbing the rest.
Each directive carries a priority, which sets the order in which directives of the same type are presented to the model. That is why it matters: where a set is long, the ones you rank highest are read first. Priority does not decide which directive wins where two overlap: that is settled by name. Preview prompt, at the top of each directive list, shows exactly what will be injected for that target, the whole set as the analysis will receive it, not one directive at a time, so behaviour is inspectable rather than opaque. Disabling a directive takes it out of effect immediately.
Each directive is versioned, and the list shows its current version alongside its size, so you can see at a glance which rules have been revised and which are large enough to be worth distilling.
Use Directives for rules and conventions; keep detailed policies, standards and regulations in the Knowledge Base and reference them in conversation when relevant.
Directives steer generation; they don't enforce it. They're guidance to the analysis, and the product's own rules take precedence where the two conflict, so a directive can be applied partially, or occasionally not at all. Three practical consequences: there's a size budget for the directives applied to any one scope, so large rule sets need distilling rather than pasting; many overlapping directives dilute each other and can conflict; and directive text is screened on save, which occasionally means rewording a legitimate rule that reads like an instruction to disregard something.
# Proposals, versioning and review
Whenever you submit an Agent Instruction within a Chat, any generated assets appear as proposals alongside the conversation. Nothing Touchstone suggests reaches your project on its own: a proposal is a suggestion you decide on.
Proposal is one shared concept across the pipeline: requirements, journey structures, test-data tables and environments are all proposals, each proposed separately so you can accept one and reject another from the same response, and all behave the same way.
A proposal starts as a new suggestion awaiting your decision, and you have four moves:
| Action | Effect |
|---|---|
| Approve | Marks it ready to create and locks it: Touchstone won't change or re-propose it in later replies |
| Reject | Declines it and locks it, so Touchstone won't change or re-propose it. You aren't prompted for a reason; it simply drops out of the proposals waiting to be created |
| Edit | Change it directly. Your edit is fed back, so later output reflects what you actually wanted |
| Undo | Reverses an approve or reject if you change your mind. An approved or rejected proposal can't be edited until it's undone |
Approving isn't the same as creating. An approved proposal is marked ready; creating it is a separate, deliberate action that writes it into your project as a real Virtuoso asset. Until you create it, nothing has left the conversation.
After creation, the proposal is closed. It stays visible in the conversation history, but you can no longer refine it through the Chat: a created requirement is a project asset, edited like any other. To iterate on it further, ask in the Chat for a copy: Touchstone will propose a duplicate you can refine and create as a new asset.
While a proposal is still open you can refine it by submitting further Agent Instructions within the Chat: ask for a different title, more acceptance criteria, a tightened scope. What you can't do in the Chat is approve or reject: those decisions are deliberately yours to make in the interface, not something you can delegate to the conversation.
Every iteration creates a new version, whether it came from Touchstone or from your own edit, and each version is chained to the one before it. Nothing is overwritten: the full history is kept, you can see how a proposal reached its current state, and you can roll back to an earlier version if an iteration moved in the wrong direction.
Proposals belong to the conversation that produced them, which is what makes a follow-up refine an existing proposal rather than create a near-duplicate alongside it. Conversation history is retained, so previous sessions remain available.
Long conversations are compressed as they grow: earlier exchanges are condensed into a summary that preserves the decisions, constraints and details you've established, so a long session doesn't lose the context you set at the start.
# What happens during a response
Each Agent Instruction runs through a short sequence: planning the work, summarising the Chat so far if it has grown long, checking whether Touchstone already has enough context, retrieving relevant sources and existing project assets, expanding the most relevant documents to full text, then generating the response. Not every Agent Instruction touches every step: a straightforward question can skip retrieval entirely, and journey generation doesn't expand documents up front because it fetches them as it writes.
The interface reports two of these stages while it responds to an Agent Instruction: Extracting information while it retrieves, then Generating response while it generates.
A generation that never reports extracting didn't consult your Knowledge Base, usually a sign the Agent Instruction was answerable from the Chat, or that it needed to be more specific. Expect a minute or two overall; proposals appear together when the response finishes.
# Notifications
TIP
Part 7 of the step-by-step guide works through the panel.
Touchstone works in the background: analyses finish while you're elsewhere, runs complete, sources land, colleagues comment. Notifications is where that activity collects, so you can pick up what happened without reopening every conversation to find out. It opens from the bell in the top bar, which carries an unread count.
Notifications are raised across six areas:
| Type | Raised when |
|---|---|
| Analyst | A requirements analysis responds, or a source is added to or updated in the Knowledge Base |
| Architect | A journey structure analysis responds |
| Autopilot | A run finishes, with its result, for example "4 completed, 0 failed out of 4 checkpoints" |
| Comments | Someone comments on work you're involved in |
| Executions | A journey execution completes |
| Orchestrations | A scheduled or pipeline-triggered run of a suite of journeys reaches a reportable state |
Notifications from the same conversation are grouped under one heading with a count, and each carries its type, a summary and a relative timestamp, with a dot marking it unread. Most also carry a direct link to whatever they concern, Go to chat, Go to knowledge base source, so you can act on the item without hunting for it.
Two controls sit above the list: an Unread / All toggle, and a type filter where each of the six areas can be switched on or off independently, so you can narrow to just the runs or just the Chat. Mark all as read clears the unread state in one action. An expand control opens the panel to full width when the summaries are long.
How long notifications are kept. The list clears itself on a schedule, and deliberately keeps unread items longer than read ones:
| State | Kept for |
|---|---|
| Read | 30 days |
| Unread | 90 days |
The asymmetry is the point: something you've already seen has served its purpose and clears in a month, while something nobody has looked at is the one you can least afford to lose, and is kept for three.
Retention applies to the notification, not the work. When a notification is removed your requirements, journeys and sources are untouched. You lose the prompt, not the asset, and the asset remains reachable through the project as normal.