Any source URLs associated with excluded tenders are permanently skipped during automated and manual discovery. To restore a tender and allow it to be re-discovered, click Remove Exclusion on the card below.
Priority Score (0 – 10)
The Priority Score is a weighted blend of seven AI-assessed business dimensions plus a recency factor — eight components in total. It answers one question: how commercially attractive is this opportunity for Goodfellow? A score of 7 or above places the tender in Top Scorers for human review. Scores below 4 typically indicate a poor fit — commodity requirements, unsuitable buyers, or requirements outside Goodfellow's catalogue.
| Dimension | Weight | What it measures | High score means… |
|---|---|---|---|
| Material Fit | +22% | How closely the required materials align with Goodfellow's core catalogue — refractory metals, precious metals, custom alloys, foils, wires, powders and sputtering targets. | The specification is a direct match for Goodfellow's specialities (e.g. tungsten foil, platinum wire, molybdenum sputtering target). |
| Specialist Supply | +18% | How specialised or technically demanding the supply requirement appears — custom grades, tight tolerances, unusual specifications, or materials that most distributors do not carry. | The requirement is clearly beyond a standard catalogue order and favours a supplier with deep materials knowledge. |
| Buyer Fit | +17% | How likely the buying organisation is to value specialist capability over lowest price. Research institutes, national laboratories, fusion and nuclear programmes score highest; general government procurement scores lower. | The buyer is a national lab, space agency, fusion programme or advanced-manufacturing facility with a track record of specialist procurement. |
| Commodity Risk | −13% | The risk that this tender will be decided on price alone — bulk volumes, standard grades, or requirements that any metals distributor could fulfil without specialist knowledge. | The tender is commodity-dominated (e.g. bulk structural steel at a fixed price). A high score here reduces the Priority Score. |
| Reissued Signal | +8% | Evidence that the buyer has previously attempted to source this requirement and struggled — prior cancellations, reissued notices, or explicit statements about sourcing difficulty. | A prior procurement attempt failed or was withdrawn, strongly suggesting the buyer needs a specialist supplier. |
| Quantity Fit | +4% | Whether the quantities required are commercially realistic for a specialist supplier. Very large volumes may favour commodity distributors; very small one-off quantities may not justify the commercial effort. | Quantities are in the small-to-medium specialist range — large enough to be worthwhile, small enough that a specialist has a competitive advantage. |
| Strategic Relevance | +4% | Any other strategic reason the opportunity is worth pursuing — new market entry, a target account, a high-profile programme, or a relationship Goodfellow is actively developing. | The opportunity opens doors in a priority programme (e.g. ITER, STEP, Artemis) or with a strategically important buyer. |
| Recency | +14% | How recently the tender was published, on a steep curve: within 7 days scores 10, ~30 days 7.5, ~90 days 4.5, and over a year effectively 0. Unlike the other dimensions this is calculated automatically from the publish date, not assessed by the AI. A missing publish date is treated as neutral (5). | The tender is fresh and currently live, so it ranks above older notices covering a similar requirement. |
Supporting Indicators
One further indicator is shown on each tender card but does not feed into the Priority Score. It provides context to help you triage quickly.
Scores whether there is enough time remaining to prepare and submit a response. A tender closing in under seven days scores 2; one closing in 30–90 days scores 9. Already-closed tenders score 0 and are surfaced for intelligence purposes only.
Score Bands at a Glance
How AI Assessment Works
Each tender is assessed by a large language model (Claude) trained to understand materials procurement. The model reads the full tender text and scores each of the seven business dimensions independently, providing a written rationale for each score. The eighth component, recency, is calculated automatically from the publish date rather than assessed by the model. All rationales are visible on the individual tender detail page. The scoring is transparent and auditable — you can always read exactly why a tender received its score and override the system's recommendation using the review controls (Pursue, Review Later, Rejected, Irrelevant).
Seeds & Configuration
Before any searches run, the engine loads seeds.json — a curated configuration file that defines what to look for and where. This file contains four key datasets that drive the entire discovery run:
- Material keywords — specific terms like tungsten foil, molybdenum sputtering target, platinum wire that anchor every search.
- Known platforms — the 10 monitored procurement portals and email alert sources (CERN, ITER, ESA, TED, Find a Tender, etc.) with their domains and alert patterns.
- Seed organisations — a watchlist of high-fit buyers like CERN, ESO, ITER, and Diamond Light Source that are searched directly.
- Search query templates — hand-crafted query strings tuned for advanced-materials procurement.
No AI calls are made at this stage. The configuration is deterministic and can be updated via the Configuration page in the sidebar.
Query Generation
The engine builds a ranked list of search queries from the seeds configuration. Queries are grouped into four modes, each targeting a different segment of the tender landscape:
The total query list is capped at a configurable maximum (default: 20 queries per run) to control cost and runtime. No AI calls are made at this stage.
Semantic Search
Each query is sent to the Exa neural search API — a semantic search engine purpose-built for retrieving structured web content. Unlike keyword search, Exa understands meaning, so a query for "specialist refractory metals procurement" surfaces results about tungsten and molybdenum tenders even if those exact words don't appear in the query.
For each query, Exa returns up to 5–8 results containing the page URL, title, publication date, a relevance score, and a content excerpt. The engine uses Exa's neural search mode with autoprompting — Exa may reformulate the query slightly to improve recall.
Searches are constrained to a recency window: a startPublishedDate is passed so Exa only returns tenders published within roughly the last nine months (configurable — default 270 days). Any stale results that slip through are dropped by a secondary date check before they reach Claude, so old or already-awarded notices stay out of the pipeline.
{"query": "CERN procurement tender specialist materials", "numResults": 8, "type": "neural", "useAutoprompt": true, "startPublishedDate": "2026-01-09T00:00:00.000Z", "contents": {"text": {"maxCharacters": 2000}}}
The Exa API key is stored securely in OpenBao and retrieved at service startup via AppRole authentication — it is never stored in plaintext. A fallback web search provider is available if Exa is unavailable.
Full-Page Fetch
If the excerpt returned in Step 3 is shorter than 500 characters — too brief for Claude to extract meaningful data — or the result arrived without a publication date, the engine calls the Exa Contents API to retrieve the full text of the page. (The publication date and tender status usually sit deeper in the notice body than the search excerpt captures, so a missing date is itself a reason to pull the full page.)
{"ids": ["https://procurement.cern.ch/tender/12345"], "text": {"maxCharacters": 9000}}
This gives the normalisation step (Step 6) substantially more signal to work with — specifications, quantities, deadlines and buyer details are far more likely to be present in the full page text than in a short snippet. The full text is passed on to Claude; pages with less than 50 characters of usable content after this step are skipped entirely.
Deduplication
Before calling Claude — which costs tokens — the engine runs two fast database checks to avoid processing anything already in the system:
- URL deduplication — if the source URL already exists in
tender_sources, the result is skipped immediately. This is the cheapest check and catches the majority of duplicates. - Content hash deduplication — after normalisation (Step 6), a 16-character SHA-256 hash of
title + buyer_org + reference_idis compared against all stored tenders. This catches the same tender discovered from two different URLs or re-published under a slightly different web address.
Both checks happen before any AI calls, keeping costs down. A tender that passes both checks is considered genuinely new and proceeds through the pipeline. Results that fail deduplication are silently skipped and do not appear in the run log.
AI Normalisation
The raw page text (title, URL, date, and full content) is sent to Claude Sonnet with a structured extraction prompt. Claude reads the text and returns a clean JSON object representing the tender. This is the first of two Claude calls per new tender.
Claude extracts the following fields:
- Title — a concise, standardised tender title
- Reference ID — the buyer's internal contract or tender number
- Buyer organisation & type — who is buying, and which category (national lab, defence, space agency, university, etc.)
- Country & region — ISO country code and geographic region
- Publication date & deadline — extracted and normalised to YYYY-MM-DD
- Summary — a 2–3 sentence factual summary of what is being procured
- Materials list — specific materials mentioned (e.g. ["tungsten foil", "molybdenum wire"])
- Procurement category — a brief classification (e.g. Refractory metals)
- Confidence — high / medium / low, reflecting how complete the source text was
Up to 9,000 characters of source text are passed per call. The model is claude-sonnet-4-6.
Once the fields are extracted, automated discovery applies a set of hygiene filters using the values Claude just read, so settled or stale opportunities never enter the pipeline:
- Settled notices — anything whose status is awarded, cancelled or closed is dropped.
- Stale publication date — tenders published before the recency window are dropped. This catches results Exa returned without a date (so they couldn't be filtered at search time) but which prove old once normalised.
- Lapsed deadline — tenders whose response deadline is already more than six weeks in the past are dropped as closed and no longer actionable (configurable; default 42 days). Tenders with no extracted deadline are kept.
These guards apply to automated discovery only — tenders ingested from known portals and email alerts are never filtered out.
AI Scoring
Once normalised, the structured tender data is sent to Claude Sonnet a second time with a specialist scoring prompt. Claude scores the tender against seven business dimensions that reflect Goodfellow's commercial proposition. This is the second of two Claude calls per new tender.
Each dimension is scored 0–10 with a written rationale:
- Material Fit (×0.22) — how closely the requirement matches Goodfellow's catalogue
- Specialist Supply (×0.18) — how technically demanding the supply requirement is
- Buyer Fit (×0.17) — likelihood the buyer values specialist capability over lowest price
- Commodity Risk (×−0.13) — risk the procurement is price-dominated (penalises the score)
- Reissued Signal (×0.08) — evidence of prior procurement failure or reissue
- Quantity Fit (×0.04) — whether quantities suit a specialist supplier
- Strategic Relevance (×0.04) — any other strategic reason to pursue
Claude scores only these seven dimensions; an eighth factor, recency, is added by the system in the next step (it is derived from the publish date, not assessed by the model). All seven rationales are stored and visible on the individual tender detail page — every score is fully auditable. See How Scoring Works in the sidebar for the full methodology.
Priority Score Calculation
The seven AI scores — together with a recency factor derived from the publish date — are combined by a deterministic weighted formula into a single Priority Score between 0 and 10. No AI is involved in this step; the formula is fixed and transparent:
material_fit × 0.22 +
specialist_supply × 0.18 +
buyer_fit × 0.17 −
commodity_risk × 0.13 +
reissued_signal × 0.08 +
quantity_fit × 0.04 +
strategic_relevance × 0.04 +
recency × 0.14
) normalised to 0–10
The recency factor scores how recently the tender was published on a steep curve (10 = within 7 days, ~4.5 at 90 days, ~0 beyond a year; a missing date is treated as neutral). This gives fresher tenders a meaningful lift so current opportunities rank above stale ones. One further indicator is computed at this stage but does not affect the Priority Score:
- Deadline Viability — based on days remaining to respond (0 = already closed, 9 = 30–90 days remaining)
Tenders scoring 7 or above appear automatically in Top Scorers.
Saved to Database
The tender, its source record, and all scores are written to the PostgreSQL database in a single atomic transaction. If any part fails — the tender record, the source record, or the scores — the entire insertion is rolled back, preventing partial data.
Three records are created per new tender:
- tenders — the normalised tender with all extracted fields, priority score, and the original source text (up to 50,000 characters)
- tender_sources — the URL, source name, and provider that found it (used for deduplication and for generating the Description pre-fill in Salesforce opportunity creation)
- tender_scores — all seven AI dimension scores plus the recency and deadline-viability values, with per-dimension rationale text
The tender is now visible across the app — in All Tenders, Top Scorers if it scores ≥ 7, and in the discovery run log. The opportunity cache is invalidated so the Salesforce integration picks up any new tenders immediately.