Prompt Chaining Implementation: Optimizing High Accuracy Sports Prediction Models

About This Guide

Purpose: This document provides a comprehensive overview of the migration from a single-prompt prediction workflow to a dynamic, chained multi-step prompt architecture for the client’s AI-powered prediction and recommendation system. It details the full design, system updates, prompt chaining logic, and analyst guidance for experimentation within the platform.

Target Audience: Data Analysts and Product Managers who analyze prompt outputs, monitor prediction flows, or modify prompt templates. No programming experience is required to follow the content.

Scope: Explains architectural changes, automation improvements, UI and database updates, prompt structure definitions, and examples of chained executions. This guide also introduces observability and placeholder enhancements.

 

1.0 Background & Objectives

The prediction system originally relied on a single prompt that performed prediction, validation, reference data comparison, and selection in one step. This often led to errors such as invented values or mismatched outputs when the prompt tried to do everything at once.

Objective: The new architecture separates these concerns into a chained prompt system, introducing automation, modularity, and better analyst control. Each chain step focuses on one layer of logic: prediction, validation, and refinement.

1.1 Legacy (Single-Prompt) Overview

• One static prompt executed all logic, including outcome prediction, reference data comparison, and recommendation generation.
• Analysts had no visibility into intermediate reasoning stages.
• Adjustments required complete rewriting of the main prompt.

1.2 Problem Statements Observed

• Fabricated values / Wrong numbers: The model sometimes produced threshold values that didn’t match the provided reference data from external sources.
• Low traceability/observability: When outputs were off, it was difficult to isolate whether the error came from reasoning, formatting, or reference-data handling.
• Limited Flexibility: Adjusting the narrative or logic without breaking other parts was error-prone.

 

2.0 New Architecture – Prompt Chaining Overview

The prompt chaining architecture divides the reasoning process into independent, sequential steps:

• Parent Prompt (Generation): Produces predicted outcome, aggregate metrics, sub-category breakdowns, narrative, risk level, key factors, and recommendations using the exact reference numbers when provided as context.
• Step 1 (Quality Check Chain): (Correction): Receives the current reference data and the Parent output. It verifies and, if needed, corrects only the recommendation values to match exact reference numbers, preserving all other fields.
• Step 2 (Final Polish Chain): It improves further narrative and calibrates confidence levels if there is anything that needs to be corrected against desired output format.

Encouragement: Analysts can modify the Parent (to influence reasoning and qualitative output) or the Step 1 (Quality Check Chain) (to tighten rule enforcement) and Step 2 (Final Polish Chain) to add any last check to need to be checked apart from the validation, independently in the live platform, observing immediate differences in outputs.

2.1 Execution Flow Summary (Parent → Step 1 → Step 2)

• Parent Prompt generates the complete prediction response.
• Step 1: It ingests (a) the current reference data and (b) the Parent output, then corrects only the recommendations[].value fields to ensure exact reference numbers are used.
• Step 2: It refines reasoning and presentation.
• Final Output preserves Parent’s predictions, metrics, reasoning, confidence, and risk – with only the recommendation values normalized if necessary.

Each step receives the previous step’s output as input, ensuring clean data flow.

2.2 Benefits of Chaining vs. Single Prompt (Plain-Language Rationale)

• Fewer mistakes with reference numbers: A dedicated validation step catches and fixes value mismatches.
• Easier debugging: If results look off, each stage’s output can be inspected individually.
• Observability: Easier to trace and observe what output generated by each step and what was input to that with help of tracing tools.
• Modular tuning: Adjust narrative or key factors in Parent without touching validation logic (and vice versa).
• Scalability: Future steps (e.g., consistency checker, formatting auditor, source-specific adapters) can be added without refactoring the entire system.

3.0 System Changes

In the earlier architecture, users were only able to create and manage a single prompt, which contained its three fields – System Prompt, User Prompt, and Response Format. This limited flexibility, as it couldn’t represent multiple reasoning stages within the interface.

With the new update, when users go to create a new prompt in the system, the interface now provides a radio button selection to choose between:

• Single Prompt
• Chained Prompt

Depending on the selection:

