Dynamic Branch Decision Logging Prompt

This playbook is for engineering teams whose prompt assembly pipeline contains conditional logic: if-else blocks, switch statements, feature flags, or risk-based routing that selects different system instructions, few-shot examples, or tool schemas at runtime. When a model produces an unexpected output, the first question is always 'which prompt did it actually receive?' This prompt answers that question by generating a structured, machine-readable log of the branch decision, the condition that triggered it, and the resulting prompt structure. Use this when you need to audit runtime assembly decisions, debug branch mispredictions, or prove to auditors that the correct policy path was followed for a given request.

The ideal user is an AI operations engineer, platform developer, or technical lead responsible for a production prompt assembly system where the final prompt is not static but constructed dynamically from multiple sources. You should have access to the assembly logic itself—the code or configuration that decides which instructions, examples, or tool schemas to inject. The prompt requires you to supply the assembly decision tree, the runtime conditions evaluated, and the branch that was taken. Without this context, the prompt cannot produce a useful log. Do not use this prompt for static, single-template prompts where no branching occurs; a simple version stamp or hash fingerprint is sufficient for those cases.

This prompt is not a replacement for application-level logging or distributed tracing. It is a supplement that produces a human-and-machine-readable artifact specifically about the branch decision. It does not instrument your assembly code, capture model outputs, or measure latency. Pair it with your existing observability stack—OpenTelemetry spans, structured logs, and request snapshots—to create a complete debugging picture. For high-risk domains such as healthcare, legal, or finance, the log output should be persisted alongside the model request and response as part of your audit trail, and a human reviewer should verify that the logged branch matches the expected policy path before the system is promoted to production.

Before implementing, confirm that your assembly pipeline can expose the decision metadata this prompt requires: the condition expression evaluated, the set of possible branches, the selected branch identifier, and the resulting prompt structure or a diff from a base template. If your assembly logic is opaque or cannot surface this information, invest in instrumentation first. Once the log is generated, validate it programmatically: check that the logged branch exists in the decision tree, that the condition value matches the expected type, and that the resulting prompt structure is non-empty and parseable. These validation checks should run as preflight guards before the log is written to your audit store.

This prompt is designed to be called as a secondary, lightweight model request that runs after the main prompt is assembled but before it is sent, or as a structured logging step that runs in parallel. The model receives the condition state and the assembled prompt structure and returns a structured branch decision log. Use it to capture why a particular prompt variant was built, which conditions were evaluated, and what the resulting structure looks like—without relying on scattered log lines or reconstructing decisions from raw code paths.

textCopy
You are a prompt assembly auditor. Your only job is to produce a structured branch decision log.

You will receive:
- A set of evaluated conditions and their boolean results.
- The final assembled prompt structure, including section names and ordering.

Do not evaluate the prompt content. Do not suggest improvements. Only log the decision path.

## INPUT

### Evaluated Conditions
[CONDITIONS]

### Assembled Prompt Structure
[ASSEMBLED_PROMPT_STRUCTURE]

## OUTPUT SCHEMA
Return a JSON object with the following fields:
- `trace_id`: string (from [TRACE_ID])
- `assembly_version`: string (from [ASSEMBLY_VERSION])
- `timestamp`: ISO 8601 string (from [TIMESTAMP])
- `branches_taken`: array of objects, each with:
  - `condition_name`: string
  - `condition_expression`: string
  - `evaluated_to`: boolean
  - `branch_label`: string (the human-readable name of the branch selected)
  - `sections_added`: array of section names injected as a result
  - `sections_skipped`: array of section names that would have been added if the condition were false
- `final_section_order`: array of section names in the order they appear in the assembled prompt
- `unreachable_branches`: array of condition names that were defined but never evaluated (if any)
- `ambiguity_flags`: array of strings describing any conditions that were redundant, contradictory, or had overlapping triggers (empty array if none)

## CONSTRAINTS
- Output ONLY the JSON object. No markdown fences, no commentary.
- If [CONDITIONS] is empty, return an empty `branches_taken` array and note the absence in `ambiguity_flags`.
- If [ASSEMBLED_PROMPT_STRUCTURE] is empty, set `final_section_order` to an empty array and flag it.
- Do not hallucinate conditions that are not present in [CONDITIONS].
- Preserve the exact section names as they appear in [ASSEMBLED_PROMPT_STRUCTURE].

Adaptation notes: Replace [CONDITIONS] with a serialized representation of your evaluated feature flags, user attributes, risk scores, or A/B test assignments—anything that drove a branching decision. [ASSEMBLED_PROMPT_STRUCTURE] should contain the ordered list of section names (and optionally their source identifiers) that ended up in the final prompt. [TRACE_ID], [ASSEMBLY_VERSION], and [TIMESTAMP] should be injected by your assembly harness before calling this prompt. If your assembly logic uses nested branches, flatten them into a single conditions list with clear labels so the model can reconstruct the decision tree without ambiguity.

Next steps: After receiving the log, validate that branches_taken matches your expected decision path for the given inputs. Store the log alongside your request trace for debugging. If ambiguity_flags is non-empty, review your branching logic for overlapping conditions that could produce non-deterministic assembly. For high-risk workflows where branch selection affects safety policies or compliance, route ambiguous logs to human review before the assembled prompt is sent to the primary model.

The Dynamic Branch Decision Logging Prompt is not a standalone prompt you call directly. It is a logging shim that wraps your existing prompt assembly pipeline. When your application evaluates a runtime condition and selects a branch, you inject this prompt's output into your trace metadata before the final model request is dispatched. The goal is to produce a machine-parseable decision record that answers three questions: which branch was chosen, what condition triggered it, and what was the resulting prompt structure.

Wire this into your assembly harness by calling the logging prompt immediately after branch selection and before the final prompt is rendered. Pass the branch condition expression, the evaluated result, the selected branch identifier, and a summary of the prompt structure that branch will produce. The model returns a structured JSON log entry. Validate this output against a schema that requires branch_id, condition_evaluated, timestamp, and prompt_structure_summary fields. If validation fails, retry once with a stricter schema constraint. If it fails again, emit a malformed-log alert and fall back to a programmatically generated log entry with an assembly_error flag set to true. Store the validated log entry alongside your request trace ID, not inside the user-facing prompt payload.

For production observability, attach the log entry to your existing trace span as a structured attribute. Do not embed it in the model request itself—this would contaminate the prompt the user's task relies on. Instead, write it to your observability backend (OpenTelemetry span event, structured log line, or dedicated audit table) keyed by trace_id and assembly_version. When an operator investigates a bad output, they query by trace ID and immediately see which branch fired and why. For high-risk workflows where branch selection affects safety or compliance, add a human-review gate: if the branch condition involves a risk score above a configured threshold, pause the pipeline and require approval before the logging prompt even runs. The logging prompt itself should never be the decision-maker; it only records decisions your application code already made.

Model choice matters less here than output determinism. Use a fast, cheap model with low temperature (0 or 0.1) and strict JSON mode. The prompt's job is structured transcription, not reasoning. If your assembly pipeline already has access to the branch condition and result as structured data, consider whether you even need a model for this—a deterministic JSON serializer is faster, cheaper, and cannot hallucinate the branch ID. Reserve the model-based logging prompt for cases where the condition logic is complex natural-language policy (e.g., 'does this user request violate the content policy?') and you want the model to explain its interpretation in the log. In all other cases, generate the log entry programmatically and skip the inference call.