How it works
How Sinal connects the pieces
Four steps. Nothing happens that you cannot inspect afterwards.
- 01
We collect
Every day we gather public tenders and contract awards from TED, BASE.gov.pt, PLACSP and the other sources on the coverage page, and keep the original record.
The notice is kept as published, so anything we show can be checked against it.
- 02
We organise
Each notice is put in the same shape: who is buying, what they want, the CPV code, the value, the deadline — and who won, once it has been awarded.
The link to the original page stays attached to every record.
- 03
You narrow it down
Filter by what you sell, where, the buyer, the value and the deadline, and see only the tenders that could be yours.
The filters live in the address bar: save the view, come back to it, or send it to a colleague.
- 04
You decide
See which authorities buy what you sell, who keeps winning, and which contracts are about to expire — before you spend a week on a bid.
Every result links to the original record on the official platform.
The chain, end to end
Four steps you can see. Underneath them, one pipeline turns what nine platforms publish into a brief one company can act on.
- Raw feeds
One record per notice or award, kept as published.
- Normalisation
Rows a filter can actually compare.
- Entity resolution
Parties as one identity, with a history.
- Relevance per vendor
What applies to one vendor, and why.
- Delivery
The signal, delivered where it gets read.
A feed vs Sinal
| What | A feed | Sinal |
|---|---|---|
| Buyer and winner names | Whatever string the source published, spelling included. | One identity per buyer and per winner, however the source spelled it. |
| Award history | None — a feed shows the current notice, not what came before it. | Every party's past awards, so an incumbent is a name, not eleven strings. |
| Contract expiry | Not computed. | Shown before the contract comes back to market, wherever the source published enough to know. |
| Sources in one query | One platform at a time, each with its own site and format. | Six corpora across Iberia, Europe, multilateral banks, Brazil, LatAm and Asia, queried together. |
| Fit to what you sell | A keyword alert: it matches the word, whatever it turns out to mean. | A profile of what you actually sell, tuned by you — not a keyword alert. |
| Below-threshold awards | Rarely published where the source doesn't require it. | Surfaced wherever the source does publish them; invisible everywhere else, and we say so. |
| Machine access | HTML, or a source-specific API you learn from scratch. | A metered read API, llms.txt, an api-catalog linkset and WebMCP, all over the same resolved data. |
| Provenance | Varies by source; some link back, most do not. | Every result links to the original record, always. |
What this chain does not do
- Not legal advice. We point at the clause and the source; a lawyer tells you what it means for you.
- Coverage follows what each official source publishes. Below-threshold direct awards are published inconsistently and sometimes late — we surface what is published, not what is withheld.
- Entity resolution can be wrong. When it is, it is visible: every result carries its source record, so a wrong match can be seen and fixed.
- Deterministic. The same input always produces the same output, and every figure on a page traces to a record you can open.
- Contract expiry is a computed estimate, not a guarantee: a contract can be extended, terminated early, or arrive with no duration published at all.
- The multilateral, Brazil, LatAm and Asia corpora are feeds, not briefs — no vendor profiles, no entity resolution, no incumbents reach them yet.
The source trail
A useful signal must remain checkable. Records retain source identifiers, dates and links like these:
TYPE call · CPV 45321000 · buyer Município de BragaVALUE €1.240.000 · deadline 2026-10-09STATUS published · source BASE PTSOURCE placsp/2026/0417 fetched 2026-09-11 06:14 UTC