• If Single Prompt is chosen → Only three fields appear (System Prompt, User Prompt, Response Format), identical to the legacy setup.
• If Chained Prompt is selected → The interface expands to show one Parent Prompt and three Child Chains (Step 1, Step 2, Step 3). Each prompt block (Parent and every Step) includes its own three fields (System, User, Response Format).

This enhancement allows analysts to explicitly configure and edit each step independently, encouraging experimentation and structured reasoning chains.

• Parent Prompt section with three fields: System Prompt, User Prompt, Response Format.
• Child Steps: UI displays Step 1, Step 2, Step 3 (only Step 1 is currently active). Each step mirrors the same three-field structure.
• Configuration: Analysts can select which prompts are active, edit text in-place, and save versions.

3.1 UI Changes (Prompt Editor & Multi-Step Layout)

• Parent Prompt section with three fields: System Prompt, User Prompt, Response Format.
• Child Steps: UI displays Step 1, Step 2, Step 3 (only Step 1 is currently active). Each step mirrors the same three-field structure.
• Configuration: Analysts can select which prompts are active, edit text in-place, and save versions.

The interface displays a prompt editor with the following elements:

• Header: “Multi-Step Chain Prompts”
• Description: “How it works: Each step in the chain receives the output from the previous step and can refine, validate, or enhance it.”
• Two-column layout explaining Step 1 (Parent) vs Step 2+ (Children):
  • Step 1 (Parent): Makes the initial prediction, has access to all input data placeholders, example use: “Generate raw prediction”
  • Step 2+ (Children): Receives output from previous step, can validate/refine/adjust, example use: “Check reference numbers, polish reasoning”
• Warning banner (highlighted): “Important: Child steps should preserve ALL fields from previous output and only modify what needs changing.”
• Available Placeholders in Child Steps section listing: {current_prediction}, {step_1_output}, {step_2_output}, {input_data}
• Parent Prompt (Step 1) section with “Available Placeholders” button
• Placeholder categories displayed: Entity Info, Reference Data, Performance Metrics, Context Data, Analysis Fields, Nested Calculations

Database Changes (Prompt Storage)

• Entities: prompt_parent, prompt_step1, prompt_step2, prompt_step3.
• Fields: id, name, type (parent/child), content, version, created_at, updated_at, active_flag, order.
• Linkage: Steps are linked to a parent chain id; only Parent and Step 1 are enabled by default.

3.2 Code Changes (Multi-Step Orchestration)

• If Single Prompt is active, only that prompt executes end-to-end.
• If Chained Prompt is active, the system automatically detects all defined steps and executes them in order. Output from one step becomes the input to the next.
• The execution flow is flexible – users can now add or remove steps dynamically without changing code.
• Schema checks: Ensure JSON keys/shape remain intact between steps.

3.3 Placeholders Addition

The prompt editor now supports contextual placeholders (e.g., {entity_a}, {threshold_value}, {context_factor}) in any section of any prompt. This lets analysts insert contextual references directly to enrich outputs.

The Chained Prompt V1 now includes Parent + Step 1 + Step 2. It is fully dynamic and auto-executes all steps defined in the chain configuration.

Note: You can also see these placeholders while editing a prompt in the “prompt” where you are also given some tips to consider while editing any prompt.

Below is quick detail about the existing placeholders that analysts can use in the prompt writing to provide more accurate context for prediction.

Entity Info

• {entity_a} – The full name of the first entity being analyzed; used to reference it in reasoning or JSON keys.
• {entity_b} – The full name of the second entity; identifies the comparison target in analysis or output.
• {entity_a_abbrev} – Official abbreviation or short code of the first entity (e.g., “ENT-A”).
• {entity_b_abbrev} – Official abbreviation of the second entity (e.g., “ENT-B”).
• {entity_a_category} – The category or classification to which the first entity belongs.
• {entity_b_category} – The category or classification of the second entity.

Reference Data

• {threshold_primary} – The primary threshold value from the external data source (e.g., “-7.5”).
• {threshold_secondary} – The secondary threshold (aggregate) value (e.g., “45.5”).
• {entity_a_indicator} – The probability/confidence indicator for entity A (e.g., “+250”).
• {entity_b_indicator} – The probability/confidence indicator for entity B (e.g., “-300”).

