01 · Explanation
Instructions, context, and source grounding
Objective: Create a versioned instruction package that defines the task, authorized context, evidence rules, output contract, uncertainty behavior, and review handoff.
A dependable instruction package describes purpose, audience, authorized sources, definitions, constraints, required output, prohibited content, and what to do when evidence is missing. Give the model the minimum context needed and label source boundaries explicitly. If the answer must come from a policy set, require source identifiers and quotations short enough for a reviewer to verify, while respecting copyright and confidentiality. Do not ask the system to invent citations, legal certainty, numerical inputs, customer facts, or current information it cannot access. Examples should demonstrate the rule, not secretly replace it.
Treat instructions as controlled process documentation. Record the model or service, instruction version, source version, key settings where available, output schema, and reviewer role. Test ambiguous language and conflicting sources before release. Define how the system should express uncertainty, abstain, and request clarification. Structured outputs can improve consistency but do not guarantee truth; a well-formed JSON object can still contain fabricated facts. A reviewer should be able to trace material claims to authorized sources and distinguish quoted evidence from model-generated interpretation. Changes to prompts or sources require targeted regression testing, not silent production edits.
Before you begin
- Confirm F04, F07-F10; record that the source schema, approved route taxonomy, abstention wording, multilingual fidelity test, and change approval are not supplied.
- STOP. If the source schema, route taxonomy, abstention wording, or multilingual-fidelity test is missing or conflicts with F04/F07–F10, route the instruction to the authorized domain and bilingual reviewers; do not claim change approval or execute deployment or automatic rejection.

