Frozen Instruction Compatibility Test Prompt

This prompt is a diagnostic instrument, not an authoring tool. You use it when a system prompt has been locked—no further edits allowed—and you need to verify that the surrounding ecosystem still honors the contract the frozen prompt expects. The primary job-to-be-done is producing a compatibility matrix that surfaces what will work, what will break, and what implicit dependencies have shifted since the prompt was frozen. The ideal user is an integration engineer, release manager, or platform engineer running pre-deployment checks after a tool schema change, an API version bump, or a downstream system migration. You should have the frozen system prompt text, the current tool definitions (function schemas, API specs, MCP server manifests), and any relevant integration surface documentation (data contracts, expected response shapes, environment variables) ready before invoking this prompt.

Do not use this prompt when the system prompt is still under active iteration. If you are still editing instructions, run a freeze readiness assessment or a pre-freeze regression suite instead. Do not use it to author new system instructions or to debug a single malformed output—this prompt operates at the integration contract level, not the individual response level. It is also not a replacement for end-to-end integration tests; it identifies contract mismatches and implicit dependency risks, but it cannot execute live API calls or observe runtime behavior. The prompt assumes the frozen instructions are correct by definition and the question is whether the environment still supports them. If the environment has changed in ways that make the frozen prompt's assumptions invalid, the output will flag those gaps with breakage warnings and adaptation notes.

Before running this prompt, gather the frozen system prompt, the current tool manifest, and any API or data contract documentation that the prompt references implicitly or explicitly. The prompt works best when you provide structured tool definitions (JSON schema for functions, OpenAPI snippets, or MCP tool descriptors) rather than prose descriptions. After receiving the compatibility matrix, review every BREAK finding with the team that owns the changed component. For WARN items, decide whether the adaptation note is acceptable or whether a post-freeze exception request is required. If the matrix surfaces implicit dependencies you were not tracking—such as the frozen prompt assuming a specific field name that has since been renamed—add those dependencies to your monitoring and alerting rules. In high-risk environments, require a second reviewer to sign off on the compatibility matrix before proceeding with deployment.

This template is designed to be pasted directly into your AI harness. It instructs the model to act as an integration engineer, analyzing a frozen system prompt for compatibility with a provided set of tool definitions, API contracts, and environment context. The primary output is a structured compatibility matrix that flags breakages, warns of implicit dependencies, and suggests adaptation notes. Before using this, ensure you have your frozen system prompt, a complete list of tool schemas, and any relevant API documentation ready to insert into the placeholders.

codeCopy
You are an integration engineer responsible for verifying the compatibility of a frozen system prompt. Your task is to analyze the provided [FROZEN_SYSTEM_PROMPT] against the [TOOL_DEFINITIONS], [API_CONTRACTS], and [ENVIRONMENT_CONTEXT].

Generate a compatibility matrix in valid JSON format using the following [OUTPUT_SCHEMA]:
{
  "compatibility_matrix": [
    {
      "component": "string (name of the tool, API endpoint, or environment variable)",
      "status": "string (one of: 'COMPATIBLE', 'WARNING', 'BREAKING')",
      "dependency_type": "string (e.g., 'explicit_tool_call', 'implicit_behavioral_reference', 'data_format_expectation')",
      "evidence_from_prompt": "string (exact quote or clear description of the instruction causing the dependency)",
      "breakage_description": "string (if status is WARNING or BREAKING, describe the failure mode. Otherwise, null.)",
      "adaptation_notes": "string (recommended action to resolve the issue or confirm compatibility)"
    }
  ],
  "overall_risk_assessment": "string (one of: 'CLEAR_TO_DEPLOY', 'DEPLOY_WITH_MONITORING', 'BLOCKED')",
  "unreferenced_tools": ["string (list of tools from TOOL_DEFINITIONS that have no explicit or implicit reference in the FROZEN_SYSTEM_PROMPT)"]
}

[CONSTRAINTS]
- Base your analysis strictly on the provided inputs. Do not infer dependencies that are not supported by evidence.
- An implicit dependency exists if the system prompt's instructions assume a capability, data format, or behavior that is only provided by a specific tool or API contract.
- A BREAKING status means the system prompt will cause a runtime error or a critical behavioral failure.
- A WARNING status means the system prompt may cause degraded performance, unexpected behavior, or relies on a deprecated feature.
- If the [RISK_LEVEL] is 'HIGH', you must also include a 'human_review_required' boolean field in each matrix entry, set to true for any WARNING or BREAKING status.

To adapt this template, replace the placeholders with your specific assets. [FROZEN_SYSTEM_PROMPT] should contain the exact text of your locked system instructions. [TOOL_DEFINITIONS] should be a JSON array of function schemas your model can call. [API_CONTRACTS] can include OpenAPI specs or plain-text descriptions of expected request/response shapes. [ENVIRONMENT_CONTEXT] might specify the model ID, deployment region, or feature flags. For high-stakes deployments, set [RISK_LEVEL] to 'HIGH' to enforce a human review flag on every warning and breakage. After running the prompt, always validate the output JSON against the [OUTPUT_SCHEMA] before integrating the results into your CI/CD pipeline. A common failure mode is the model hallucinating dependencies for tools that are not actually referenced; cross-reference the unreferenced_tools list with your own inventory as a sanity check.

The Frozen Instruction Compatibility Test Prompt is designed to run as an automated gate in your CI/CD pipeline, not as a one-off manual check. The prompt takes a frozen system instruction block and a set of tool definitions, API contracts, or downstream system schemas as input, and it produces a structured compatibility matrix. To integrate this into a release workflow, you should wrap the prompt in a harness that validates the output schema, logs the matrix for audit, and blocks the release if any BREAKING incompatibilities are detected. The harness must treat the frozen instructions as immutable and the tool/schema definitions as the variable under test.

A concrete implementation should start by loading the frozen system prompt from a versioned artifact store and the current tool definitions from your service registry or OpenAPI spec. Construct the prompt with [FROZEN_INSTRUCTIONS] and [CURRENT_TOOL_DEFINITIONS] as the two primary inputs. After the model returns the compatibility matrix, run a strict JSON schema validator against the expected output shape—each entry must include tool_name, compatibility_status (one of COMPATIBLE, WARNING, BREAKING), breakage_description, and adaptation_notes. If any entry has compatibility_status: BREAKING, the harness should fail the pipeline step and surface the breakage descriptions to the release engineer. For high-reliability systems, run the prompt three times and require consensus on BREAKING classifications before blocking the release, reducing false positives from model non-determinism.

Log every compatibility matrix to your prompt observability system with the frozen instruction version hash, tool definition version, model identifier, and timestamp. This creates an audit trail for debugging production incidents where a tool call fails silently because an implicit dependency was missed. Avoid wiring this prompt directly into a deployment trigger without human review of WARNING entries—these often surface assumptions about parameter formats or error handling that require engineering judgment. The harness should also check for implicit dependencies the model flags, such as the frozen instructions referencing a tool by a deprecated name or assuming a field exists that was removed in the current schema. If your system uses dynamic tool discovery, run this compatibility test whenever the tool registry changes, not just when the system prompt is modified.