TenderGraph

An agentic tender operating system that helps bidder teams find the right opportunities, prepare compliant bids, track every change, and keep final submission under human control.

Comment

Inspiration

We were asked to examine a tender at the opening stage. By the time we completed the review, Chile's public procurement portal already showed the procedure as awarded.

The documents were still relevant, but the procurement process had advanced while our analysis remained tied to an earlier stage. That exposed a broader problem: bidder teams work across opportunities, requirements, spreadsheets, attachments, amendments, deadlines, and outcomes, but the state of a tender keeps changing while the work is underway.

A new opportunity must first be qualified. Requirements must be traced to the current documents. People need to know what to prepare, what remains missing, and whether the bid is still commercially viable. An amendment can then alter one requirement, invalidate existing work, or create a new compliance blocker days before submission.

Most teams manage this lifecycle across disconnected portals, email, spreadsheets, shared folders, and document assistants that only answer questions about the file currently in front of them.

The scale is substantial. Public procurement represented 12.7% of OECD GDP and 29.9% of government expenditure in 2023.

The Open Contracting Data Standard models procurement as a sequence of releases, updates, and amendments. We built TenderGraph to coordinate that changing lifecycle while keeping evidence, approvals, and submission authority explicit.

What it does

TenderGraph is an agentic tender operating system for bidder teams.

It coordinates seven stages of the bidding lifecycle:

  • opportunity discovery;
  • qualification;
  • requirements analysis;
  • bid preparation;
  • compliance;
  • amendment monitoring;
  • outcome learning.

The default workspace begins with three clearly labeled synthetic opportunities. TenderGraph ranks them using fit scores, highlights blockers, and recommends whether each opportunity should be selected, reviewed, or passed.

Selecting an opportunity does not automatically commit team resources. A bid manager must approve qualification before the preparation plan is unlocked.

TenderGraph then organizes the current requirements, connects each one to versioned evidence, assigns readiness states, and generates a dependency-aware bid plan with responsible human owners. Requirements can be covered, changed, incomplete, or waiting for review.

Compliance remains blocked while unresolved gaps exist. The final submission package can never be released by an agent; submission authority remains human-only.

When an amendment arrives, TenderGraph evaluates it against the complete requirement set. It identifies which requirements changed, which remain valid, which tasks must be reopened, and which compliance decisions require review.

The current benchmark demonstrates this flow with a shortened delivery window. One requirement changes, four remain unchanged, affected tasks are replanned, and the submission stays blocked until the team resolves the new delivery and certificate issues.

TenderGraph also includes a hash-verified public Chilean evaluation case. It reconstructs the commission's recommendation, compares evaluated scores, explains why other suppliers were not recommended, and links each reviewed claim to exact evidence. It preserves the source limitation that an evaluation recommendation is not proof of a signed contract.

GPT-5.6 can reason, classify, compose, and propose actions. It cannot approve qualification, compliance, consequential claims, or final submission.

How we built it

TenderGraph is a Next.js and TypeScript application built around typed Zod contracts.

The lifecycle engine models opportunities, agent stages, current and superseded sources, requirements, bid tasks, approvals, amendments, compliance blockers, and submission authority.

Each source record includes its procedure, jurisdiction, version, current status, and content hash. Requirements remain connected to the exact evidence used to establish their current value. Bid tasks reference both requirements and upstream dependencies.

Six lifecycle gates run in application code:

  • current source validation;
  • requirement-to-evidence binding;
  • complete requirement classification;
  • valid task dependencies;
  • complete amendment-impact coverage;
  • human-only submission authority.

These gates prevent an agent from working from an obsolete document, inventing a requirement, omitting part of an amendment's impact, starting blocked tasks, or approving its own submission.

The deeper evidence harness supports PDF, DOCX, HTML, JSON, CSV, Markdown, and plain text. It converts documents into hashed, addressable evidence records without granting them authority merely because they were ingested.

Codex invokes GPT-5.6 Terra to compose answers from selected claims and evidence. Fifteen additional runtime gates reject altered claim text, evidence swaps, omissions, duplicated claims, invalid sources, scope contamination, provenance failures, internal leakage, incomplete traces, and latency violations.

For evidence changes, GPT-5.6/Codex evaluates the complete active-claim set. Six impact gates validate scope, evidence identity, partition completeness, action semantics, and the rule that model proposals remain subject to human review.

This work applies a central lesson from From Prompts to Contracts: guarantees that matter should be enforced by application code rather than left as instructions inside a prompt.

Codex was also our development collaborator. It helped us:

  • translate the research architecture into procurement contracts;
  • implement the lifecycle engine and chat-first workspace;
  • build the evidence harness and validation gates;
  • generate adversarial tests;
  • verify the public Chilean case;
  • diagnose serverless deployment failures;
  • run browser, responsive, and production checks;
  • review the submission media and documentation.

