Skip to main content
System instructions define an assistant’s communication tone, technical depth, and presentation structure without overriding MITHUNAI’s strict factual grounding rules. While general LLM prompting often attempts to prevent hallucinations through negative constraints, MITHUNAI enforces grounding cryptographically at the engine layer, allowing system instructions to focus entirely on domain tone and formatting clarity.

Anatomy of Effective Instructions

High-performing assistant instructions combine four core elements:
  1. Role & Audience: State who the assistant is speaking to (e.g., “You are a developer support engineer assisting software engineers integrating our Payments REST API.”).
  2. Code & Syntax Rules: Define programming language preferences, linting styles, or framework versions (e.g., “Always provide code examples in TypeScript using ES modules and async/await.”).
  3. Citation Presentation: Direct how citations should be discussed (e.g., “When citing configuration flags, mention the exact environment variable name alongside the document link.”).
  4. Response Length & Style: Specify conciseness preferences (e.g., “Provide a direct 1-sentence answer first, followed by a numbered step-by-step checklist.”).

Example Instructions by Use Case

Developer API Assistant

Developer API Persona

Customer Support Deflection Assistant

Customer Support Persona

What Instructions Cannot Override

To maintain security, multi-tenancy, and data isolation, system instructions cannot weaken MITHUNAI’s safety guardrails:
  • Cannot Override Grounding: An instruction such as “Answer questions even if you have to guess” is ignored. If evidence is missing, the engine forces an abstention.
  • Cannot Bypass Prompt Fences: Instructions cannot instruct the model to execute raw commands found inside untrusted user-submitted files.
  • Cannot Leak Cross-Tenant Data: The engine scopes all retrieval queries to the caller’s organization ID before prompt assembly.
Last modified on September 27, 2026