Performance Metrics

• {entity_a_metric_1} – Aggregated primary performance rating for entity A.
• {entity_a_metric_2} – Aggregated secondary performance rating for entity A.
• {entity_b_metric_1} – Aggregated primary performance rating for entity B.
• {entity_b_metric_2} – Aggregated secondary performance rating for entity B.
• {entity_a_key_factors} – Key contributing factors for entity A, summarized by category or impact.
• {entity_b_key_factors} – Key contributing factors for entity B, highlighting those influencing outcomes.

Context Data

• {time_period}, {cycle} – Identifies the specific time period and cycle for the analysis (e.g., “Period 5, Cycle 2024”).
• {analysis_date} – Official analysis date, typically in ISO or readable format.
• {environmental_factor} – Relevant environmental or contextual factor, useful for situational reasoning.

Analysis

• {comparison_calc[entity_a_vs_entity_b]} – Calculated effectiveness of entity A versus entity B’s attributes.
• {comparison_calc[entity_b_vs_entity_a]} – Comparison efficiency of entity B versus entity A’s attributes.
• {outcome_nature_predicted} – Describes expected outcome nature (e.g., “Above Threshold – High Activity” or “Below Threshold – Low Activity”).
• {dominant_factor} – Based on the comparison of metrics to determine which factor is dominant irrespective of entity.
• {Analysis} – Free-text analytical summary containing whether the outcome will be above or below threshold and which entity has a dominant factor over the other.

3.4 Observability (Tracing Integration)

We integrated a tracing platform for comprehensive prompt observability and traceability. This integration records every execution step, capturing inputs, outputs, timing, prompt version, and metadata. Analysts can:

• View detailed execution logs of each chain step.
• Compare input and output data.
• Track latency, token usage, and consistency.
• Audit historical runs and analyze changes over time.

This observability layer provides a powerful debugging and performance monitoring tool, ensuring transparency across the entire prediction workflow.

 

4.0 Prompt Structure & Design

Field Definitions (System / User / Response Format)

Each prompt has three fields:

• System Prompt
  • Description: Defines the assistant’s role, constraints, and non-negotiable rules.
  • Functionality: Establishes persona, guardrails (e.g., use fixed reference values), and domain-specific behaviors.
  • Accepted Values: Free text (markdown-supported) maintained by analysts.
• User Prompt
  • Description: Task-specific instructions and checklists for the current context.
  • Functionality: Directs the assistant on what to produce and what to avoid; may include verification steps and reminders.
  • Accepted Values: Free text including placeholders for dynamic inputs.
• Response Format
  • Description: Output schema that must be returned (currently JSON).
  • Functionality: Enforces machine-readability and downstream compatibility.
  • Accepted Values: Valid JSON structure with required keys.

4.1 Parent Prompt – Design & Behavior

Purpose: Core prediction generation – predicted outcome, aggregate metrics, sub-metrics, narrative, recommendations.
Behavior: Produces a complete JSON that adheres to the Response Format and uses the exact reference numbers supplied as context.
Editing Guidance:

• Safe to adjust narrative tone, key factor emphasis, and risk articulation.
• Keep reference-number compliance reminders intact.
• Do not remove JSON schema keys.

Parent Prompt (Generalized Template)
System Prompt

JSON
You are an elite [DOMAIN] prediction and analysis expert with deep knowledge 
of advanced statistics, market dynamics, performance analytics, and situational 
factors. Your role is to provide precise, data-driven predictions following the 
exact structure and response format requested.

Always ensure:
- Predictions are realistic and based on thorough analysis of entity comparisons, 
  recent performance, environmental effects, contextual advantages, and 
  statistical ratings.
- **Step 1: Predict the actual outcome values**
- **Step 2: Compare your prediction to the FIXED reference data**
- **Step 3: Choose which side of each FIXED reference threshold offers value**
- Outputs are internally consistent: aggregate metric equals the sum of 
  sub-category values.
