LANDMARK · 7 MIN · BUILD
Frame the problem before the prompt
After this landmark, you can state what a system must actually decide, verify, or produce before choosing a model, a prompt, or an architecture for it.
You can still explore it. We’re showing the shared explanation and a related practical view without hiding the knowledge.
Teams reach for a model before they’ve written down what the system needs to be right about, how wrong it’s allowed to be, and who checks it. That order produces elegant demos that fail in production, because the hard questions (what’s the failure mode, what’s reversible, who’s accountable when it’s wrong) get answered implicitly by whatever the model happens to do.
Framing means writing the task, the acceptable error, and the human role down before any architecture decision, so later choices (model, retrieval, guardrails) serve a spec instead of inventing one.
This is the canonical concept. It stays the same across learner lenses so personalization never changes the underlying facts.
What this looks like for you
Before asking an assistant to handle something recurring, write one sentence on what ‘good’ looks like and what a bad answer would cost you. It clarifies how much you need to check.
MAKE A DECISION
A team wants to add an AI feature that drafts customer refund decisions. What’s the first step?
CARRY THISPick one AI feature your team is building or considering. Write the one-sentence frame: what decision, what wrong costs, who checks.