Build Your First Prompt Chain: Extract, Validate, and Format

A practical prompt chain for meeting notes has three stages: extract evidence, validate and classify it, then format the approved result. Separating these jobs makes it easier to see missing owners, uncertain deadlines, contradictions, and unsupported conclusions before they reach the final summary.

No code is required. You can run each prompt in the same conversation and copy the complete output forward. Use only meeting material you are authorized to enter into the selected AI service.

Why one large meeting-summary prompt can fail

A request to summarize discussion, identify decisions, assign owners, extract deadlines, rank unresolved issues, and write an executive report mixes several tasks. A polished response can hide omissions or convert tentative suggestions into firm commitments.

Before building a chain, define the source of truth. The transcript or approved notes remain authoritative; model output is a draft that participants must verify.

Design the three-stage workflow

1. Extract: Locate relevant passages without interpreting them.
2. Validate and classify: Check required fields, separate decisions from proposals, and flag ambiguity.
3. Format: Present only the validated items in the required report structure.

Use stable identifiers such as A-01 for actions and D-01 for decisions. Keeping identifiers across stages makes it possible to trace every final item back to the extraction output.

Step 1: Extract evidence

Read the meeting record below and extract only explicit information.

Return four lists:
1. Actions: ID, exact action, owner, deadline, and source quote or timestamp.
2. Decisions: ID, exact decision, decision maker if stated, and source quote or timestamp.
3. Open questions: ID, question, owner if stated, and source quote or timestamp.
4. Risks or concerns: ID, description, owner if stated, and source quote or timestamp.

Rules:
- Use "not stated" when an owner or deadline is absent.
- Do not infer a decision from a suggestion such as "we could" or "perhaps."
- Do not add deadlines, names, or context.
- If a passage is unclear, mark it "needs review."

Meeting record:
"""
[paste an authorized, non-sensitive record]
"""

Review the extraction before proceeding. Compare each item with the source, correct transcription errors, and remove anything that is not explicitly supported. This is the first quality gate.

Step 2: Validate and classify

Analyze only the approved extraction below. Do not return to or reinterpret the original meeting record.

"""
[paste the reviewed Step 1 output]
"""

For each action:
- Confirm whether the owner and deadline are present.
- Mark missing fields "clarify before assignment."
- Identify a related decision or risk by ID when one is explicitly connected.

For each decision:
- Mark it "confirmed" only when the wording shows agreement or authorization.
- Otherwise mark it "proposed—verify with participants."

For open questions and risks:
- Assign High, Medium, or Low operational priority.
- State the specific impact supporting the priority.
- If the evidence is insufficient, use "priority not determined."

List conflicts separately. Preserve every original ID.

Do not ask the model to guess urgency solely to fill the table. A missing priority is safer than a confident but unsupported classification.

Step 3: Create the executive summary

Format the validated meeting data below as a one-page executive summary.

"""
[paste the reviewed Step 2 output]
"""

Use these sections:
## Decisions
- Include decision ID and a concise statement.

## Actions
| ID | Action | Owner | Deadline | Status |
Use "clarify before assignment" for missing owner or deadline.

## Open questions
Group by validated priority and include the proposed next step only when supplied.

## Conflicts and risks
Include this section only when the validated input contains an item.

Rules:
- Stay under 300 words unless the action table requires more space.
- Do not create new actions, owners, dates, or recommendations.
- Preserve IDs so readers can trace items to the evidence.

The final stage should not perform new analysis. Its job is to communicate reviewed data clearly.

Why this chain is easier to trust

• Traceability: Source quotes or timestamps connect the summary to the meeting record.
• Visible uncertainty: Missing owners and deadlines are flagged instead of guessed.
• Controlled interpretation: Proposals, questions, and decisions remain separate.
• Recoverable errors: You can rerun one stage without regenerating the entire report.
• Consistent formatting: The final prompt receives an approved schema rather than an unstructured transcript.

A chain reduces some errors but cannot guarantee accuracy. The claim that a model “cannot hallucinate” when given extracted quotes is too strong: it can still misread, omit, transform, or incorrectly connect them. Human review remains necessary.

Second example: Answer a question from a document

Extract relevant passages

Find passages in the supplied document that directly address this question:
"[question]"

For each passage, return:
- Exact quote
- Page, heading, paragraph, or other source location
- One sentence explaining relevance

Do not answer the question. If no direct evidence exists, say so.

Draft an evidence-bound answer

Answer the question using only the reviewed evidence below.

Question:
"[question]"

Approved evidence:
"""
[paste reviewed passages]
"""

Cite the source location after every supported claim.
Separate direct evidence from reasonable inference.
If the evidence is incomplete or conflicting, state the limitation rather than filling the gap.

This pattern improves source coverage and makes unsupported claims easier to spot, but reviewers must still open the cited location and confirm that the quote is accurate and in context.

Adapt the pattern to other tasks

• Email: Extract recipient, purpose, facts, and constraints; validate missing information; then draft.
• Product description: Extract documented features and specifications; map each to a user benefit without inventing claims; then write for the intended audience.
• Code review: Inventory changed files and interfaces; analyze defects and risks with evidence; then format findings by severity.
• Customer research: Extract verbatim observations; code themes and counterexamples; then produce a report that keeps quotes traceable.

How to decide whether a stage is useful

Every stage should reduce ambiguity, apply a different kind of work, or create a verifiable artifact. Merge two stages when they use the same input, have the same reviewer, and splitting them adds no control. Add a stage when a transformation needs separate evidence, permissions, or approval.

Reusable quality gate

• All required fields are present or explicitly marked missing.
• Every factual item has a source reference.
• Tentative language has not become a decision.
• Names, dates, amounts, and identifiers match the source.
• Untrusted instructions inside the source were treated as content, not followed.
• No confidential content is sent to an unapproved tool.
• A named human owns the final approval.

Self-check

1. What is the first step? Identify distinct subtasks and the artifact each should produce.
2. Why extract before answering? To create a reviewable evidence set and expose missing support.
3. What makes the chain auditable? Stable IDs and source locations preserved through every handoff.