A code-expansion policy states which levels around an approved seed code a tender search will include. It treats the exact code, selected children, the parent and any neighboring branch as separate query arms. Each arm records the target portal, code-system edition, query expression, tested date window, useful additions, false positives, exclusions, review cost and decision. The resulting parent, child and exclusion table is an executable search rule, not a list of every category with a remote connection to the offer.
An exact classification code often misses buyers who publish at a broader or different level. Expanding to its parent can recover those notices, but may also multiply unrelated results. Selecting every child looks precise while silently omitting notices placed only on the parent. Portals add another complication: one interface may include descendants automatically, while another may match only the value entered. Teams commonly respond by monitoring an entire division and then stop reading the alert because it is too noisy. The alternative failure is a narrow alert that feels efficient because it returns little, even though known relevant notices are absent.
Do not choose breadth from the taxonomy diagram alone. Run exact, child and parent searches separately in the portal that will carry the alert, over the same dates and geography. Judge a sample using a written relevance rule and challenge every arm with known relevant notices. Measure precision directly. Call recall a benchmark estimate unless the complete set of relevant notices is known. Add a broader arm only when its unique useful results justify the extra review time. Pair noisy parents with subject terms, buyer filters or exclusions instead of inheriting the whole branch. An agent may execute searches, deduplicate records and calculate the table, but it must preserve query provenance and surface unreviewed results rather than deciding that a notice is qualified.
Benchmark
Give every code level the same retrieval test
Start after the seed code has been approved for the offer. Code selection asks which category describes the procurement object; expansion asks how much surrounding hierarchy to monitor. Keep those decisions separate. Freeze one portal, one interface or API version, one code-system edition, a closed publication window, geography and notice-type scope. Write a relevance rule that a second reviewer can apply. For example: the notice is relevant when the principal scope includes implementation or operation that the supplier can deliver, in a country served, with no obvious mandatory condition that makes the opportunity impossible. A code match alone cannot satisfy that rule.
Build a small reference set from official notices already judged relevant and irrelevant. Include awkward cases: a relevant notice coded only at a parent, an irrelevant notice sharing the exact code, a mixed contract and a record found through text rather than classification. This is not a complete truth set. It is a challenge set that reveals obvious blind spots. If the complete number of relevant notices in the portal is unknown, report known-item coverage or benchmark recall, not absolute recall. Precision has a simpler denominator: among the reviewed results returned by an arm, how many met the rule? Record any unjudged tail instead of counting it as irrelevant.
| Field | What to record | Why it matters |
|---|---|---|
| Seed | System, edition, code and official label | Keeps selection fixed |
| Surface | Portal, endpoint or interface version | Makes behavior reproducible |
| Window | Publication dates and geography | Makes arms comparable |
| Scope | Notice types and status | Prevents mixed denominators |
| Relevance | Written include and reject rule | Constrains judgement drift |
| Challenge set | Official notice IDs with prior judgements | Tests known misses |
| Budget | Records or minutes per review cycle | Defines usable breadth |
Experiment
Test exact, child and parent searches independently
Draw only the local branch around the seed: its parent, its children and any sibling supported by real buyer practice. A hierarchy is not permission to search the whole tree. CPV exists to standardise the subject of European public contracts, while UNSPSC explicitly supports moving up and down a five-level hierarchy for more or less analytical detail. Those facts describe the vocabularies, not the behavior of every search form. TED developer documentation also treats CPV as hierarchical, and its published SPARQL example uses a code prefix and SKOS broader relationships to reach subtypes. Your target portal may implement a different query contract, so run a probe and save the result.
Create one arm for the exact seed, one for all approved children, one for the parent, and separate arms for only those siblings that have evidence. Add a text-only control using the offer vocabulary. Then create combined variants for a noisy code and a discriminating subject phrase. Use official notice identifiers to deduplicate before comparing arms. If one notice appears under the parent, a child and a text query, it is one opportunity, not three successes. Preserve which arms found it because that provenance explains whether an expansion contributed anything unique.
- Never infer descendant behavior from the visual code picker.
- Save the literal query, timestamp and result count for every arm.
- Keep supplemental and main classifications distinguishable when the source exposes them.
- Deduplicate by stable official notice identity before scoring.
- Retain a text-only control to expose classification misses.
Decision
Approve an expansion for marginal value, not raw volume
Precision is the share of retrieved records that are relevant. Recall is the share of all relevant records that were retrieved. The second quantity is usually unknowable for an open tender corpus, so use a dated reference set and label the measure honestly. The key expansion number is marginal: how many relevant notices did this arm add that the existing approved arms did not find? Set beside it the unique false positives and review minutes it introduced. A parent returning six useful notices and 240 irrelevant records may be worse operationally than a child returning four useful notices and twelve irrelevant records. The answer depends on the value of a missed opportunity and the team’s actual capacity, not a universal percentage.
Before rejecting a broad parent, test one or two explainable constraints. A subject phrase can isolate the intended service; a buyer or sector filter can contain a branch whose neighboring categories belong elsewhere; an exclusion can remove a repeated contaminant. Inspect every proposed exclusion against mixed contracts. If excluding hardware also hides systems-integration notices that include devices, narrow the negative rule or leave it for human triage. Stop tuning when another filter reduces relevant additions, moves the result beyond the review budget or relies on a distinction the source data does not reliably expose.
| Arm | Evidence to keep | Typical decision |
|---|---|---|
| Exact seed | Relevant, irrelevant and known misses | Keep as baseline |
| Selected children | Unique useful notices and parent-only misses | Keep named children |
| Parent alone | Marginal value and review cost | Reject or condition |
| Parent plus phrase | Recovered value after constraint | Keep with paired filter |
| Credible sibling | Comparable-buyer evidence and unique value | Test or reject |
| Exclusion | Removed noise and any relevant losses | Automate only if safe |
| Text control | Relevant records absent from code arms | Preserve alongside codes |
Operation
Publish a search policy an agent can execute and challenge
Turn the decision table into versioned instructions. For each approved arm publish the code system and edition, hierarchy path, exact query, paired terms, exclusions, portal, geography, notice types, test window, result counts, judgement coverage, marginal useful additions, owner and next review trigger. Record rejected arms too. Without rejection reasons, a future analyst or agent is likely to restore the broad parent and repeat the noise. Separate facts observed from the portal from policy choices made by the team.
An agent may run the approved read-only searches, normalize and deduplicate identifiers, attach source URLs, calculate the recorded measures and flag a drift threshold. It should abstain when the portal changes syntax, the selected code disappears, an exclusion conflicts with a new relevant notice or too much of the result set remains unjudged. The safe next action is to return the affected arm and evidence for review. Expanding discovery never authorizes qualification, outreach, registration or submission. The policy succeeds when a person can understand every included branch and when new evidence can overturn it without reconstructing the experiment.
- Version the code edition and executable query together.
- Expose observed result facts separately from approval decisions.
- Set drift triggers for volume, precision, misses and portal behavior.
- Require review when exclusions or hierarchy semantics change.
- Keep discovery output separate from bid qualification.
What good looks like
Useful outcomes from expand procurement code tender search
- Every expansion decision begins with one approved seed code and one target portal.
- Exact, parent, child and neighboring searches are measured as separate query arms.
- The test uses a fixed date window, geography and written relevance rule.
- Unique relevant additions are distinguished from duplicate volume.
- Precision is reported separately from benchmark coverage and review effort.
- Broad codes carry paired filters and explicit exclusion patterns.
- An agent can reproduce the search and explain why each branch is included or rejected.
Operating model
How to run the work
- 01
Freeze the test conditions
Name the portal, code-system edition, seed code, date window, geography, notice types, relevance rule and maximum number of records the team can review.
- 02
Create independent query arms
Run the exact code, selected children, the parent and credible neighbors separately. Record the literal query and whether the portal expands a level automatically.
- 03
Judge and deduplicate results
Review records against the same rule, preserve their official identifiers and separate unique additions from notices already returned by another arm.
- 04
Price the marginal coverage
For each arm, compare unique relevant additions with unique false positives and estimated weekly review minutes. Test paired terms before accepting a noisy parent.
- 05
Publish a bounded policy
Approve, condition or reject each branch. Include exclusions, stopping rules, owner, review date and the evidence needed to reopen the decision.
Evaluation
Questions that change the decision
- Does the target search interpret a parent as an exact value or include descendants?
- Which known relevant notices does the seed code retrieve and miss?
- Do children add notices that are absent from the exact-code result?
- Does the parent add relevant work or mainly adjacent categories?
- Which text, buyer, geography or notice-type filter rescues a noisy branch?
- How much human review time can the recurring alert consume?
- Which exclusion is stable enough to automate without hiding a valid mixed contract?
- What new evidence will trigger the next expansion review?
Failure modes
Where teams lose control
The portal may already expand a selected level, causing hidden duplication.
A benchmark built only from previous wins may exclude new but relevant work.
A broad parent may look productive because it returns many records, not because it finds useful ones.
A child-only search may miss notices classified at the parent level.
A negative keyword may remove a legitimate mixed or multidisciplinary contract.
Precision calculated before deduplication may unfairly reward repeated notices.
A taxonomy or portal update may invalidate an older expansion rule.
Measurement
Measure the finished job
Measure the completed workflow, including review effort and exceptions. Output volume on its own is not evidence of a better process.
- judged results and relevant results by query arm
- precision after notice-level deduplication
- known relevant notices retrieved by each arm
- unique relevant additions from parent, child and neighbor arms
- unique false positives introduced by each expansion
- estimated reviewer minutes per useful new notice
- weekly alert volume against the approved review budget
- expansion decisions revalidated after code-system or portal changes
Questions
Common questions
Should a tender alert always include the parent code?
No. Test the parent as a separate arm. Keep it only when unique relevant notices justify its false positives and review cost, often with a paired filter.
Does selecting a parent automatically search every child?
Not in every portal or interface. Verify the actual query behavior, save the expression and test it with known child-coded notices.
Can we measure true recall for an open tender search?
Usually not, because the complete set of relevant notices is unknown. Report coverage against a dated, disclosed reference set and state that limitation.
Can an agent tune the code expansion automatically?
It can run bounded experiments and propose changes. A reviewer should approve new branches or exclusions because relevance, missed value and review capacity are business judgements.
Sources
Primary references
- Common Procurement Vocabulary European Commission
- TED Search API Publications Office of the European Union
- TED procurement-object query examples Publications Office of the European Union
- United Nations Standard Products and Services Code United Nations Development Programme
- Evaluation of unranked retrieval sets Stanford University
About the author
Tony Kim
Tony writes about applied AI, dependable product engineering and the systems that turn complex response work into controlled delivery.
Zelius
Managed tender intelligence and bid execution for teams that want the commercial outcome.
Suppliers, founders and commercial teams pursuing public or private opportunities. Start with the workflow, constraints and evidence you already have.
