In the RCCOF Framework™ (Role, Context, Constraint, Output format, Few-shot), Few-shot is the demonstration layer. It supplies approved input and output pairs so the model can imitate a voice rather than interpret a description of one. Adjectives such as friendly, authoritative or clear do not transfer a voice. A paragraph somebody already approved does.
What Few-shot in RCCOF is
Few-shot in the RCCOF Framework is the supply of worked examples inside the prompt: a small number of input and output pairs that demonstrate what an approved result looks like. It is the only layer of the framework that teaches by showing, and it is the layer that carries register, rhythm and restraint.
The mechanism is imitation rather than instruction. A model given examples conditions its output on their surface properties, which includes sentence length distribution, how often it hedges, whether it opens with a claim or a context sentence, and how it transitions. None of those properties can be reliably specified in words, which is why the other four layers cannot cover this ground.
Few-shot is also the cheapest layer to maintain well and the easiest to maintain badly. A single strong exemplar pair reused across a hundred prompts costs one approval. A set of exemplars nobody revisits after the house style changes quietly enforces a voice the organisation has abandoned.
Why adjectives cannot transfer a brand voice
Adjectives cannot transfer a brand voice because every adjective available for describing a voice is interpreted against a training distribution rather than against your archive. Asking for professional prose returns the average of everything the model has seen called professional, which is a real voice, just not yours.
The gap becomes obvious when the same description is handed to two teams:
| Description | What one team means | What another team means |
|---|---|---|
| Friendly | Second person, contractions, short sentences | Warm openings, first person plural, longer sentences |
| Authoritative | Declarative, unhedged, figures cited | Formal register, passive constructions, no contractions |
| Clear | Short sentences, common words | Defined terms, explicit structure, longer but precise |
| Confident | No hedging language at all | Hedging allowed where genuinely uncertain |
Every cell in that table is a defensible reading. The model picks one, consistently, and nobody discovers which until a reviewer says the output does not sound right without being able to say why. An exemplar removes the ambiguity in one step, because there is nothing left to interpret.
How many exemplars, and how to choose them
Choosing exemplars matters more than counting them, but both have practical answers. A small number of well-chosen pairs outperforms a large number of average ones, because every exemplar is also a claim about what a typical approved output looks like.
Selection criteria, in order of importance:
- Approved, not merely published. The exemplar should be something a reviewer would sign off again today, not something that shipped under deadline.
- Representative of the ordinary case. A brilliant outlier teaches the model to aim for an outlier, which it will miss while abandoning the reliable middle.
- Matched in length to the target. Exemplars far shorter than the intended output transfer their brevity along with their voice.
- Diverse in subject, consistent in voice. Examples that all cover one topic teach topic as well as register, and the topic will bleed into unrelated outputs.
Start with two or three pairs and add only when a specific failure justifies one. Each addition should be traceable to something that went wrong without it; otherwise the set grows until nobody can say what it is teaching.
Anatomy of a usable exemplar pair
A usable exemplar pair has two halves that both do work. The input half shows the kind of request the output answers; the output half shows the approved result. Supplying only the output half is the most common way this layer is weakened, because the model then has to guess what question the example was answering.
| Part | What it must contain | Common mistake |
|---|---|---|
| Input | A request in the same form your real prompts take | Omitted entirely, leaving the output unanchored |
| Output | A complete approved result, not an excerpt | A fragment, which teaches fragments |
| Boundary | An unambiguous marker between pairs and between the pair and the instruction | Formatting that blends into the surrounding prompt |
| Label | A statement that this is an example and not the task | The model answering the exemplar's input instead of the real one |
The last row causes a failure that looks like a malfunction. A prompt whose exemplar is not clearly marked as an example will sometimes come back with an answer to the exemplar's question, correctly formatted and entirely irrelevant, and the cause is a missing label rather than anything about the model.
Negative exemplars: showing what not to produce
Negative exemplars show a rejected output alongside a corrected one, and they earn their place when a failure keeps recurring despite a written prohibition. They are more expensive than positive exemplars in prompt length and in risk, so they are worth adding deliberately rather than by default.
Two rules keep them from backfiring:
- Always pair the rejection with the correction. A negative example on its own puts the unwanted pattern in front of the model with no alternative to move toward, which sometimes increases its frequency.
- Label the rejection unmistakably. The marker has to survive being read quickly and out of order, because an unlabelled bad example is simply a bad example.
Prefer a Constraint where a Constraint will do. If the failure can be stated as a countable prohibition, state it there and keep the exemplar block positive. Negative exemplars are for failures of register and shape that resist being written down as rules, which is exactly the category this layer exists for.
Comparative matrix: described voice against demonstrated voice
This comparative matrix puts a described voice against a demonstrated voice on the dimensions that decide whether a register survives from brief to output. The left column is what most prompts contain, and the failures listed there are the ones that reviewers struggle to articulate.
| Dimension | Voice described | Voice demonstrated |
|---|---|---|
| Carried by | Adjectives | Approved input and output pairs |
| Interpreted against | The model's training distribution | Your own archive |
| Sentence rhythm | Unspecified, defaults to the model's | Transferred from the exemplars |
| Review feedback | "It does not sound like us" | "It drifts from example two here" |
| Consistency across authors | Each author interprets differently | One shared reference |
| Cost to change | Rewrite descriptions, hope | Swap the exemplars |
Keeping exemplars fresh as the brand changes
Exemplars decay, and they decay invisibly because nothing breaks when they do. A set approved two years ago continues to produce output faithful to a voice the organisation has since moved away from, and the drift is attributed to the model rather than to the examples.
Three habits keep the set current:
- Date every exemplar and the approval behind it. An undated example cannot be audited, and an unaudited example is assumed correct forever.
- Review on style change, not on schedule. The trigger is a change to the house style or a new editorial standard, not the passage of time.
- Keep the set in one place. Exemplars pasted into individual prompts cannot be updated centrally, and after enough copies exist nobody knows which version is current.
Treat the exemplar set as an asset with an owner. It is the only part of a prompt library that encodes editorial judgement rather than instruction, which makes it both the most valuable piece and the one most likely to be copied into places where it will never be updated.
Few-shot against Role: identity against imitation
Few-shot and Role both shape how output sounds, which is why they are sometimes treated as alternatives. They are not. Role assigns an identity and a depth of authority; Few-shot demonstrates a register. A prompt can need both, and each fails in a way the other cannot repair.
| Property | Role | Few-shot |
|---|---|---|
| Mechanism | Description of an identity | Demonstration of a result |
| Controls | Depth, perspective, what counts as obvious | Rhythm, register, restraint |
| Failure when absent | Competent writing with no point of view | Correct content in the wrong register |
| Changes with | The task and its required expertise | The house style |
When the two conflict the exemplars usually win, because imitation is a stronger signal than description. That is worth knowing before debugging: output that ignores a carefully written Role is often obeying an exemplar that was written in a different voice.
Position of Few-shot in the 5-layer RCCOF specification
Few-shot occupies the fifth and final position in the RCCOF specification, after Output Format. It comes last because an exemplar demonstrates everything the previous four layers specified at once, and an exemplar that contradicts them is the strongest signal in the prompt.
- Role fixes who is speaking and with what authority.
- Context fixes what is true and who is being addressed.
- Constraint fixes what may not be done or claimed.
- Output Format fixes the structure the result must take.
- Few-shot fixes the register by demonstration rather than description.
This makes one standing check worth building into any review. Read the exemplars against the banned vocabulary list and against the format specification before shipping either. An exemplar that uses a forbidden construction, or that has a different anatomy from the one the format block requires, teaches the model to break the rule it was just given. The full specification sets out how the five layers combine.
Frequently asked questions about Few-shot in RCCOF
These are the questions most frequently asked about Few-shot in RCCOF once teams start assembling exemplar sets: whether examples can be generated rather than written, how many are enough, whether the technique still matters with larger models, and what to do when an exemplar and a constraint disagree.
Can I use generated output as an exemplar?
Only after a human has approved it as if it were original work. Using unreviewed generated text as an exemplar teaches the model its own tendencies, which compounds them rather than correcting them. The value of this layer comes from the editorial judgement in the approval, not from the text itself.
How many exemplars are enough?
Two or three chosen well are usually enough to transfer a register, and each further addition should be traceable to a specific failure it fixes. A set that has grown without that discipline is teaching things nobody can name, which is harder to debug than having no exemplars at all.
Do newer models still need Few-shot?
Newer models still need Few-shot, though less than older ones did. For general competence, less than they used to. For a specific house voice, just as much, because no amount of capability tells a model which of many defensible registers is yours. The layer is not compensating for weakness; it is supplying information that exists only in your archive.
What happens when an exemplar contradicts a constraint?
The exemplar usually prevails, and silently. Demonstration outweighs description, so a banned word appearing in an approved example will keep appearing in output despite the prohibition. Check the exemplars against the constraint list whenever either one changes.
Where do exemplars go in an RCCOF prompt?
Exemplars go in the Few-shot layer, after Role, Context, Constraint and Output Format and before the task. The master template allows one or two gold-standard paragraphs of real brand text.
Why use real brand text as an exemplar?
Real brand text carries the voice the output must match, including rhythm and word choice that adjectives cannot describe. That is the job RCCOF gives the Few-shot layer.