Runtime Prompt Governance

Purpose

This document defines how prompts should be governed in the future runtime architecture.

Prompts are a critical part of system behavior, but they are not the entire behavior model. They must operate within domain, workflow, policy, and approval constraints defined elsewhere in the docs hub.

Related docs:

Core principle

Runtime prompts should be treated as governed contracts that shape AI behavior inside approved system boundaries.

Prompts can define:

tone and behavior
task framing
output format
tool-use guidance
grounding and retrieval instructions
fallback and refusal behavior

Prompts must not independently define:

permission models
tenant access
approval requirements
compliance exceptions
undocumented business rules

Those belong to canonical domain, workflow, security, and policy documentation.

Prompt layers

Recommended prompt stack:

1) Platform prompt

Defines global runtime invariants.

Examples:

safety posture
tenant isolation reminders
response quality expectations
behavior consistency rules

2) App prompt

Defines behavior for a product surface or app.

Examples:

Chatti Live behavior
Comment Responder behavior
assistant-side guidance

3) Workflow prompt

Defines task-specific orchestration framing.

Examples:

planning behavior
execution guidance
validation criteria

4) Workspace or KB-derived prompt context

Defines local business truth and policy context.

Examples:

brand voice
compliance language
approved facts
workspace-specific rules

Prompt governance rules

Prompts must be versioned.
Prompt changes must be attributable and reviewable.
Prompts must not be the only place where critical business policy exists.
Sensitive actions must still require policy and approval checks outside the prompt.
Runtime prompt updates should generally enter the system as proposals, not silent live edits.

Boundary between prompts and platform behavior

Prompt-driven behavior is only one part of runtime behavior.

Full runtime behavior is shaped by:

prompts
policy rules
workflow contracts
tool and API boundaries
tenant and permission constraints
runtime state and memory

Recommended interpretation:

prompts influence behavior
policies constrain behavior
orchestration decides behavior
execution performs behavior

Documentation home

Use docs/prompts/** for:

product/runtime prompt contracts
prompt inputs and outputs
grounding expectations
refusal and fallback behavior
prompt versioning strategy

Do not use docs/ai-governance/** for runtime product prompts unless the content is explicitly about engineering or delivery-agent behavior.

Learning and prompt evolution

Prompt evolution should follow this model:

Observe runtime outcomes
Detect prompt-related friction or failure
Generate a structured revision proposal
Review and approve the change
Publish a new prompt version

This preserves:

trust
auditability
rollback ability
explanation of why behavior changed

MVP-compatible path

In the current platform stage:

define prompt contracts in docs before treating them as runtime-governing assets
keep prompts tightly tied to documented workflows and domain rules
use recommendations and proposal flow before introducing adaptive self-tuning prompts

Longer term:

prompts may be assembled dynamically from approved contracts
prompt version resolution may become runtime-driven
adaptive tuning may be allowed within explicit governance bounds