Inside a Master Prompt: Variables, Schema, Guardrails, and Why Each Part Exists

A master prompt is easier to understand when you stop treating it as one large block of text.

It is a set of parts with different owners and different failure modes. Instructions guide the model. Variables define runtime inputs. A schema defines the object the application accepts. Constraints describe edge behavior. Metadata tells the team which artifact ran.

Putting all of that into one versioned blueprint is what turns prompt writing into maintainable application work.

The Artifact at a Glance

A CyWire master prompt has this general shape:

{
  "slug": "supplier-incident-review",
  "name": "Supplier Incident Review",
  "industry": "manufacturing",
  "use_case": "quality_review",
  "full_prompt_text": "Compiled instruction sent to the model...",
  "sections": {
    "identity": "...",
    "industry_context": "...",
    "task_instructions": "...",
    "output_format": "...",
    "quality_safety": "...",
    "constraints": "..."
  },
  "variables": {},
  "output_schema": {},
  "schema_strict": true,
  "metadata": {
    "version_number": 1,
    "tags": ["supplier", "quality", "incident"]
  }
}

The exact fields inside variables and schema change by workflow. The architectural responsibilities do not.

1. Identity: The Working Role

Identity tells the model which expertise and decision posture the task requires.

Weak identity:

You are a helpful quality expert.

Useful identity:

You review supplier incident records for a manufacturing quality team.
Use only the supplied evidence. Distinguish observed facts from proposed causes.
Do not make final regulatory or disposition decisions.

The second version narrows role, evidence, and authority. It does not ask the model to impersonate a real credentialed person or make decisions reserved for a human.

Identity should change how the task is performed. If deleting it does not change behavior, it is decoration.

2. Industry Context: The Operating Environment

The same words can mean different things in different workflows. "Incident," "case," "review," and "severity" need operational context.

Industry context can define:

• who creates and consumes the result;
• what source records normally contain;
• which terminology is expected;
• which standards or policies matter;
• where human approval remains required.

This section should not become a textbook about the industry. Include only context that changes the model's decision or output.

3. Task Instructions: The Actual Workflow

Task instructions are usually the largest section because they define the sequence of work.

For a supplier incident review, the sequence might be:

1. Extract observed facts from the source report.
2. Identify missing evidence without filling the gaps.
3. Classify severity using supplied business rules.
4. Separate likely causes from confirmed causes.
5. Recommend the next review action.
6. Return the required structured object.

Sequence matters. Asking for a cause before forcing the model to identify missing evidence encourages premature conclusions.

Good task instructions also include local examples near difficult rules. CyWire calls these microshot examples: small examples attached to the instruction they clarify, not one oversized sample at the end.

Observed fact: "Seal was torn when the carton arrived."
Not an observed fact: "Carrier mishandling caused the tear."

That example teaches a decision boundary without forcing every output to copy one complete sample.

4. Output Format: The Handoff to Software

The output-format section tells the model how its response connects to the schema. It should be short and direct:

Return one JSON object matching the supplied output schema.
Do not wrap the object in markdown.
Use null only where the schema permits null.
Do not add undeclared properties.

The output-format prose supports the schema; it does not replace it. The schema remains the machine-readable contract.

5. Quality and Safety: What a Useful Result Requires

Quality rules describe the standards that apply across the whole response:

Keep facts separate from analysis.
Tie every conclusion to supplied evidence.
Flag contradictory source statements.
Do not present a proposed action as completed work.

Safety is workflow-specific. A marketing outline and a clinical documentation workflow do not need the same controls. Generic warnings pasted into every prompt create noise and can hide the rules that matter.

This layer guides behavior. Authorization, privacy enforcement, and data access still belong in application infrastructure.

6. Constraints: Hard Boundaries

Constraints state what the model must not do and how it should respond at the boundary.

Do not infer a supplier name that is absent from the source.
Do not assign a severity when required evidence is missing.
Do not recommend closing the incident without a documented review.
Do not return fields outside the schema.

A useful constraint names a likely failure and the expected alternative. "Do not hallucinate" is not operational. "Set evidence_status to insufficient and list missing items" is.

Variables: The Runtime Interface

Variables separate stable workflow logic from changing request data:

{
  "incident_text": {
    "type": "string",
    "required": true,
    "description": "The unmodified supplier incident report"
  },
  "severity_policy": {
    "type": "string",
    "required": true,
    "description": "The approved internal severity criteria"
  }
}

Declared variables create a clean integration boundary. They also make missing data visible before the model call instead of burying undefined inside a long string.

Read Master Prompt Variables for injection, validation, and naming patterns.

Output Schema: The Response Interface

The output schema defines fields and types for downstream code:

{
  "type": "object",
  "required": ["severity", "evidence_status", "facts", "next_action"],
  "additionalProperties": false,
  "properties": {
    "severity": {
      "type": "string",
      "enum": ["low", "medium", "high", "undetermined"]
    },
    "evidence_status": {
      "type": "string",
      "enum": ["sufficient", "insufficient", "conflicting"]
    },
    "facts": {
      "type": "array",
      "items": { "type": "string" }
    },
    "next_action": { "type": "string" }
  }
}

Notice that uncertainty is represented in the contract. Without undetermined or an evidence-status field, the model may be forced to choose a confident value when the source cannot support one.

Read Why Every Master Prompt Needs a JSON Schema for deeper design guidance.

Metadata and Version Identity

Metadata supports operations around the prompt: version number, tags, counts, and lineage. It should not silently affect model behavior.

The important runtime field is the prompt version. Save it with generated output so an old result can be traced to the exact published snapshot that produced it.

The Design Test

For every rule, ask where it belongs:

• Does it explain a decision? Put it in task instructions.
• Does it define a required input? Make it a variable.
• Does it define an allowed output? Put it in the schema.
• Does it prohibit a known failure? Make it a constraint.
• Does it describe ownership or lineage? Keep it in metadata.

When one paragraph tries to do all five jobs, the prompt becomes difficult to test and easy to break.

Browse the CyWire marketplace to inspect how these layers are applied to real industry workflows.