# Prompt composition

Status: target responsibilities agreed; unified resolution remains planned.
The existing demo's launch and verification contracts remain in force.

Mosaic composes instructions from sources with distinct ownership and lifetimes.
The composition contract must be explicit and testable across supported harnesses.

| Source | Responsibility |
|---|---|
| CONSTITUTION | Shared boundaries, principles and authority |
| STANDARDS | Quality expectations and evidence requirements |
| Agent SOUL | Voice, temperament and interaction style |
| Repository AGENTS | Applicable repository procedures |
| Scoped USER context | Relevant, authorized user preferences |
| Runtime context | Actual identity, workspace, tools, skills and session behavior |
| Assignment records | Authorized work, current state and acceptance criteria |

## Resolution rules

Select one canonical SOUL belonging to the requested agent. A project folder,
template, root SOUL, or shared boilerplate must not replace it implicitly.
System bootstrap creates the initial agent's instance from a reviewed template;
later agent bootstrap follows the same ownership rule. Templates are not runtime
personality layers. Updating them must not silently overwrite existing instances.

Load repository procedures only where applicable to the execution's scope.
Do not automatically give a worker the conductor's context or privileges.
User preferences, agent style, and retrieved content cannot widen permission.
Heading order in a concatenated Markdown file is not security enforcement.

## Execution lifetime and provenance

Resolve current approved input revisions on Resume and Fresh. Record their
identity with the execution, and preserve the exact injected snapshot where
required. Keep credentials out of ordinary prompt records. Permission enforcement
belongs to the runtime and policy mechanisms, not the personality file.

A harness may contribute its own instructions. Distinguish Mosaic's assembled
inputs from a verified model-bound request; a local prompt snapshot alone cannot
establish what an external harness added.

## Current implementation boundary

The container replaces Pi's base prompt with generated context; native development
appends context to Pi's coding prompt. They differ in source selection and policy
enforcement. Reconcile those paths under ACT-1 after demo validation. Do not remove
POC startup-marker behavior before replacement verification fixtures are tested.

See [context inspection](context.md), [runtime ownership](agent-runtimes.md), and
[the migration plan](../plans/2026-09-07_agent-context-templates-and-migration.md).