How Trinta Monitors Hundreds of Sources Every Day: Inside the Architecture

A bid manager exporting equipment across West Africa, the Gulf, and Latin America has, on paper, one job: never miss a relevant tender. In practice that job is close to impossible by hand. The notices live across more than 380 different places: the EU's TED, Brazil's PNCP, Colombia's SECOP, Paraguay's DNCP, the World Bank and UNGM, plus dozens of national e-procurement portals, central medical stores (NUPCO, KEMSA, CENAME, SALAMA), social-security hospital networks (IMSS, EsSalud, CCSS), and one-off referral hospitals that publish a single PDF and move on. Each one uses a different language, layout, deadline format, and login policy. Checking even thirty of them every morning is a full-time role, and the one you skip on Tuesday is the one that closed on Friday.

That monitoring problem is exactly what Trinta's architecture exists to solve. Here is how it actually works under the hood.

More than 750 hand-written connectors, not one magic scraper

The tempting shortcut, when you need to read hundreds of sources, is to build one clever universal scraper and point it everywhere. We tried that approach and deliberately threw it away. Every portal has its own quirks: pagination schemes, anti-forgery (CSRF) handshakes, open-contracting (OCDS) bulk files delivered as monthly ZIP archives, two-step guest sessions that hand you a visitor cookie before they show you anything. A single generic engine handles all of these badly.

So Trinta runs on hand-written, deterministic connectors: one small, purpose-built component per source, each tuned to that portal's real behaviour. The fleet grew from around 15 connectors to more than 750, and counting. A connector for a structured API like TED or PNCP is simple. A connector for a portal that shows a "Log In" button but quietly serves its tender list from a public, no-auth endpoint takes detective work: we render the page once, watch which API call actually returns the data, then call that endpoint directly. That technique alone unlocked dozens of portals that looked walled from the outside.

A few principles keep the fleet honest:

A scheduled scan that runs without anyone watching

Connectors are useless if a human has to press start. The whole pipeline runs on a scheduled cloud job (a daily cron on GitHub Actions) that needs no laptop open and no person awake. Every run does the same disciplined sequence:

1. Harvest. All connectors run in parallel, with a hard per-source timeout so that one slow or broken portal can never stall or fail the entire scan. 2. Ingest and triage. New notices are merged into the store, expired ones are dropped, and obvious noise is filtered out. 3. Enrich, audit, publish. Documents are pulled, each tender is reviewed, and the results are deployed to the live feed.

Two filters do heavy lifting during harvest. A relevance gate matches each notice against a multilingual keyword profile (English, French, Spanish, Portuguese, Arabic, Hebrew), so a Turkish or Brazilian notice is judged on its own language, not a rough translation. And a scope filter drops things that look right but are not: for a buyer of systems, a pure consumable-resupply or equipment-rental notice is out, and the filter knows the rental vocabulary in five languages so "locacao", "alquiler", and "location" all trip it.

Document enrichment: the file list, not just the link

Finding a tender is half the work. The other half is reading it, and that is where teams lose hours: opening the portal, hunting for the dossier, downloading each annex. Trinta's document-enrichment layer does that automatically. A dispatcher routes each notice to the right extractor:

This step is fully deterministic and needs no AI model, so it runs cheaply on every scan. The outcome is that a tender often arrives with its dossier link and a list of annexes already attached, so the bid team starts reading instead of searching.

An audit agent that scores every tender, and fails loud

The last stage is the one most monitoring tools skip. After harvest and enrichment, an audit agent reviews each tender that has not yet been reviewed. It opens the reachable documents, reads the scope, maps the requirements to what the client actually supplies, and assigns a fit score with a short rationale. That score, not a crude keyword count, is what drives the ranking in the feed, so a high-scoring lead is one a person already vetted the requirements against.

There is a deliberate safety rule baked into the code, not just the documentation: every tender must be audited before it ships. If the audit step cannot run (for example, a missing API key) or audits nothing, the entire scan fails loudly and stops. Nothing un-reviewed reaches the live feed. We would rather show no update than a wrong one.

No fake data, ever

Underneath all of this is one rule that shapes every design choice: we never fabricate data to fill a gap. If a value is not public, and procurement values genuinely are sealed surprisingly often (Brazilian budgets under certain laws, German works notices, Gulf board figures behind a login), the feed shows "Not disclosed" with the reason, never an invented number. A bid-document fee is not the contract value, and we never let one masquerade as the other. Stale notices are pruned on a recency window. Award and result notices, which have no real deadline, are filtered out so they cannot appear as live opportunities.

The payoff for the SME owner, exporter, or consultant is simple. Instead of patrolling 1,539 portals and trusting that you covered them, you open one daily feed of matched tenders, already scored for fit, already carrying their documents, already cleaned of noise and resupply contracts and expired notices. The monitoring problem does not disappear; it just stops being yours. That is the entire point of a scored, matched daily feed: the hundreds of sources keep changing every night, and you only ever see the handful that matter to you.

Frequently asked questions

Share this article

Reference

Related articles