TenderAI

An enterprise AI copilot that turns tender requirements and approved historical evidence into traceable technical proposals, with human review, risk controls, and Word-ready delivery.

Comment

Inspiration

Creating a technical tender proposal is not simply a writing task. Teams must interpret hundreds of requirements, locate reliable evidence across years of historical documents, coordinate multiple reviewers, manage images and attachments, and finally assemble a compliant Word document.

Traditional workflows depend heavily on manual search and copy-paste. Generic AI writing tools can produce fluent text, but they often lose source traceability, reuse outdated project-specific claims, or generate content that cannot survive formal review.

We built TenderAI to make proposal production faster without sacrificing evidence, accountability, or human control.

What it does

TenderAI is an enterprise AI assistant for producing technical tender documents through a controlled, traceable workflow.

It can:

  • Parse DOCX and PDF tender documents, including local OCR for scanned pages.
  • Convert tender content into atomic requirements linked to exact source locations.
  • Extract reusable text, tables, images, and product capabilities from historical proposals.
  • Version and review knowledge at project, department, and company scopes.
  • Combine keyword and local embedding retrieval to find relevant historical evidence.
  • Build an immutable evidence pack for each response unit.
  • Generate or rewrite content only from approved evidence.
  • Trace generated claims back to their supporting sources.
  • Flag high-risk claims, missing evidence, historical names, and project-specific commitments.
  • Support assignments, revisions, review issues, approvals, and multi-user workflows.
  • Assemble approved chapters and images into clean, reproducible Word and PDF deliverables.

Pricing and signature activities remain human-controlled tasks. TenderAI does not automatically fill commercial quotations or signatures.

How we built it

TenderAI uses a modular architecture built around FastAPI, PostgreSQL, pgvector, object storage, and independent background workers.

PostgreSQL is the system of record for projects, requirements, knowledge versions, evidence packs, revisions, reviews, and audit events. Search indexes, embeddings, previews, and generated documents are treated as reproducible projections rather than authoritative facts.

A lightweight local bge-small-zh-v1.5 embedding service provides semantic retrieval without sending historical proposal content to an external provider. External AI models are connected through a controlled gateway with immutable provider configuration, payload hashing, explicit approval, risk scanning, budget limits, and usage auditing.

Headless LibreOffice is used for deterministic Word and PDF assembly, so automated builds do not depend on Windows GUI automation.

Enterprise identity is delegated to an existing IAM platform using RS256 tokens and a stable user identifier. Project permissions and database row-level security prevent cross-project data access.

Challenges we faced

One major challenge was preserving traceability across the entire workflow. A generated paragraph must remain linked to the exact requirement, evidence version, model input, human revision, and approval decision that produced it.

Historical proposal quality was another challenge. Real documents contain repeated paragraphs, missing titles, generic image captions, broken internal relationships, outdated project names, and large embedded media collections. We therefore separated immutable source material from reviewable semantic suggestions instead of allowing automated cleanup to overwrite history.

Document assembly was also significantly harder than plain text generation. Page numbering, tables of contents, images, captions, headers, and final Word compatibility required a dedicated two-pass build process.

Finally, we designed external model access to fail closed. If the provider, model, approved payload, recipient, project policy, or budget does not match the frozen authorization, the request is blocked before any network transmission.

Accomplishments

We validated the historical knowledge pipeline against ten large proposal files totaling more than 1.1 GB.

The current evaluation corpus produced:

  • 48,118 extracted content units.
  • 14,533 reviewable knowledge candidates.
  • 5,355 traceable image assets.
  • 12,332 semantic review clusters.
  • 100% source-location coverage for accepted structural candidates.
  • A potential duplicate retrieval reduction of 15.14%.
  • 557 passing automated regression tests.

The deployed core supports enterprise authentication, project isolation, requirement correction, evidence packs, revisions, review workflows, image review, audit trails, and reproducible Word/PDF assembly.

We also created an 80-item human evaluation set covering exact duplicates, near duplicates, title and summary quality, and image context. Image-based review rows include the actual source image rather than relying only on surrounding text.

What we learned

The quality of an AI-generated proposal depends more on evidence quality than on model size.

A stronger language model cannot compensate for incorrect requirements, noisy historical material, poor retrieval, or unverified claims. The most valuable architecture is therefore not “upload documents and generate everything,” but a staged process:

parse → verify → retrieve → select evidence → generate → review → assemble

We also learned that uncertainty must remain visible. When evidence is missing, the system should create a review issue instead of producing confident but unsupported text.

What's next

Our next milestone is to complete the human evaluation of the semantic knowledge candidates and compare retrieval before and after administrator approval.

After that, we will run controlled A/B tests on approved, de-identified response units using selected external models. Only models that improve factual coverage, traceability, risk control, and human editing effort will enter a single-response-unit pilot.

The longer-term goal is to expand from one controlled response unit to a complete technical proposal while preserving the same evidence, authorization, review, and reproducibility guarantees.

Built With

Share this project:

Updates