Transparency Statement Adaptation Prompt

This playbook is for AI product teams that must maintain consistent transparency disclosures—covering capability limitations, data handling practices, and AI identity markers—across multiple model providers. The core job is to take a single source-of-truth transparency statement and adapt it into structurally sound, provider-native instructions that survive real deployment. The ideal reader is an engineering lead or AI platform architect who owns the system prompt layer and is responsible for ensuring that every user-facing model instance discloses its nature, boundaries, and data practices correctly, regardless of which provider serves the response.

Use this prompt when you are deploying the same product experience on more than one model family (for example, OpenAI and Anthropic, or a cloud provider and an open-weight local model) and you need each instance to produce equivalent transparency disclosures. The prompt is designed to handle structural adaptation: it maps your disclosure requirements into the instruction format, delimiter conventions, and behavioral tendencies of each target model. It also produces a completeness checklist so you can verify that no required disclosure element was dropped during adaptation. Do not use this prompt for writing the original transparency policy from scratch—it assumes you already have an approved source statement. Do not use it for one-off consumer chatbot disclaimers; it is built for product teams that treat transparency as a compliance and trust surface, not a casual add-on.

Before running this prompt, gather your canonical transparency statement, the target model's system prompt conventions, and any deployment-specific constraints such as locale, audience, or regulatory requirements. After adaptation, you must run the output through the disclosure completeness checks included in the prompt's output schema. For regulated or high-risk domains, add a human review step before the adapted statement reaches production. The next section provides the copy-ready template you will use to perform this adaptation.

This prompt template is designed to be copied directly into your prompt library or orchestration layer. It accepts a source transparency statement, a target model identifier, and contextual deployment information, then produces an adapted statement that preserves disclosure completeness while respecting the instruction format, tone sensitivity, and parsing behavior of the target model. Every placeholder is enclosed in square brackets and must be replaced before execution. Do not leave any placeholder unresolved in production.

textCopy
You are a transparency policy adaptation engine. Your task is to rewrite a source transparency statement so that it is structurally compatible with [TARGET_MODEL] while preserving all required disclosures.

## SOURCE TRANSPARENCY STATEMENT
[SOURCE_STATEMENT]

## TARGET MODEL
Model family: [TARGET_MODEL]
Model version: [TARGET_MODEL_VERSION]
Deployment environment: [DEPLOYMENT_ENVIRONMENT]

## REQUIRED DISCLOSURES
These disclosures must appear in the output. Do not omit, soften, or reorder them:
[DISCLOSURE_LIST]

## ADAPTATION RULES
- Preserve the factual content of each disclosure exactly.
- Adjust tone, formatting, and placement to match [TARGET_MODEL]'s instruction-following conventions.
- If [TARGET_MODEL] is known to ignore trailing instructions, place critical disclosures early.
- If [TARGET_MODEL] is known to over-prioritize safety language, avoid phrasing that could trigger unintended refusal.
- Maintain the disclosure order specified in [DISCLOSURE_LIST] unless structural adaptation requires reordering; if reordering is necessary, note the change in an adaptation log.

## OUTPUT FORMAT
Return a JSON object with the following schema:
{
  "adapted_statement": "<the full adapted transparency statement as a single string>",
  "disclosure_coverage": {
    "total_required": <integer>,
    "included": <integer>,
    "missing": ["<list of missing disclosure IDs or descriptions>"]
  },
  "adaptation_notes": ["<list of changes made, including reordering, tone shifts, or structural modifications>"]
}

## CONSTRAINTS
- Do not invent new disclosures.
- Do not remove or weaken any required disclosure.
- If a disclosure cannot be adapted without loss, flag it in `missing` and explain why in `adaptation_notes`.
- Output only valid JSON. No markdown fences, no commentary outside the JSON object.

To adapt this template for your own use, replace each square-bracket placeholder with concrete values. [SOURCE_STATEMENT] should contain the full text of your existing transparency statement. [TARGET_MODEL] and [TARGET_MODEL_VERSION] identify the model you are porting to, such as claude-sonnet-4-20250514 or gpt-4o. [DEPLOYMENT_ENVIRONMENT] describes where the model runs, such as production-chat-api-us-east or staging-eu-tenant-isolated. [DISCLOSURE_LIST] is the most critical field: provide an explicit, enumerated list of disclosure IDs and their required text. For example: 1. AI_IDENTITY: "I am an AI assistant developed by Acme Corp." 2. CAPABILITY_LIMITS: "I cannot access real-time data unless connected to a search tool." 3. DATA_HANDLING: "Conversations may be logged for quality improvement." The output schema includes a coverage check, which you should validate programmatically after the model responds. If missing is non-empty, escalate for human review before deploying the adapted statement.

The Transparency Statement Adaptation Prompt is not a one-shot generation tool; it is a policy enforcement step in a governed content pipeline. The prompt expects a structured [SOURCE_POLICY] describing required disclosures (AI identity, capability limitations, data handling, human review flags) and a [TARGET_MODEL] identifier. The output is a transparency statement template adapted to that model's instruction-following patterns. In production, this prompt should be called whenever a new model is onboarded, a policy is updated, or a deployment environment changes. The generated statement is then injected into the system prompt or user-facing disclosure layer of the target assistant.

Wire this prompt into a pipeline with the following stages: Input Validation checks that [SOURCE_POLICY] contains all required disclosure categories (identity, limitations, data use, human escalation) and that [TARGET_MODEL] maps to a known provider configuration. Generation calls the prompt with the validated inputs. Output Validation parses the generated transparency statement and runs a disclosure completeness check—a structured eval that verifies each required disclosure category is present, no contradictory claims exist, and the statement uses language appropriate for the target model's typical output style. Human Review Gate is mandatory for any statement that will be shown to end users in regulated domains (healthcare, finance, legal) or when the disclosure completeness check scores below a defined threshold. Logging captures the source policy version, target model, generated statement, validation scores, reviewer identity, and approval timestamp for audit evidence.

For multi-model deployments, run this prompt once per target model during onboarding, store the adapted statements in a versioned policy registry, and inject the correct statement at runtime based on the active model. Do not regenerate transparency statements per request—this introduces latency and inconsistency. Instead, treat the generated statements as configuration artifacts that are reviewed, approved, and deployed alongside model routing rules. When a source policy changes, re-run the prompt for all active target models, diff the outputs against the previous versions, and route changes through the same validation and review gates. Avoid deploying transparency statements that have not passed the disclosure completeness check, as missing disclosures create compliance gaps that are difficult to detect after deployment.