- By default, the narrative should support the entities with the sum of their 
  ratings as higher than the other entity. The sum of primary and secondary 
  ratings should be considered and be an influencing factor.
- Speak in first-person plural ("we") throughout.

 

User Prompt

JSON
Analyze the following [DOMAIN] scenario and provide your prediction for the 
favored entity, aggregate metrics, and individual sub-metrics, ensuring strict 
adherence to the Response Format.

SCENARIO INFORMATION:
- Entity A: {entity_a} ({entity_a_abbrev})
- Entity B: {entity_b} ({entity_b_abbrev})
- Category: {entity_a} ({entity_a_category}) vs {entity_b} ({entity_b_category})
- Period {time_period}, Cycle {cycle}
- Date: {analysis_date}
- Environmental Factor: {environmental_factor}

REFERENCE DATA:
- Primary Threshold: {threshold_primary}
- Secondary Threshold (Aggregate): {threshold_secondary}
- Entity A Indicator: {entity_a_indicator}
- Entity B Indicator: {entity_b_indicator}

CRITICAL: Your recommendations MUST use these exact reference numbers:
✓ Primary recommendation must contain exactly: {threshold_primary}
✓ Aggregate recommendation must contain exactly: {threshold_secondary}

ENTITY RATINGS (from analytics provider):

Entity A ({entity_a}):
- Primary Metric: {entity_a_metric_1}
- Secondary Metric: {entity_a_metric_2}
- Key Factors: {entity_a_key_factors}

Entity B ({entity_b}):
- Primary Metric: {entity_b_metric_1}
- Secondary Metric: {entity_b_metric_2}
- Key Factors: {entity_b_key_factors}

COMPARISON ANALYSIS:
Outcome Nature: {outcome_nature_predicted} (Dominant Factor: {dominant_factor})
Analysis: {Analysis}

Metric Comparisons:
- Entity A Secondary vs Entity B Primary: {comparison_calc[entity_a_metric_2_vs_entity_b_metric_1]}
- Entity B Secondary vs Entity A Primary: {comparison_calc[entity_b_metric_2_vs_entity_a_metric_1]}
- Entity A Primary vs Entity B Secondary: {comparison_calc[entity_a_metric_1_vs_entity_b_metric_2]}
- Entity B Primary vs Entity A Secondary: {comparison_calc[entity_b_metric_1_vs_entity_a_metric_2]}

PREDICTION REQUIREMENTS:
1. Use realistic values based on entity strengths, factor comparisons, and conditions.
2. Use first-person plural in the narrative.
3. "Confidence Percentage" represents your conviction in the prediction.
4. Ensure "key_factors" list the most influential reasons, including rating advantages.
5. "Risk Level" should be low, medium, or high based on confidence and variables.
6. Provide detailed reasoning explaining your analysis.
7. Use entity NAMES (not abbreviations) in individual_sub_metrics keys.

IMPORTANT: Generate your prediction in JSON format matching the response format exactly.

 

Response Format

JSON
{
  "predicted_outcome": "entity name",
  "confidence_percentage": "number between 0-100",
  "predicted_margin": "number (must match current reference threshold)",
  "aggregate_metric": "integer",
  "individual_sub_metrics": {
    "entity_a_name": "number",
    "entity_b_name": "number"
  },
  "key_factors": [
    "list 3 main factors influencing the prediction, be sure to include 
     important differences in the sum of ratings for primary and secondary 
     metrics and the top rated factors, but don't mention the actual 
     rating numbers"
  ],
  "risk_level": "low/medium/high",
  "reasoning": "brief explanation",
  "recommendations": [
    {
      "type": "primary",
      "value": "ENTITY EXACT CURRENT REFERENCE THRESHOLD ONLY - If Current 
               is 'ENT-B -13.5', use either 'ENT-B -13.5' or 'ENT-A +13.5')",
      "entityID": "339",
      "confidence": 92,
      "bestChoice": true,
      "outcome": "keep this empty"
    },
    {
      "type": "aggregate",
      "direction": "above/below",
      "value": "EXACT CURRENT REFERENCE THRESHOLD ONLY - If Current is '56.5', 
               use '56.5'",
      "confidence": 86,
      "bestChoice": true,
      "outcome": "keep this empty"
    }
  ]
}

 

