How to use these prompts

The prompts below support the analytic steps of the method. They do not run the workshop. The map comes from the room, and the prompts work on what the room produced.

Every prompt follows the same six house rules.

1. Show the evidenceFor each judgement, quote the material it came from and say where the quote sits.
2. Separate support from inferenceLabel anything the model added as INFERRED, and say what would confirm it.
3. Say when the material is silentA gap is an answer. Filling a gap with a plausible invention is the main failure mode.
4. Never claim a linkage the tool does not containIf a framework or tool has no entry for something, the answer is that it has no entry.
5. Two coders, then reconcileRun the coding prompts twice, independently, and report the disagreements. The disagreement is a finding.
6. Run the traceability checkPrompt 9 checks every other output before anyone relies on it.

1. Persona development from workshop material

Purpose: build personas from evidence rather than from invention, and find the positions nobody in the room occupied.

You are helping a research team turn workshop material into personas for a
service pathway map.

INPUT: [raw workshop notes, transcripts, journey artefacts]

TASK
1. Identify every distinct position in the system the material describes: people
   who use the service, people who deliver it, people who refer into it, unpaid
   carers, and anyone the material implies but does not name.
2. For each position, build a persona containing ONLY what the material supports:
   who they are, what they are trying to achieve, what the pathway demands of them
   at each step, what they bring in time, money, language, confidence and support,
   and what constrains them.
3. For every attribute, cite the quote or note it came from. Label anything that is
   a reasonable inference INFERRED, and say what would confirm it.
4. Do not invent names, ages, jobs, family circumstances, diagnoses or quotes. If
   the material gives no name, use a functional label such as "parent of a child
   referred by a health visitor".
5. Flag any position that appears only in someone else's words. That is a gap in
   the room, not a persona.
6. End with a list of what you could not determine.

Check the output: every attribute carries a quote or an INFERRED label, no names are invented, the gaps list is not empty, and no persona is built only from staff descriptions without being flagged.

2. Journey mapping consolidation

Purpose: turn scattered material into pathways that can be walked and compared, without smoothing them.

INPUT: [workshop notes, journey artefacts, transcripts, any pathway documents]

TASK
1. For each persona, reconstruct the journey as steps from first contact to exit,
   using the participants' own step names where they gave them.
2. For each step record: who does what, how long it takes, what the persona has to
   do to make it happen, and what they are told.
3. Mark three things separately: the designed pathway, the lived pathway, and the
   work the persona does to bridge the gap between them.
4. Record every point where the persona has to chase, repeat, wait, translate, pay
   or arrange something themselves.
5. Where a step has no evidence, leave it empty and write NO EVIDENCE. Do not smooth
   the journey to make it continuous.
6. Flag every step where the material contradicts itself, quoting both versions.

Check the output: does any journey look cleaner than the material warrants, are contradictions preserved rather than resolved, and is the bridging work recorded.

3. Needs analysis coding to the Theoretical Domains Framework

Purpose: code the demands and barriers to the framework, with an actor and a behaviour attached to every code. The mechanism step that follows uses the same framework extended, so a determinant coded to a TDF domain normally has a matching mechanism entry.

INPUT: [coded journey material: steps, touch points, reported emotion, quotes]
FRAMEWORK: Theoretical Domains Framework. Use only its published domains and
definitions. [paste the domains and definitions you are using]

TASK
1. For each domain, list every item that belongs to it, with the quote.
2. State the behaviour being explained and the actor. A domain code without an
   actor and a behaviour is not a finding.
3. Give a confidence for each code: HIGH (explicit), MEDIUM (implied, show the
   working), LOW (weak or single mention).
4. Record where an item fits two domains rather than forcing it into one, and say
   what the overlap is.
5. Record items that fit no domain. Do not invent a domain and do not stretch a
   definition. A no-domain bucket is a legitimate and often interesting output.
6. Keep system-level findings at system level. If the material describes a system
   condition rather than a person's behaviour, say so and do not code it as an
   individual-level domain.
7. Report which domains are empty. Empty domains are a finding about the material.

Check the output: every code names an actor and a behaviour, overlaps are recorded rather than resolved, nothing has been forced to fit, and the unmapped bucket exists.

4. Mapping coded determinants to behaviour change techniques

Purpose: move from determinants to candidate techniques using a linkage resource, not the model's own opinion.

INPUT: [the coded determinants, with quotes and confidence]
RESOURCE: the Theory and Techniques Tool, which links mechanisms of action to
behaviour change techniques. Its mechanism list is the Theoretical Domains Framework
extended: the 14 TDF domains plus 12 further constructs from a set of 83 theories of
behaviour change, 26 mechanisms in all. Also the behaviour change technique taxonomy
version 1, which lists 93 techniques in 16 clusters.
[paste the tool extract for the mechanisms in play]

TASK
1. For each coded determinant, name the mechanism of action it operates through,
   citing the tool's own entry. If the tool has no mechanism for that determinant,
   write "no linkage in the tool" and stop.
2. From the tool's links for that mechanism, list the candidate techniques with the
   technique number, its published label, and the tool's confidence for the link.
3. Mark each candidate CORE, OPTIONAL or DO NOT USE, with the reason. A technique the
   material contradicts is DO NOT USE.
4. For each candidate, state what it would look like in this service: who delivers
   it, to whom, at which step, and what would have to be true for it to work.
