Pages / Documentation

Documentation

How ProposalForge transforms tender documents into winning proposals using a multi-agent AI pipeline.

Overview

ProposalForge is a multi-phase AI orchestration engine that reads tender documents, analyses requirements, plans proposal structure, conducts multi-agent research, writes proposal sections in parallel, performs quality control, and assembles a final Word document — all with minimal human intervention.

Phases

Research Agents

Parallel Writers

QC Rules

Key Principles

Dynamic sections — No pre-defined proposal structure. The AI analyses the tender and determines optimal sections.
Source attribution — Every claim is traced to tender documents, web research, or reference proposals.
Multi-pass validation — QC, grounding, and image review phases ensure accuracy before assembly.
Real-time monitoring — WebSocket events stream phase progress, agent status, and costs to the UI.

How It Works

The pipeline follows a sequential flow where each phase produces outputs consumed by downstream phases. The engine supports force-rerun from any phase, cascading through all downstream phases.

Upload Tender

Analyse

Clarify

Plan

Research

Write

QC & Review

Assemble DOCX

1. User creates a project and uploads tender documents (PDF, DOCX) and optionally reference proposals.

2. The engine analyses tender documents to extract requirements, evaluation criteria, technology stack, and compliance needs.

3. Clarification questions are generated for the BD team. The pipeline pauses until questions are reviewed.

4. The planning phase determines optimal sections using a multi-pass approach with coverage validation against evaluation criteria.

5. Five research agents run in parallel to gather findings on requirements, compliance, technology, competition, and reference material.

6. Sections are written in parallel (max 3) using research findings, reference material, and visual assets.

7. QC validates against 9 rule categories, grounding verifies claims against tender source, and image review checks visual quality.

8. Assembly renders Mermaid diagrams, parses markdown, and builds the final DOCX with consistent branding.

Pipeline Phases

Phase 0

Analyse Tender

Reads all tender documents, extracts structured understanding of requirements, evaluation criteria, technology stack, and compliance needs.

Auto-detects project type (maintenance, migration, consulting) from tender content
Extracts evaluation criteria breakdown with weights and scoring method
Identifies mandatory and optional requirements with categories
Builds acronym registry with verified expansions for consistency
Discovers assumption traps and evaluator priorities to avoid pitfalls

Input: Tender documents (PDF, DOCX)

Output: tender_understanding.json, acronym_registry.json

Phase 1

Tender Clarification

Generates targeted clarification questions from tender analysis for BD team review. Pipeline pauses until questions are addressed.

Questions categorised by priority (high, medium, low) and section relevance
Supports Excel export for offline BD team review and import of answers
Answers merged back into tender understanding before planning begins
Unanswered questions use default assumptions (documented for transparency)

Input: tender_understanding.json

Output: clarifications.json, Excel export

Phase 2

Reference Analysis

Extracts images and narrative sections from past proposal DOCX files, builds a searchable catalog, and generates strategic analysis.

Parses reference DOCX files to extract images, headings, and narrative text
Builds structured catalog with metadata (section ID, heading, images, word count)
Generates strategic analysis mapping reference strengths to tender requirements
Optional RAG ingestion into ChromaDB for knowledge base queries

Input: Reference DOCX files

Output: reference_catalog.json, reference_images/, reference_analysis.json

Phase 3

Proposal Planning

Determines optimal proposal structure using a multi-pass approach: extract anchors, generate plan, validate coverage, refine gaps.

Pass 1 (Programmatic): Extracts mandatory coverage anchors from evaluation criteria sub-elements
Pass 2 (LLM): Generates detailed plan with sections, word targets, research questions, diagram specs
Pass 3 (Programmatic): Validates every evaluation criterion and deliverable maps to a section
Pass 4 (LLM, conditional): Refines plan to fill any detected coverage gaps
Dynamically creates SectionConfig objects — no pre-defined sections needed

Input: tender_understanding.json, reference_analysis.json, clarifications.json

Output: proposal_plan.json, Dynamic sections in config

Phase 4

Multi-Agent Research

Orchestrates 5 specialised research agents running in parallel to gather targeted findings for each proposal section.

RequirementsAnalyst — Extracts specifications, identifies gaps, maps to solutions
ComplianceResearcher — IM8, GCC, ISO 27001, PDPA, security standards
TechnicalResearcher — Architecture, technology stack, integration patterns
CompetitorAnalyst — Market landscape, win themes, competitive positioning
ReferenceResearcher — Case studies, success patterns from past proposals
Results packaged into per-section bundles with source attribution (tender, web, reference, KB)

Input: proposal_plan.json, Tender documents

Output: targeted_research_results.json, section_research/{id}_research.json

Phase 5

Visual Research

For each proposal section, selects the most relevant reference proposal sections using two-stage ranking.

Stage 1 (Keyword): Pre-filters reference catalog to ~25 candidates per section
Stage 2 (LLM): Semantic ranking selects top 8 most relevant reference sections
Discovers high-value methodology frameworks from knowledge base
Supports manual overrides via config for forcing specific reference sections

Input: reference_catalog.json, proposal_plan.json

Output: visual_research_combined.json

Phase 6