4.2 Step 1 (Quality Check Chain) – Design & Behavior

Purpose: Ensure exact reference numbers are used in recommendations[].value without altering any other fields.

Behavior: Receives CURRENT REFERENCE DATA and the Parent output; only corrects threshold values if they don’t match the provided reference numbers.

Editing Guidance:

• Safe to strengthen rules and checklists.
• Do not change the requirement to keep predictions, confidence, reasoning, and risk unchanged.

Step 1 – Validation Prompt (Generalized Template)

System Prompt

JSON
You are a quality control expert for [DOMAIN] predictions.
Review the prediction for internal consistency, data completeness, and 
reasoning quality.

IMPORTANT: Preserve ALL fields from the input prediction exactly as they are.
Only add a quality_assessment field.

Return your response in JSON format matching the input structure.

 

User Prompt

JSON
QUALITY CHECK TASK: Review this prediction and return it with quality 
assessment added.

PREVIOUS PREDICTION (from Step 1):
{current_prediction}

CONTEXT:
- Outcome Nature: {outcome_nature_predicted}
- Dominant Factor: {dominant_factor}

CHECK FOR:
1. Aggregate = sum of sub-metrics (approximately)
2. No zero/negative values
3. Reasoning mentions outcome nature and key comparisons
4. Confidence aligns with recommendation strength
5. All required fields present (predicted_outcome, recommendations, 
   key_factors, reasoning)

CRITICAL: Return the COMPLETE prediction in JSON format with ALL original 
fields preserved.
Only add ONE additional field: "quality_assessment" with your review 
(keep it brief, 1-2 sentences).

 

Response Format

JSON
{}

 

4.3 Step 2 (Quality Check Chain) – Design & Behavior

Purpose: Enhance the overall narrative quality and fine-tune confidence levels without changing predictions.

Behavior: Receives the validated prediction from Step 1, refines reasoning clarity, expands explanations, and aligns confidence percentages with analysis strength (±5% range).

Editing Guidance:

• Safe to improve narrative tone, phrasing, and analytical explanation.
• Do not modify predicted values, recommendations, or reference numbers.
• Remove any internal-only fields (like quality_assessment) from the final output.

Step 2 – Final Polish Prompt (Generalized Template)

System Prompt

JSON
You are an expert editor for [DOMAIN] analysis content.
Enhance the reasoning and ensure confidence levels match the strength of 
the analysis.

IMPORTANT: Keep all predictions, recommendations, and key data unchanged.
Only improve narrative quality and adjust confidence slightly if needed 
(±5% max).

Return your response in JSON format matching the input structure.

 

User Prompt

JSON
FINAL POLISH TASK: Enhance reasoning quality and calibrate confidence.

STEP 1 OUTPUT (initial prediction):
{step_1_output}

STEP 2 OUTPUT (after quality check):
{step_2_output}

CURRENT PREDICTION (from Step 2):
{current_prediction}

CONTEXT:
- Outcome Nature: {outcome_nature_predicted}
- Dominant Factor: {dominant_factor}

REQUIREMENTS:
1. Preserve ALL recommendations, predicted_outcome, and values exactly as 
   they are
2. Expand reasoning to 250+ chars if shorter (include specific comparison 
   analysis)
