Prompt – LLM Prompting Variables

Prompt Description

Prompt design reference document used to standardize orchestration behavior, variables, and interaction controls.

Execution Context

• Topic / Scope: Canonical variable contract for user controls, admin locks, and runtime payload merge rules.
• Upstream Inputs: Source specification from /mnt/hasmaster_1000/design/prompting/llm-prompting-variables.md.
• Downstream Consumer: Prompt authors, orchestrator/runtime implementers, and QA reviewers.

System Usage

• Used By: prompt development and runtime prompt governance
• Trigger: when defining or updating interaction-style variable schema and payload contracts
• Inputs: prompting policy, journey requirements, and orchestration constraints
• Outputs: validated variable spec and payload contract guidance

Canonical Prompt Payload

# LLM Prompting Variables (Canonical Control Spec)

Purpose: define which variables are user-selectable in real time vs locked by system policy, and define the exact payload contract used by journey orchestration.

## 1) Control model summary

Use two control layers:
1. `System-defined` (admin-locked, always enforced).
2. `User-selectable` (5 high-impact interaction preferences).

Core principle:
- Reuse sequence logic and quality gates across scenarios.
- Do not hard-code deterministic assistant phrasing.
- Let agents generate wording from context + user controls.

## 2) User-selectable controls (final 5)

| Label | Far Extreme Left | Far Extreme Right | Description | How Selected |
|---|---|---|---|---|
| Humor | Strictly professional | Hilarious | Level of playfulness in responses. | User selectable |
| Directness | Gentle and softened | Blunt and direct | How straight to the point the assistant is. | User selectable |
| Detail Depth | Brief summary | Deep step-by-step | Amount of explanation and context. | User selectable |
| Technical Level | Layman-friendly language | Expert technical language | Degree of jargon and technical depth. | User selectable |
| Directive Style | Patient coach | Just tell me what to do | How guided vs command-style responses feel. | User selectable |

### 2.1 Allowed values (enums)

```json
{
  "humor_level": ["none", "light", "playful"],
  "directness": ["gentle", "balanced", "blunt"],
  "explanation_depth": ["brief", "moderate", "deep"],
  "technical_level": ["layman_friendly", "balanced", "expert"],
  "directive_style": ["patient_coach", "balanced", "tell_me_what_to_do"]
}
```

## 3) System-defined controls (admin policy)

These are not user-editable in UI:
1. `accuracy_strictness = strict`
2. `language_safety = family_safe`
3. `question_style = guided`
4. `confirmation_style = every_task` (Stage 1)
5. schema validity / output contract enforcement

## 4) Admin default baseline

```json
{
  "tone": "practical",
  "humor_level": "light",
  "directness": "balanced",
  "explanation_depth": "moderate",
  "technical_level": "layman_friendly",
  "directive_style": "patient_coach",
  "accuracy_strictness": "strict",
  "question_style": "guided",
  "confirmation_style": "every_task",
  "inspiration_preference": "mixed",
  "accessibility_mode": "standard"
}
```

## 5) User-facing mode presets (5)

These simplify control for non-technical users.

```json
{
  "practical": {
    "humor_level": "light",
    "directness": "balanced",
    "explanation_depth": "moderate",
    "technical_level": "layman_friendly",
    "directive_style": "patient_coach"
  },
  "quick_outcome": {
    "humor_level": "none",
    "directness": "blunt",
    "explanation_depth": "brief",
    "technical_level": "layman_friendly",
    "directive_style": "tell_me_what_to_do"
  },
  "high_clarity": {
    "humor_level": "none",
    "directness": "balanced",
    "explanation_depth": "deep",
    "technical_level": "layman_friendly",
    "directive_style": "patient_coach"
  },
  "humorous": {
    "humor_level": "playful",
    "directness": "balanced",
    "explanation_depth": "moderate",
    "technical_level": "layman_friendly",
    "directive_style": "patient_coach"
  },
  "tech_savvy": {
    "humor_level": "none",
    "directness": "blunt",
    "explanation_depth": "deep",
    "technical_level": "expert",
    "directive_style": "tell_me_what_to_do"
  }
}
```

Optional additional user control:
- `audience_level`: `layman` | `tech_savvy`

## 6) Payload contract (runtime)

Minimum (recommended for most turns):

```json
{
  "interaction_mode": "practical",
  "audience_level": "layman"
}
```

With advanced overrides:

```json
{
  "interaction_mode": "practical",
  "audience_level": "layman",
  "interaction_style_override": {
    "humor_level": "light",
    "directness": "balanced",
    "explanation_depth": "moderate",
    "technical_level": "layman_friendly",
    "directive_style": "patient_coach"
  }
}
```

## 7) Merge precedence (required)

Backend must compute effective style in this order:
1. admin default baseline,
2. selected mode preset,
3. user override (if provided),
4. enforce system-locked fields.

System-locked fields always win final merge.

## 8) UI requirements linkage

UI should provide:
1. visible 5-option mode selector,
2. optional knowledge-level toggle,
3. advanced override controls (collapsible),
4. persistence across session/refresh,
5. payload submission on every turn.

Reference docs:
- `design/prompting/journey_orchestrator_ui_requirements.md`
- `design/prompting/journey_interaction_control_model.md`

## 9) Scale boundary

User controls affect communication behavior.
They do not control source trust/freshness rules.

Source retrieval integrity remains system-defined and scalable via registry strategy.