COSTAR (Context, Objective, Style, Tone, Audience, Response) structures the ask. ISATVON structures the ask and the answer, and adds three things COSTAR has no slot for: a self-verification step, a tool policy, and constraints with declared fallbacks.
| COSTAR | ISATVON | ISATVON adds |
|---|---|---|
| Context | S Source | The explicit “do not assume” boundary |
| Objective | I Instructions | Role and hard rules alongside the objective |
| Style | V Variables | Style becomes a measurable constraint with a fallback |
| Tone | V Variables | Same |
| Audience | V Variables | Same |
| Response | O Outcome | The reply itself in ISATVON structure |
| Not covered | A Automation | Step order + self-verification before answering |
| Not covered | T Tech Stack | Capabilities allowed/forbidden (search, code, citations) |
| Not covered | N Notification | Mandatory assumptions/confidence/omissions report |
COSTAR is a good framework and most of ISATVON overlaps with it. It came out of a competition-winning prompt engineering practice, and its six sections cover the things people most often leave out of a prompt: who the model is talking to, in what register, and what the reply should look like. If your prompts currently consist of one sentence and a hope, adopting COSTAR is a large improvement for very little effort.
The mapping table above shows this directly. Five of COSTAR’s six sections map cleanly onto ISATVON sections. ISATVON is not a replacement for the idea behind COSTAR; it is the same idea extended to cover what happens after the model starts writing.
Every framework encodes a theory of where prompts fail. COSTAR’s theory is that they fail because the ask is underspecified. ISATVON accepts that and adds a second theory: they also fail because the answer is unaccountable. Three sections exist only to address that.
Fixes the step order, then ends with a self-check the model has to run before it is allowed to answer: every figure sourced, every constraint met, every claim checked.
A prompt without this asks for an answer. A prompt with it asks for a checked answer. That is a different request, and models respond to it differently.
States which capabilities are allowed and which are forbidden: web search, code execution, citations, image generation.
Without it the model decides for itself whether to look something up or answer from memory, and it does not tell you which it chose. Two runs of the same prompt can differ for that reason alone.
Requires a closing report: assumptions made, confidence level, and anything requested that was not delivered.
This is the section that changes review time most. Silent omissions are the expensive failure mode, because you only find them after you have acted on the output.
Take a concrete request: summarise a 30-page vendor contract for a non-lawyer.
You get context (the contract), an objective (summarise the obligations), a style (plain English), a tone (neutral), an audience (a non-lawyer) and a response shape (bullets).
You will very likely get a good summary. What you will not get is any indication of which clauses the model skipped because they were ambiguous, whether it read all 30 pages or the first ten, or whether “90-day termination window” came from the document or from what contracts usually say.
You get all of the above, plus: S pins the summary to the supplied document and forbids filling gaps from general contract knowledge. A requires the model to confirm it covered every section before answering. T forbids web search. N forces it to list the clauses it found ambiguous and state its confidence.
The summary itself may be similar. The difference is that you now know what it is based on, and where not to trust it.
This is the general pattern. ISATVON rarely produces a dramatically better deliverable. It produces a deliverable you can review in minutes instead of re-reading the source to check it.
Seven sections and a mandated response format are not free, and the honest comparison includes the downsides.
The Lite template exists for the middle ground: the ISATVON sections that matter most, without the full ceremony.
COSTAR has no verification slot, so nothing stops the model from shipping unchecked claims. In our own side-by-side testing this showed up concretely: a COSTAR-framed launch email invented a “40% fewer interruptions” statistic out of nothing. The ISATVON version of the same task self-verified its word count and constraint list before answering and invented no figures, because A ends with an explicit self-check and I carries a “never invent figures” rule. This is an internal comparison, not a published benchmark, and one task is not evidence of a rate. The point is the mechanism: that verification step, not the section count, is where the difference comes from.
COSTAR is lighter and fine for one-shot stylistic tasks: a tweet, a rewrite, a tone change. Six sections, no ceremony.
ISATVON earns its extra sections when the answer has to be trustworthy: research, analysis, code, anything where you need to know what the model assumed, what it used, and whether it checked itself. The structured response also makes outputs comparable across platforms and across reruns.
Rule of thumb: if you’d be annoyed to discover the model silently invented a fact or broke a constraint, use ISATVON.