5. Do not invent technique numbers or labels.
6. Finish with the limits. A tool link says experts associate a technique with a
   mechanism. It does not say the technique works in this service.

Check the output: every technique number exists in the taxonomy, every mechanism cites the tool, no linkage is invented, and the limits paragraph is present.

5. Mapping CFIR to ERIC implementation strategies

Purpose: shortlist strategies through the matching tool, with the tiers kept honest.

INPUT: [CFIR-coded barriers and enablers]
RESOURCE: the CFIR-ERIC matching tool, which maps CFIR barriers to ERIC strategies
with an expert-endorsement tier for each pairing - the endorsed tier and the
less-endorsed tier. [paste the tool rows for these barriers]

TASK
1. Restate each barrier in CFIR terms, naming the domain and construct.
2. For each barrier, list the tool's recommended strategies with the ERIC number,
   the published strategy name, and the tier. Never present a less-endorsed
   strategy as though it were the top tier.
3. Mark which recommendations the team had already planned, and which are new.
4. For each candidate, state the mechanism you expect it to work through, the
   actor, the resource it needs, and how you would know it had happened. The
   matching tool does not supply the mechanism. You do, and you label it as your
   reasoning.
5. Where a recommended strategy is not feasible in this service, say so and why,
   rather than reporting it as a recommendation you will follow.
6. Note that the tool encodes expert consensus, not trial evidence.

Check the output: tiers are correct, no strategy is invented, mechanisms are labelled as reasoning rather than tool output, and infeasible recommendations are named rather than buried.

6. Journey map to causal loop diagram

Purpose: convert the map into variables and causal links, so that feedback becomes visible.

INPUT: [the consolidated journey map and coded material]
IF IMAGE: [attach the map]

TASK
1. Convert the map into variables. Each variable must be a quantity that can rise
   or fall, not an activity or a person. Rewrite anything that is not a quantity.
2. Propose causal links as: A affects B, with the polarity (positive means A and B
   move in the same direction) and the delay, if any.
3. For each link, cite the material that supports it. Do not add a link because the
   diagram looks better with it.
4. Identify the feedback loops and label each as reinforcing or balancing, naming
   the loop after its main variable.
5. List the most connected variables and say what they connect.
6. Mark links the material supports weakly, and links that follow only from the
   team's reasoning.
7. State what the diagram does not show: people, money, time, and anything outside
   the boundary you chose.

Check the output: every variable is a quantity, every link has a polarity and an evidence note, the boundary is stated, and no link exists only to close a loop.

7. Loop and leverage analysis

Purpose: choose where to intervene, with the reasoning and the risks shown.

INPUT: [the causal loop diagram, its loops, and the connection counts]

TASK
1. Rank the variables by connectivity and by how many loops they sit in. Give the
   count.
2. For the top variables, say what a change there would do elsewhere in the map,
   and whether that is good or bad for each persona.
3. Name the loops that sustain the current problem, and what would weaken them.
4. Say explicitly which variables are highly connected because of how the map was
   drawn rather than because of anything in the service.
5. Recommend at most five intervention points, each with the variable, the intended
   effect, the mechanism, the risk of a compensating effect elsewhere, and what
   would show it was working.
6. State what the map cannot tell you about effect size, cost or feasibility.

Check the output: connectivity is counted not asserted, the drawing-artefact caveat is present, and each recommendation names a mechanism and a compensating risk.

8. Logic model assembly

Purpose: assemble inputs, activities, outcomes and impact, with every row labelled for how it is known.

INPUT: [the coded determinants, the candidate techniques and strategies, the
leverage points, and the outcome measures the team intends to use]

TASK
1. INPUTS: the staff, time, money, materials and access the plan requires. Include
   the unpaid work the journeys revealed, because that is a real input.
2. ACTIVITIES: each technique or strategy, named exactly as in its taxonomy, with
   who delivers it, to whom, at which step, and how often.
3. SHORT-TERM OUTCOMES: the determinants you expect to move, each named with its
   framework and how it will be measured.
4. MEDIUM-TERM OUTCOMES: the behaviour changes expected in each actor, with the
   measure.
5. IMPACT: the health, wellbeing or service outcomes, and the chain of reasoning
   that gets there.
6. For every row, state the evidence it rests on and label it: MEASURED IN THIS
   PROJECT, DERIVED FROM THE MAP, or ASSUMED.
7. Collect every assumption in one place at the end.
8. State what would falsify the model.

Check the output: no row claims effect evidence it does not have, assumptions are collected in one place, and the taxonomy names are exact.

9. Traceability check

Purpose: the check that runs on every output before anyone uses it.

INPUT: [any output from prompts 1 to 8]

TASK
For each claim in the output:
1. Quote the material it rests on.
2. State whether the material says it directly, implies it, or does not support it.
3. If the material does not support it, move the claim to the unsupported list.
4. Check every citation: does the source exist, and does it say what is claimed.
5. Check every framework term against the framework's own list, and report any term
   that is not in it.
6. Report what the output asserts without evidence, and what it omits that the
   material plainly contains.

Check the output: supported, inferred and unsupported lists are all present, citation errors are named, and omissions are reported.

Two notes for the trainer

Run prompts 3 and 4 twice, by two people, then reconcile. Report the disagreements, because the disagreement is the finding about how hard the coding is.