Dark Launch Architecture Evaluation Prompt

Use this prompt when a platform team is designing or reviewing a dark launch (shadow traffic) architecture for a new service and needs a structured, pre-implementation risk assessment. The ideal user is a staff engineer, architect, or technical lead who has a concrete design proposal in hand—including a service topology diagram, a description of the traffic mirroring path, and a list of downstream dependencies. The prompt evaluates four critical dimensions: traffic mirroring mechanisms, isolation guarantees, observability design, and production safety boundaries. It is intended for use during architecture review sessions, as part of a pre-deployment risk gate, or when comparing alternative shadowing approaches before any code is written.

This prompt is not a deployment runbook, an incident response guide, or a substitute for load testing. Do not use it to evaluate a system that is already live in production without design documentation, or to assess non-functional requirements like cost optimization or team staffing. The prompt assumes the reader brings a specific design proposal; it will not generate a dark launch architecture from scratch. If you lack a service topology or cannot describe how traffic will be mirrored, start with a design spike before invoking this evaluation. The output is a structured review document with identified risks, missing safety controls, and recommended mitigations—not a pass/fail verdict.

Before running this prompt, gather the following context: the service topology (including the shadow target and any downstream services), the traffic mirroring mechanism (e.g., request duplication at the proxy, async log replay, or sidecar capture), the isolation strategy (e.g., separate database instances, read-only shadow stores, or virtualized dependencies), the observability plan (metrics, traces, and alerts that distinguish shadow from production traffic), and the safety boundaries (rate limits, circuit breakers, and kill switches). If any of these inputs are missing, the evaluation will be incomplete. After receiving the review, use the identified gaps to update your design before proceeding to implementation. For high-risk systems—especially those touching payment processing, user notifications, or stateful external APIs—always require human review of the evaluation output before approving the architecture.

This prompt template is designed for platform engineers and SREs who need a rigorous, repeatable review of a dark launch architecture before any production traffic is mirrored. It forces the reviewer to articulate the system context, traffic mirroring mechanism, isolation guarantees, and observability design in sufficient detail that a model or a peer reviewer can identify risks that are often missed during implementation. The template is structured to produce a JSON output with severity-rated findings and actionable recommendations, making it suitable for integration into a release gate or architecture review pipeline.

textCopy
Evaluate the following dark launch architecture design for production safety. Identify risks related to side-effect leakage, resource contention, and observability gaps. Provide a structured review with findings, severity ratings, and actionable recommendations.

## System Context
[SERVICE_NAME]: Name of the service being dark launched.
[ARCHITECTURE_DESCRIPTION]: A description of the service topology, including upstream callers, the mirroring point, and all downstream dependencies.

## Traffic Mirroring Design
[MIRRORING_MECHANISM]: How production traffic is duplicated and forwarded to the dark service (e.g., Envoy request mirroring, Kafka topic duplication, application-level SDK).
[MIRRORING_PERCENTAGE]: The percentage of production traffic being mirrored.
[MIRRORING_LATENCY_IMPACT]: The expected impact on production request latency.

## Isolation Guarantees
[DATA_STORE_INTERACTIONS]: List all databases, caches, queues, and object stores the dark service reads from or writes to. For each, specify whether it is a dedicated dark instance or a shared production instance.
[SIDE_EFFECT_ACTIONS]: List any external API calls, email/SMS sends, payment processing, or other side-effect-producing actions the dark service might trigger.
[RESOURCE_QUOTAS]: CPU, memory, and network limits applied to the dark service instances.

## Observability Design
[METRICS_COLLECTED]: The metrics emitted by the dark service for comparison against the production baseline.
[LOG_AGGREGATION]: How dark service logs are separated from production logs.
[ALERTING_RULES]: Any alerts configured on dark service metrics or error rates.