The product and governance decisions remained ours: the bidder-team audience, the seven-stage lifecycle, the public-versus-synthetic evidence boundary, mandatory approval for consequential actions, and permanent human authority over bid submission.

The analysis workflow is also packaged as a Codex plugin and $tendergraph-analyze skill. The authenticated local runtime uses a ChatGPT-authenticated Codex session and does not require a separate OpenAI API key.

Challenges we ran into

The first challenge was expanding from document analysis into a coherent operational workflow.

A useful tender agent cannot simply summarize an opportunity. It must know whether the opportunity fits the company, which documents are current, what work is blocked, which requirements changed, and whether the organization has approved the next action.

We therefore modeled the lifecycle as connected stages rather than a set of unrelated AI features. Qualification approval unlocks preparation. Requirements drive tasks. Task dependencies drive readiness. Compliance blocks submission. Amendments can reopen earlier work.

The second challenge was that schema-valid output was not authority-valid.

A model can return valid JSON while changing claim text, citing evidence from the wrong source, omitting an affected requirement, duplicating a classification, or proposing an action it is not authorized to perform. We validate semantic identity, provenance, completeness, scope, and authority in code.

We also needed to demonstrate an end-to-end bidding workflow without presenting fictional opportunities as live procurement records. The active-bid inbox is therefore clearly labeled as a reproducible synthetic benchmark. The public Chilean evaluation remains separate and hash-verified.

Deployment exposed failures that local tests missed in PDF rendering, worker packaging, and serverless storage. We added the required canvas polyfills, output-file tracing, and request-scoped temporary storage, then reran the real ingestion and impact workflows against production.

Finally, Vercel cannot inherit a developer's ChatGPT-authenticated Codex session. The hosted application uses a validated deterministic fallback when Codex is unavailable, while authenticated GPT-5.6 runs execute locally or through the plugin.

Accomplishments that we're proud of

  • A working seven-stage tender lifecycle covering discovery, qualification, requirements, bid preparation, compliance, monitoring, and outcome learning.
  • Three ranked opportunities with fit scores, blockers, and select, review, or pass recommendations.
  • Human qualification approval that unlocks the bid plan.
  • Versioned requirements linked to current source evidence.
  • Dependency-aware tasks with named human owners.
  • Compliance that remains blocked while gaps are unresolved.
  • Amendment analysis across the complete requirement set.
  • Permanent human-only authority over final submission.
  • Six lifecycle gates enforced in application code.
  • A clearly labeled synthetic active-bid benchmark and a separate hash-verified public Chilean case.
  • All 49 unit and adversarial tests passing.
  • All 23 deterministic contract scenarios passing.
  • In a controlled enforcement ablation, the full harness admitted 0 of 8 injected faults while schema-only admission accepted all 8.
  • Live Codex composition and impact runs with retained Session IDs.
  • Exact agreement on the corrective impact benchmark.
  • Production PDF ingestion with stable, addressable evidence anchors.
  • Desktop and mobile verification with no console errors.
  • A public Apache-2.0 repository with reproducible setup, a reusable Codex plugin and skill, dated Build Week history, and a hash-verified submission package.

What we learned

The most important lesson was that agentic work requires both autonomy and authority boundaries.

Agents can discover opportunities, calculate fit, organize requirements, generate work plans, monitor amendments, and propose updates. They should not silently allocate company resources, approve unresolved compliance, or release a legally consequential submission.

We also learned that procurement automation must preserve the connection between operational work and evidence. A task is not trustworthy because an agent created it. It is trustworthy when it can be traced to a current requirement, a valid source, and an approved decision.

Amendment monitoring also requires checking the full requirement set. Identifying what changed is only half of the task. Teams need to know which requirements were checked and remain valid.

Finally, production probes became part of the reasoning harness. Passing unit tests did not establish that document workers, native dependencies, temporary storage, or responsive interfaces would survive the deployed environment.

What's next for TenderGraph

The next steps are licensed live procurement connectors, OCR for scanned documents, durable hosted workspaces and review history, organization-level access controls, jurisdiction-specific policy packs, and secure integrations with document and bid-submission systems.

The current release demonstrates the full operational lifecycle through a reproducible synthetic active-bid benchmark. It does not claim universal live-source discovery or autonomous submission.

From this foundation, TenderGraph can expand into continuous opportunity monitoring, company-specific qualification policies, assisted bid drafting, reusable compliance libraries, pricing workflows, portfolio intelligence, and private RFPs.

The long-term product is an increasingly autonomous tender operation in which agents handle discovery, analysis, preparation, monitoring, and learning, while consequential commercial and legal authority remains with the organization.

The moat is the customer's accumulated decision graph: every opportunity, source, requirement, task dependency, amendment, reviewed claim, approval, and outcome preserved over time.

Built With

Share this project:

Updates

Submission history