Business Rules - Prompt Engineering

This document lists the fundamental business rules of the Prompt Engineering domain, identified by a unique BR-NNN code. Each rule is technology-independent and describes an invariant constraint on prompt design and evaluation.

---

BR-001 - Every Prompt declares instruction, context and output indicator

Code: BR-001 Name: Minimum structure of an effective prompt Description: A production-bound PromptTemplate must contain explicit components: the instruction (what to do), the relevant context and the output indicator (response format/criteria). An ambiguous prompt lacking these components is not considered ready. Rationale: Reduce ambiguity and increase reproducibility of model behaviour. Priority: HIGH Actors: Prompt Engineer Traceability: INV-01; prompt-authoring.md.

---

BR-002 - Separation between instructions and untrusted data

Code: BR-002 Name: User data is never treated as instructions Description: Content provided by the user or by external sources must be wrapped in explicit Delimiters and treated as data, never as part of the System Prompt instructions. The template must prevent data from injecting new instructions. Rationale: Defend against prompt injection (the domain's main vulnerability). Priority: CRITICAL Actors: Prompt Engineer, Guardrail Violation: input attempting to override instructions is neutralised or flagged. Traceability: OWASP LLM Top 10 (LLM01); INV-04.

---

BR-003 - Every prompt change is validated by an evaluation

Code: BR-003 Name: Mandatory testing before adoption Description: A new PromptTemplate version is not adopted without being run on a suite of representative TestCases, with metrics (correctness, faithfulness, format, cost) compared against the previous version. Rationale: Avoid regressions: a small change to a prompt can degrade results in non-obvious ways. Priority: HIGH Actors: Prompt Engineer, Evaluator Violation: adoption is blocked if the evaluation regresses. Traceability: prompt-evaluation.md; INV-02.

---

BR-004 - Few-shot examples are representative and consistent

Code: BR-004 Name: Quality and consistency of examples Description: The few-shot Examples included in a prompt must be correct, consistent in format with the expected output and representative of real cases, including edge cases. Contradictory or incorrect examples must be removed. Rationale: The model imitates the examples; inconsistent examples produce inconsistent output (in-context learning). Priority: HIGH Actors: Prompt Engineer Traceability: prompt-authoring.md; INV-03.

---

BR-005 - Structured output is constrained and validated

Code: BR-005 Name: Schema and validation for machine-readable output Description: When a prompt requires structured output (e.g. JSON), it must declare the expected schema in the output indicator and the output must be validated before downstream use. Malformed output triggers a constrained retry or a fallback. Rationale: Ensure the output is consumable by automated systems without parsing errors. Priority: HIGH Actors: Prompt Engineer, Application Service Traceability: prompt-authoring.md; INV-05.

---

BR-006 - Factual claims are grounded

Code: BR-006 Name: Grounding to reduce hallucinations Description: For factual tasks, the prompt must instruct the model to base the answer on the provided context (RAG) and to declare uncertainty when the context is insufficient, rather than inventing. Grounded answers cite the source. Rationale: Reduce the hallucination rate and increase faithfulness. Priority: HIGH Actors: Prompt Engineer Traceability: INV-06; prompt-evaluation.md.

---

BR-007 - Sampling parameters consistent with the task

Code: BR-007 Name: Temperature and parameters suited to the task type Description: Sampling parameters (temperature, top-p, max tokens, stop sequence) must be consistent with the task: low values for deterministic/factual and structured tasks, higher values for creative tasks. The choice is documented in the template. Rationale: Unstable or truncated output often stems from inadequate parameters. Priority: MEDIUM Actors: Prompt Engineer Traceability: domain-faq.md (temperature); INV-07.

---

BR-008 - Versioning and reproducibility of prompts

Code: BR-008 Name: Every adopted prompt is versioned and traceable Description: Every adopted PromptTemplate must have an identifiable, immutable version, with a reference to the evaluation that motivated its adoption. Previous versions remain available for comparison and restoration. Rationale: Reproducibility, A/B comparison and the ability to revert to a better version. Priority: HIGH Actors: Prompt Engineer Traceability: BR-003; prompt-evaluation.md; INV-08.