## Evaluation Criteria
1. Side-Effect Leakage: Can the dark service cause any real-world side effects?
2. Resource Contention: Can the dark service degrade production performance?
3. Data Isolation: Is any production data at risk of corruption from the dark path?
4. Observability Completeness: Can the team detect and diagnose failures in the dark service?
5. Abort Safety: How quickly and safely can the dark launch be terminated?

## Output Format
Return a JSON object with the following structure:
{
  "overall_risk_assessment": "low" | "medium" | "high" | "critical",
  "findings": [
    {
      "id": "string",
      "category": "side_effect_leakage" | "resource_contention" | "data_isolation" | "observability_gap" | "abort_safety",
      "severity": "low" | "medium" | "high" | "critical",
      "description": "string",
      "impact": "string",
      "recommendation": "string"
    }
  ],
  "required_actions_before_launch": ["string"],
  "monitoring_requirements": ["string"]
}

To adapt this template for your own review process, replace each bracketed placeholder with concrete details from your architecture. The quality of the output depends heavily on the specificity of the inputs—vague descriptions of [DATA_STORE_INTERACTIONS] or [SIDE_EFFECT_ACTIONS] will produce vague findings. For high-risk services that interact with payment systems, user notification channels, or production databases, require a human reviewer to verify each finding before the dark launch proceeds. The overall_risk_assessment field should gate the launch: any result of high or critical must block production traffic mirroring until the required_actions_before_launch are completed and re-reviewed.

When integrating this prompt into a CI/CD pipeline or architecture review tool, validate the output JSON against the expected schema before accepting the results. A common failure mode is the model producing findings that are too generic—if a finding does not reference a specific component from your [ARCHITECTURE_DESCRIPTION], treat it as low confidence and request a re-evaluation with more detailed inputs. For services that handle regulated data or have strict uptime requirements, pair this automated review with a manual architecture review; the prompt identifies technical risks, but it cannot assess organizational context or team readiness.

This prompt is designed to be called programmatically within a design review pipeline, not as a one-off chat interaction. Integrate it into your existing architecture review process by calling the LLM API with structured output mode enabled—either JSON mode or function calling with a strict schema that matches the expected output contract. The prompt instructs the model to return a list of findings, each with a severity level (critical, high, medium, low), a category, a description, and a recommendation. Enforcing this schema at the API level prevents parsing errors downstream and ensures every finding is machine-readable for automated routing.

After receiving the model response, validate the returned JSON against your output schema before presenting results to the user or taking automated action. Check that all required fields are present, severity values match the allowed enum, and no malformed or truncated objects exist. If validation fails, implement a retry loop with the same prompt and schema, up to a maximum of two retries. If the model consistently fails to produce valid output, log the failure and escalate to a human reviewer rather than silently dropping findings. For findings with a critical severity, flag the review for mandatory human approval before the dark launch can proceed. This means routing the finding to a designated reviewer queue, blocking the deployment pipeline, and requiring explicit sign-off. Do not treat the model's risk assessment as the sole approval signal for high-risk services such as payments, healthcare, or authentication systems—pair this prompt with a formal Failure Mode and Effects Analysis (FMEA) process.

Log the full prompt, raw model response, validated output, and any retry attempts for audit and debugging purposes. Include a unique review ID, timestamp, model version, and the architecture description hash so you can trace every evaluation back to the exact inputs that produced it. This prompt is not a one-shot gate; re-run it whenever the architecture description, traffic mirroring mechanism, or downstream dependencies change. For teams using retrieval-augmented generation (RAG), you can extend the harness by injecting relevant incident postmortems, previous dark launch reviews, or service-level objective (SLO) definitions into the [CONTEXT] placeholder before calling the model. Choose a model with strong reasoning capabilities and low hallucination rates for this task—GPT-4o, Claude 3.5 Sonnet, or equivalent. Avoid smaller or faster models that may miss subtle side-effect leakage or resource contention risks. The harness should treat this prompt as a structured evidence generator, not a decision maker, and always pair its output with human judgment for critical safety boundaries.