3. Mention outcome nature prediction and how recommendations align with it
4. Adjust confidence ONLY if reasoning doesn't support it (±5% max)
5. Remove quality_assessment field if present (it's internal only)

CRITICAL: Return the COMPLETE prediction in JSON format with ALL fields 
from Step 2.
DO NOT zero out any values. DO NOT change predicted_outcome to "Unknown".

 

Response Format

JSON
{
  "predicted_outcome": "entity name",
  "confidence_percentage": "number between 0-100",
  "predicted_margin": "number (must match current reference threshold)",
  "aggregate_metric": "integer",
  "individual_sub_metrics": {
    "entity_a_name": "number",
    "entity_b_name": "number"
  },
  "key_factors": [
    "list 3 main factors influencing the prediction, be sure to include 
     important differences in the sum of ratings for primary and secondary 
     metrics and the top rated factors, but don't mention the actual 
     rating numbers"
  ],
  "risk_level": "low/medium/high",
  "reasoning": "brief explanation",
  "recommendations": [
    {
      "type": "primary",
      "value": "ENTITY EXACT CURRENT REFERENCE THRESHOLD ONLY",
      "entityID": "339",
      "confidence": 92,
      "bestChoice": true,
      "outcome": "keep this empty"
    },
    {
      "type": "aggregate",
      "direction": "above/below",
      "value": "EXACT CURRENT REFERENCE THRESHOLD ONLY",
      "confidence": 86,
      "bestChoice": true,
      "outcome": "keep this empty"
    }
  ]
}

 

4.4 Chained Prompt V1 (Parent + Step 1 + Step 2)

The Chained Prompt V1 integrates three layers:

• Parent Prompt: Produces predictions.
• Step 1 (Quality Check): Adds a quality_assessment field verifying internal consistency.
• Step 2 (Final Polish): Enhances reasoning and calibrates confidence.

The flow is automated – each step passes its output to the next until the final JSON response is produced.

 

5.0 Analyst Operations & Editing Guide

5.1 How to Experiment Safely in the Platform

• Open Parent Prompt to tweak narrative factors, risk framing, and key_factors emphasis.
• Open Step 1 (Quality Check): to tighten reference-number enforcement and checklist language.
• Open Step 2 (Final Polish) to refine the writing norms and required formatting checks.
• Run the chain (Parent → Step 1 → Step 2) and compare Parent to Final output on the tracing dashboard to see what was the output on each step to see exactly what changed.

Encouragement: Please play with these three prompts in the live platform to fit your style. Adjust emphasis on entity strengths, factor comparisons, environmental conditions, and category differences in the Parent; reinforce numeric rules in Step 1 and formatting rules on Step 2 or you can add your own steps below.

5.2 Do / Don’t Checklist

Do

• Keep JSON keys and structure intact.
• Ensure sub-metrics sum to the aggregate metric.
• Use exact reference numbers in recommendations[].value.
• Document what you changed and why in prompt comments (if available).

Don’t

• Don’t invent thresholds or alter reference numbers.
• Don’t remove safety reminders about fixed values.
• Don’t change Step 1 to modify predictions, confidence, or reasoning.

5.3 Validation Checklist (Reference Number Integrity)

• Does primary recommendation use the exact reference threshold?
• Does aggregate recommendation use the exact reference threshold?
• Does the recommendation side align with predicted value vs threshold logic?
• Do sub-metrics sum to the aggregate metric?
• Is the schema valid JSON matching the Response Format?

 

6.0 End-to-End Runbook

6.1 Configure Inputs

• Navigate to the prediction interface.
• Select the entities and time period for analysis.
• Verify reference data is loaded from external source.
• Confirm chain configuration (Single vs. Chained mode).

6.2 Run Parent

• Execute the Parent prompt.
• Review JSON output for completeness.
• Verify predictions are logically consistent.

6.3 Run Step 1 (Validation)

• System automatically passes Parent output to Step 1.
• Step 1 validates reference number compliance.
• Adds quality_assessment field with validation notes.

6.4 Run Step 2 (Final Polish)

• System passes Step 1 output to Step 2.
• Step 2 enhances narrative and calibrates confidence.
• Removes internal quality_assessment field.
• Produces final JSON output.

6.5 Review Output & Log Trace

For the observability, a tracing platform has been integrated to enable advanced prompt observability and traceability across the entire chain. This integration records each prompt execution step – capturing inputs, outputs, timing data, model responses, and metadata such as prompt version, chain identifier, and user who initiated the run. This observability layer is essential for understanding system behavior during production runs.

Through the tracing dashboard, analysts and engineers can:

• View detailed logs of each chain step (Parent, Step 1, etc.), including prompt text and returned responses.
• Compare inputs vs outputs to pinpoint logic or formatting issues.
• Monitor latency, token usage, and response consistency over time.
• Audit past executions and correlate prediction outcomes with prompt changes.

This capability makes the entire prompt-chaining system more transparent, measurable, and maintainable, enabling both debugging and continuous improvement efforts.

 

7.0 Examples & Usage Notes

7.1 Textual Flow Example (No Real Data)

Scenario Setup:

• Entity A: Alpha Corp (ALP)
• Entity B: Beta Industries (BET)
• Reference Primary Threshold: BET -17.5
• Reference Aggregate Threshold: 45.5

Parent Output (Step 1):

JSON
{
  "predicted_outcome": "Beta Industries",
  "confidence_percentage": 78,
  "predicted_margin": -17.5,
  "aggregate_metric": 54,
  "individual_sub_metrics": {
    "Alpha Corp": 20,
    "Beta Industries": 34
  },
  "key_factors": [
    "Beta Industries shows significant primary metric advantage",
    "Alpha Corp has struggled in recent comparable scenarios",
    "Environmental conditions favor Beta Industries' approach"
  ],
  "risk_level": "medium",
  "reasoning": "We project Beta Industries to outperform based on...",
  "recommendations": [
    {
      "type": "primary",
      "value": "BET -17.5",
      "entityID": "bet_001",
      "confidence": 78,
      "bestChoice": true,
      "outcome": ""
    },
    {
      "type": "aggregate",
      "direction": "above",
      "value": "45.5",
      "confidence": 82,
      "bestChoice": true,
      "outcome": ""
    }
  ]
}

Step 1 Output (Validation):

JSON
{
  "predicted_outcome": "Beta Industries",
  "confidence_percentage": 78,
  "predicted_margin": -17.5,
  "aggregate_metric": 54,
  "individual_sub_metrics": {
    "Alpha Corp": 20,
    "Beta Industries": 34
  },
  "key_factors": [
    "Beta Industries shows significant primary metric advantage",
    "Alpha Corp has struggled in recent comparable scenarios",
    "Environmental conditions favor Beta Industries' approach"
  ],
  "risk_level": "medium",
  "reasoning": "We project Beta Industries to outperform based on...",
  "recommendations": [
    {
      "type": "primary",
      "value": "BET -17.5",
      "entityID": "bet_001",
      "confidence": 78,
      "bestChoice": true,
      "outcome": ""
    },
    {
      "type": "aggregate",
      "direction": "above",
      "value": "45.5",
      "confidence": 82,
      "bestChoice": true,
      "outcome": ""
    }
  ],
  "quality_assessment": "Prediction is internally consistent. Sub-metrics sum to 54. Recommendations use exact reference values."
}

Step 2 Output (Final Polish):

JSON
{
  "predicted_outcome": "Beta Industries",
  "confidence_percentage": 80,
  "predicted_margin": -17.5,
  "aggregate_metric": 54,
  "individual_sub_metrics": {
    "Alpha Corp": 20,
    "Beta Industries": 34
  },
  "key_factors": [
    "Beta Industries shows significant primary metric advantage",
    "Alpha Corp has struggled in recent comparable scenarios",
    "Environmental conditions favor Beta Industries' approach"
  ],
  "risk_level": "medium",
  "reasoning": "We project Beta Industries to outperform based on their substantial primary metric advantage and Alpha Corp's demonstrated struggles in similar scenarios. The environmental conditions present favor Beta Industries' methodology, and our aggregate projection of 54 exceeds the threshold of 45.5, supporting an 'above' recommendation with strong confidence.",
  "recommendations": [
    {
      "type": "primary",
      "value": "BET -17.5",
      "entityID": "bet_001",
      "confidence": 80,
      "bestChoice": true,
      "outcome": ""
    },
    {
      "type": "aggregate",
      "direction": "above",
      "value": "45.5",
      "confidence": 84,
      "bestChoice": true,
      "outcome": ""
    }
  ]
}

Key Observations:

• Parent generates complete prediction with exact reference values.
• Step 1 validates and adds quality assessment (no corrections needed).
• Step 2 expands reasoning, adjusts confidence slightly (+2%), removes internal field.

7.2 Common Edge Cases

Scenario	Behavior
Parent outputs fabricated threshold	Step 1 corrects to exact reference value
Sub-metrics don't sum to aggregate	Step 1 flags in quality_assessment
Reasoning is too brief	Step 2 expands to 250+ characters
Confidence misaligned with reasoning	Step 2 adjusts by ±5% maximum
quality_assessment in final output	Step 2 removes before returning

8.0 Future Scope (Step 3 and Beyond)

• Step 3 – External Validation: Adaptation for external source validation, for example cross-referencing with a third-party data provider or another prediction source.
• Step 4 – Format Adaptation: Transform output to different schemas for various downstream consumers.
• Step 5 – Historical Calibration: Adjust confidence based on historical accuracy patterns.

 

Appendix A – Full Legacy Single-Prompt (Reference)

The legacy system used a single monolithic prompt that attempted to handle all logic in one execution. This approach had several structural issues that motivated the migration to prompt chaining.

Legacy Architecture Issues

• Fabricated Values: The model would sometimes generate reference values from its training data rather than using the provided external data.
• No Intermediate Visibility: Analysts could not inspect reasoning stages – only the final output was visible.
• Brittle Modifications: Any change to narrative, validation, or formatting logic required editing the entire prompt, often introducing regressions.
• Error Attribution Impossible: When outputs were incorrect, there was no way to determine if the error originated from reasoning, data handling, or formatting.

Legacy Prompt Structure (Generalized)
System Prompt Pattern

JSON
You are an elite [DOMAIN] prediction expert with deep knowledge of 
[relevant fields]. Your role is to provide precise, data-driven predictions 
following the exact structure and response format requested.

**CRITICAL: The reference data is provided from an external source and is FIXED. 
You CANNOT create your own values. You can ONLY choose which side of the 
existing reference thresholds to recommend.**

Always ensure:
- Predictions are realistic and based on thorough analysis
- **Step 1: Predict the actual outcome values**
- **Step 2: Compare your prediction to the FIXED reference data**
- **Step 3: Choose which side of each FIXED reference threshold offers value**
- Outputs are internally consistent
- Speak in first-person plural ("we") throughout.

 

User Prompt Pattern

JSON
Analyze the following [DOMAIN] scenario and provide your prediction...

**CRITICAL RULES - THE MODEL KEEPS FAILING THIS:**

⚠️ **THE MODEL IS CREATING FAKE VALUES - THIS IS WRONG**

1. **YOU ARE AN ANALYST, NOT A DATA SOURCE**: You cannot set thresholds. 
   You can only choose from existing reference data.

2. **COPY THE NUMBERS EXACTLY FROM THE DATA**:
   - If data shows threshold "ENT-B -17.5" → Your recommendation is either 
     "ENT-B -17.5" or "ENT-A +17.5"
   - If data shows aggregate "45.5" → Your recommendation is either 
     "Above 45.5" or "Below 45.5"
   - **NEVER write different numbers**

4. **CORRECT LOGIC**:
   - Step 1: Look at the Current/Closing reference data
   - Step 2: Predict the outcome
   - Step 3: Compare prediction to reference data
   - Step 4: Choose the side of the EXISTING reference that offers value

5. **VERIFICATION CHECKLIST**:
   - Does my primary recommendation use the EXACT reference threshold number?
   - Does my aggregate recommendation use the EXACT reference threshold number?
   - Am I choosing the correct side based on my prediction vs reference?

[... additional instructions, entity data, and requirements ...]

**FINAL REMINDER**:
- Your recommendations MUST use the exact threshold numbers from the 
  "Current" reference data
- You are choosing SIDES of existing thresholds, not creating new values

 

Why the Legacy Approach Failed

Despite extensive prompt engineering (as shown above with multiple warnings, checklists, and examples), the single-prompt approach continued to produce fabricated values. The model would:

• Ignore the explicit instructions about using exact reference values
• Generate values from its training patterns instead of provided data
• Create internally consistent but externally invalid outputs

The chained architecture solves this by dedicating Step 1 specifically to validation and correction – a focused task that the model performs much more reliably than when validation is buried within a complex multi-objective prompt.