TenderGuard AI

Inspiration

I have spent over fifteen years managing public infrastructure projects in Colombia. Military academy laboratories, mass transit systems, rural housing, industrial plants. And across all of those years, the problem has always been the same.

A tender document arrives with hundreds of pages. You have to cross-check every requirement against certificates, insurance policies, financial statements, accredited experience, public registries, and a dozen annexes. All of that gets done by hand, in spreadsheets, with PDFs open on three screens and the constant fear that you will miss a qualifying requirement that gets you disqualified.

I have seen well-prepared proposals lose because of an expired document that nobody caught in time. I have seen teams work through the night verifying the same items two or three times because there was no way to tell what was already covered.

TenderGuard AI was born from that frustration. Not from market research or an article about AI. It came from living the problem for years and asking myself whether a tool could help me see, at a glance, what was ready, what was missing, and what needed human review.

What it does

TenderGuard AI takes a tender document in PDF, extracts each requirement individually, preserves the exact page and section where it appears, and cross-references it against the supporting documents uploaded by the user.

The result is a compliance matrix where every requirement is classified as:

Compliant — sufficient evidence exists. Partially compliant — evidence exists but is incomplete or ambiguous. Non-compliant — the document is missing or does not satisfy the requirement. Needs human review — the system does not have enough information to decide and says so instead of making something up.

Each classification shows a confidence level, the supporting evidence, what is missing, suggested corrective actions, and attention priority. Users can filter results and export everything to CSV.

This is not a system that says, "Trust me." It is a system that says, "Here is what I found, here is the source, and here are the parts I could not resolve — you should review them yourself."

How we built it

The backend runs on Python with FastAPI, SQLAlchemy, and Alembic. The frontend uses Next.js, TypeScript, and Tailwind CSS. The demo runs on SQLite, though the repository also includes support for PostgreSQL and Redis/RQ for asynchronous processing.

The complete workflow connects eight steps: creating the tender process, uploading the PDF, extracting and structuring requirements with page and section citations, uploading supporting documents as evidence, cross-referencing each requirement against available evidence, generating the compliance matrix, presenting prioritized corrective actions, and exporting results.

From the beginning I wanted every result to carry context. Not just "compliant" or "non-compliant," but where the requirement came from, which document supports it, and why it might still need a person to review it.

Halfway through the week I faced an uncomfortable decision. I could build the demo with real-time generative extraction, which looks more impressive, or I could build a controlled and reproducible experience. Real-time extraction depends on connectivity, credentials, and API availability, and can produce slightly different results each time. If a judge runs it and something fails because of a timeout, there is no second chance.

I chose to use fictional documents and deterministic evaluation for the final demo. Fifteen requirements, eight supporting documents, a result that anyone can reproduce exactly. Five compliant, four partial, three non-compliant, and three requiring human review. I am not pretending this is ready to certify real tenders. I am showing that the workflow runs end to end, that traceability holds at every step, and that the system knows when it does not know.

I used Codex as my engineering partner throughout the entire build week. I gave it concrete tasks with clear acceptance criteria and verified each result before moving on. It helped me explore the repository when there were too many files to review manually, implement models, endpoints, migrations, tests, and documentation. It was also key for spotting gaps: differences between what the API could already do and what the frontend was not yet showing. Those reviews helped me close holes I probably would have discovered too late working alone.

I used GPT-5.6 primarily for product reasoning and decision-making, while Codex was my main engineering collaborator. It helped me structure the compliance taxonomy, decide when a requirement should escalate to human review, analyze traceability risks, and prepare the demo narrative. When I got lost in technical details, GPT-5.6 helped me come back to the important question: does this serve the user, or does it just seem interesting to me?

The combination worked well. Codex turned decisions into code. GPT-5.6 helped me make better decisions.

Challenges we ran into

The hardest challenge was traceability. Any system can say "compliant." The hard part is making sure every conclusion is connected to a specific requirement, a page in the tender document, a concrete piece of evidence, and an explanation that a person can verify.

Another challenge was uncertainty. In a real tender there are ambiguous requirements, conditions that depend on other documents, imperfect OCR text, and evidence that does not say exactly what you need. Presenting those cases as certainties would be irresponsible. That is why I built in human review states and confidence levels. If the system does not know, it has to say so.

I also had to fight scope. In one week you can build many disconnected things. I chose to build one complete and demonstrable workflow instead of five features that do not connect to each other.

Accomplishments that we're proud of

I finished something that works end to end. It is not a nice screen without a backend, or an endpoint without an interface, or a loose AI response. It is a workflow: create a process, upload documents, review requirements with citations, check evidence, see the matrix, identify corrective actions, filter, and export.

I also prepared automated tests, documentation to run the project, and fictional data that lets anyone repeat the demo without special configuration.

And I recorded a video under three minutes that shows all of this. That was a project in itself.

What we learned

That a compliance tool that does not show its sources and its limits is worthless. In this kind of product, a response that looks smart but cannot be verified is worse than having no response at all.

That Codex works best when you give it context, concrete instructions, and clear criteria to verify the result. Treating it as an engineering assistant with defined tasks worked much better than asking vague things.

And that GPT-5.6 was especially useful for keeping the real problem in sight. It is very easy, when you are deep in the code, to add features because you can, not because the user needs them.

What's next for TenderGuard AI

Connect the workflow to real generative extraction, strengthen OCR processing, and test it with real tender processes that have been properly anonymized.

I also want to add organization accounts, collaborative reviews, approvals, change history, deadline tracking, and configurable compliance policies.

TenderGuard AI does not offer legal advice and does not replace professional review. It is an MVP that shows how AI can help turn scattered documents into a clearer, more traceable, and better organized review process. For someone who has spent fifteen years doing that work by hand, that already means a lot.

Built With

• alembic
• codex
• css
• docker
• fastapi
• gpt-5.6
• next.js
• postgresql
• python
• redis
• rq
• sqlalchemy
• sqlite
• tailwind
• typescript