AIDRAD: Using Meeting Transcripts, SOPs, and Emails to Generate Better Requirements

In Part 1 of our AIDRAD Foundation Series, we demonstrated how replacing 60-page narrative BRDs with Structured Intent Contracts eliminates requirement ambiguity, prevents scope creep, and provides a machine-executable specification for AI agents and engineering teams.

The immediate and fair question every technical leader asks is:

“Business stakeholders do not write YAML schemas or JSON state machines. They speak in rambling 60-minute meetings, forward fragmented 12-message email chains, and reference outdated 40-page PDF SOPs written four years ago. How do we bridge the gap between chaotic human communication and a clean Intent Contract?”

In traditional IT, that bridge was an army of Business Analysts (BAs) spending four to six weeks manually synthesizing interview notes into a narrative document. In the AIDRAD framework, we treat unstructured communication as a multi-stream data ingestion pipeline that extracts structured intent automatically while explicitly highlighting enterprise contradictions.

1. Architecture: The Multi-Source Intent Synthesis Engine

Instead of relying on human note-takers to capture fragmented conversations, the pipeline ingests three raw input streams:

flowchart LR
    A["🎙️ Stream Audio Transcripts"] & B["📧 Threaded Emails"] & C["📑 Legacy SOP PDFs"] --> D["🔍 Role & Diarization Parser"]
    D --> E["⚠️ Semantic Conflict Engine
Institutional Contradictions"]
    E --> F["📐 Pydantic Intent Contract"]
    F --> G["🚀 Day-3 Interactive Prototype"]

    style A fill:#1e293b,stroke:#3b82f6,stroke-width:2px,color:#f8fafc
    style B fill:#1e293b,stroke:#a855f7,stroke-width:2px,color:#f8fafc
    style C fill:#1e293b,stroke:#64748b,stroke-width:2px,color:#f8fafc
    style D fill:#1e293b,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    style E fill:#1e293b,stroke:#f59e0b,stroke-width:2px,color:#f8fafc
    style F fill:#1e293b,stroke:#10b981,stroke-width:2px,color:#f8fafc
    style G fill:#064e3b,stroke:#34d399,stroke-width:2px,color:#f8fafc
  

flowchart LR
    A["Stream Audio Transcripts"] & B["Threaded Emails"] & C["Legacy SOP PDFs"] --> D["Role & Diarization Parser"]
    D --> E["Semantic Conflict Engine (Highlights Contradictions)"]
    E --> F["Pydantic Intent Contract"]
    F --> G["Day-3 Interactive Prototype"]

Building on our earlier work on extracting actionable tasks from Microsoft Stream meeting recordings, we do not simply summarize what people said. Summaries preserve ambiguity. We extract state boundaries, entity invariants, and decision authority.

2. Why Raw Prompts Fail on Transcripts (The Grounding Problem)

If you paste a 10,000-word meeting transcript into an LLM and prompt: “Extract the software requirements”, you will receive a generic, hallucinated bulleted list. The model assumes every conversational suggestion is a hard requirement, confuses tentative hypotheticals with policy, and misses implicit edge cases.

To produce deterministic engineering specifications, the extraction must enforce strict schema validation using structured outputs (such as Pydantic in Python):

from pydantic import BaseModel, Field
from typing import List, Optional

class ExtractedRule(BaseModel):
    rule_id: str
    category: str = Field(description="Must be one of: CONSTRAINT, STATE_TRANSITION, INVARIANT, SLA")
    statement: str = Field(description="Exact declarative requirement statement")
    source_speaker: str = Field(description="Person who stated the requirement")
    source_timestamp_or_section: str
    confidence_level: str = Field(description="CONFIRMED_AGREEMENT vs HYPOTHETICAL_DISCUSSION")

class DisambiguationIssue(BaseModel):
    issue_id: str
    topic: str
    conflicting_sources: List[str]
    detected_conflict: str
    clarification_question_for_stakeholder: str

class TranscriptExtractionOutput(BaseModel):
    intent_domain: str
    extracted_rules: List[ExtractedRule]
    open_conflicts: List[DisambiguationIssue]

3. The Secret Weapon: Automated Semantic Conflict Detection

The single most valuable output of this ingestion stage is not the rules—it is the Semantic Conflict Detection. In enterprise software delivery, late rework occurs because different stakeholders hold conflicting mental models of how the business actually operates.

Consider an actual conflict surfaced in a real enterprise procurement workflow:

• Source A (Legacy 2022 SOP PDF): “Purchase orders exceeding $25,000 must receive dual sign-off from the Finance Controller and the Department Head.”
• Source B (Recorded Stakeholder Call): The VP of Finance states: “We recently updated the threshold; anything under $50,000 can be approved by the Department Head alone to avoid bottlenecks.”
• Source C (Email Chain from Compliance): An email states: “Internal audit still requires all capital expenditures over $10,000 to undergo secondary treasury review.”

In a traditional BRD cycle, a business analyst writes down one version or glosses over the discrepancy. Six months later in UAT, the system is rejected because Finance and Compliance disagree on the workflow.

The AIDRAD pipeline extracts all three assertions, links them directly to their citations, and generates a 1-Page Disambiguation Questionnaire before a single developer begins coding:

conflict_id: "CONF_042"
domain: "purchase_order_approval_threshold"
contradiction:
  source_1: "SOP_v3.pdf: Section 4.1 ($25,000 dual sign-off)"
  source_2: "Transcript_20261012.vtt: VP Finance @ 14:22 ($50,000 single sign-off)"
  source_3: "Email_Compliance_20261014.eml: Audit Head ($10,000 treasury rule)"
action_required:
  question_for_steering_committee: "Please confirm: What is the binding threshold for single vs dual approval, and does the $10,000 treasury rule apply to operational expenditure or capital expenditure only?"

Resolving this conflict takes 10 minutes in a steering chat instead of three weeks of late architectural refactoring.

4. Compiling into the Day-3 Interactive Demo

Once the disambiguation questions are answered, the validated rules compile directly into the state_transitions and invariants blocks of the Structured Intent Contract we detailed in Part 1.

As we outlined in our methodology for the Intent to Demo to Harden to Go-Live lifecycle, this intent contract is not filed away in a SharePoint directory. It is immediately used to scaffold a Day-3 interactive mock application. Stakeholders click through the actual form states, test the approval gates, and confirm that the system matches their operational reality.

Executive Takeaways

• Compress Discovery from Weeks to Hours: Ingest 15 hours of meeting audio, 40 email threads, and 200 pages of legacy SOPs in minutes to produce a structured candidate schema.
• Expose Institutional Contradictions Early: Surface operational disagreements between departments on Day 1 rather than during User Acceptance Testing on Month 4.
• Zero Loss in Translation: Requirements maintain a clear, unbroken audit trail from raw audio timestamps and email message-IDs straight to automated test suites.

In Part 3 of the AIDRAD Foundation Series, we will examine Autonomous Execution Pipelines: how modern AI agents take verified intent schemas and automatically scaffold production-ready database migrations, backend controllers, and unit tests.