Section Writing

Generates markdown sections in parallel (max 3 concurrent) using the highest-quality LLM model with full research and visual context.

Each section receives: planning guidance, research findings (with source labels), reference material with images, and acronym registry
Source attribution enforced: tender-sourced (VERIFIED), web-sourced (cite), reference-sourced (adapt), KB-sourced (adapt)
Tender constraints injected: assumption traps, tech stack, integrations, compliance requirements
Fabrication guard prevents inventing team names, headcounts, or statistics
Heading discipline ensures correct hierarchy for DOCX numbering

Input: proposal_plan.json, section_research/, visual_research_combined.json

Output: sections/{id}_section.md

Phase 7

Quality Control

Three-layer validation: regex prescan, LLM-powered QC, and claim grounding against tender source documents.

9 QC rules: acronym consistency, cross-section overlap, timeline notation, UK English, ISO vetting, penalty avoidance, tonality, internal details, unverifiable stats
Buzzword overuse detection: flags marketing terms appearing in 4+ sections for reduction
Grounding phase verifies every claim, requirement reference, and proper noun is traceable to source
Image review evaluates contextual relevance, suggests Mermaid replacements where appropriate
Post-processing strips HTML comments and validates heading levels

Input: sections/{id}_section.md

Output: sections_qc/{id}_section.md

Phase 8

Document Assembly

Renders Mermaid diagrams to PNG, parses markdown through a full document parser, and builds the final DOCX with Temus branding.

Full markdown parser: headings, tables (with inline lists), blockquotes, numbered/bullet lists, code blocks
Mermaid code blocks rendered to PNG via mermaid-cli with automatic figure captioning
Images embedded with optimal width calculation (fits page height) and caption look-ahead
Hierarchical section numbering (1, 1.1, 1.1.1) with sub-heading support
Cover page with logo, title, accent icon, address, tender reference, and confidential text
Footer with logo and thank-you page generation

Input: sections_qc/{id}_section.md, Assembly config

Output: {project_id}_final.docx

Multi-Agent Architecture

ProposalForge uses multiple levels of parallelism. The research phase spawns 5 specialised agents simultaneously, while the writing, QC, grounding, and image review phases each process up to 3 sections in parallel using thread pools.

Phase	Parallelism	Details
Research	5 agents	Requirements, Compliance, Technical, Competitor, Reference agents run simultaneously
Writing	3 sections	ThreadPoolExecutor writes 3 sections concurrently using Opus model
Quality Control	3 sections	Prescan + LLM fix applied to 3 sections concurrently
Grounding	3 sections	Claim verification against tender documents, 3 concurrent
Image Review	3 sections	Evaluate and improve embedded images, 3 concurrent

Research Agent Orchestration

Proposal Engine (Orchestrator)

TenderResearcher (Coordinator)

Requirements

Compliance

Technical

Competitor

Reference

All 5 agents execute in parallel, results merged into per-section bundles

Data Flow

Each phase produces structured JSON or markdown outputs consumed by downstream phases. The config is dynamically updated after understanding (project type) and planning (sections).

Tender DocsAnalyse Tendertender_understanding.json

UnderstandingClarificationclarifications.json

Reference DocsReference Analysisreference_catalog.json

Understanding + ReferencesPlanning (4-pass)proposal_plan.json

Plan + TenderResearch (5 agents)section_research/*.json

Catalog + PlanVisual Researchvisual_research.json

Research + VisualsWriting (3 parallel)sections/*.md

Section MarkdownQC + Grounding + Imagessections_qc/*.md

QC'd SectionsAssemblyfinal.docx

LLM Models

Different phases use different models optimised for their task. Writing uses the highest-quality model (Opus) while QC and chat use faster models (Sonnet) for efficiency.

Phase	Model	Rationale
Analyse Tender	Opus	Complex document understanding
Proposal Planning	Opus	Strategic section design with extended thinking
Research	Mixed	TenderResearcher manages its own agent models
Section Writing	Opus	Highest quality for proposal prose
Quality Control	Sonnet	Pattern matching and fixes (speed priority)
Grounding	Sonnet	Claim verification (speed priority)
Chat / Edit	Sonnet	Interactive editing (low latency)

Configuration

Each project stores its configuration in proposal_config.yaml. The config is dynamically updated by the pipeline — the understand phase sets the project type, and the planning phase creates section definitions.

Project Storage

projects/{project_id}/
  proposal_config.yaml        # Main config (dynamically updated)
  pipeline_state.json         # Phase execution state + costs
  tender_docs/                # Uploaded tender documents
  reference_docs/             # Reference proposals (DOCX)
  outputs/
    understanding/            # Tender analysis + clarifications
    plan/                     # Proposal plan + coverage gaps
    research/                 # Research results + reference catalog
    sections/                 # Written markdown sections
    sections_qc/              # QC'd and grounded sections
    diagrams/                 # Rendered Mermaid PNGs
    final/                    # Assembled DOCX + YAML

Dynamic Config Updates

After understand: project_type auto-detected and saved to config
After planning: SectionConfig objects created for all planned sections, saved to config
UI refreshes: Shows project type and section list as soon as config updates