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 has no verification slot, so nothing stops the model from shipping unchecked claims. In blind benchmarking this showed up concretely: a COSTAR-framed launch email invented a “40% fewer interruptions” statistic. The ISATVON version of the same task self-verified its word count and constraint list before answering and invented nothing, because A ends with an explicit self-check and I carries a “never invent figures” rule. That verification step, not the section count, is the framework’s real edge.
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.
