A capability profile is a node: matching in production, the procurement graph still in progress

One gap, two systems, and only one of them shipped#

We want to state the boundary before anything else, because it is the most useful thing on this page. Capability matching is in production: a customer can build a profile of what a firm can deliver and see notices scored against it, with reasons. The procurement graph, which links buyers, suppliers, awards and classification codes across sources, is active work. It is not shipped, it is not part of what Klarum offers today, and nothing below describes a feature a customer can use.

We write the two together because they are one argument. A capability profile is a node in a graph: it is the supplier side of the market, described from the firm's own records. A match score is an edge weight: a judgement of how strongly a notice connects to that node. For the edge to exist at all, the notice and the profile have to be described in terms that can meet, and that is a classification problem. The shipped half solves it for one firm at a time. The unshipped half tries to solve it for a whole market.

The line between them is this: a procurement vocabulary says what is being bought and never who can deliver it, so a capability profile is the missing node that gives every score an edge to land on, and the graph is what we are still building around it.

Why keyword alerts fail#

A keyword alert asks whether a notice contains certain words. Public procurement is written in broad language, so a firm that sets an alert for a topic receives every notice that touches it, whether or not the firm could ever deliver the work. The team learns to skim, then to ignore, and the notice that mattered sits unread in the same list as the rest.

The deeper problem is that the alert knows nothing about the firm. Even the classification a notice carries, the Common Procurement Vocabulary code^[1], describes the thing being bought. It has no field for the people who could supply it. The alert cannot tell a notice the firm has won before from one it has never touched, or one that needs a certification the firm does not hold. That is the same gap that makes the graph hard, seen from the bid manager's desk.

Method#

What is in production: a profile, a score, a reason#

We model what a firm can deliver from its own documents and its own win history, rather than from a list of keywords someone typed once. Past proposals, reference projects, CVs and the record of bids won and lost all say something about capability, and they say it more honestly than a marketing page does.

Notices are then scored against that profile, and each score carries its reasons. The method is set out in full in our article on match scores and we do not repeat it here. What matters for this piece is the effect: the reason is shown, so a bid manager can read why a notice ranked where it did and disagree with it. The profile keeps improving as the firm adds documents and records outcomes, so the filter follows the firm rather than freezing at whatever a team once configured.

What is not shipped: relationships across the market#

A single tender notice tells a bid team very little. The team also wants to know who this buyer has bought from before, which suppliers keep winning under this kind of work, and whether a newcomer has ever taken an award here. None of those answers lives in one record. They live in the links between records: a buyer to its notices, a notice to its award, an award to a supplier, and every notice to a code that says what is being bought. That is a graph.

We are building it from published notices and awards across several national and supranational sources. Buyers, suppliers, notices and awards are the nodes, and edges record who issued and who was awarded. The hope is that the shape of past awards carries a usable signal about future ones, for example that a buyer favours incumbents, splits work into lots that suit small firms, or reuses a narrow set of suppliers. A firm profile is simply the node we already know how to describe well, because the firm hands us its own records.

The profile as an object in the graph#

Calling a profile a node is more than a figure of speech, and it is worth saying what follows from it. A node in a graph is defined by its identity and by its edges, and a capability profile has both. Its identity is the firm: one legal entity, however many names, offices and registration schemes it appears under. Its edges are the relationships the firm's own records assert. A reference project is an edge to a past buyer. A CV is an edge to a person and to the kind of work that person has done. A bid won or lost is an edge to a notice, and the outcome is the weight on it. A certification is an edge to a requirement a notice can impose.

Seen this way, a match score is a path question. A notice arrives with its own edges: a buyer, a code saying what is wanted, a list of requirements. The score asks how many of the notice's edges land on edges the profile already holds, and how strongly. The reasons we show are those paths, written out in words. A reason such as "the firm has delivered work for this kind of buyer" is a path from the profile to the notice's buyer through a reference project, and a reason such as "the notice requires a certification the firm lacks" is a missing edge. This is why showing reasons costs nothing extra: the reason is the structure that produced the score, not a story told afterwards.

Identity is where the two subjects meet most plainly. Resolving a supplier across sources, so that one firm is one node, is the same problem as resolving a firm's own material into one coherent profile. A firm describes the same reference project in a proposal, in a CV and in a tender response, each time with different wording, a different client name spelling and a different emphasis. If the profile counts those as three projects it overstates the firm's experience, and if it fails to link a project to the buyer it was delivered for, it hides an edge that would have made a notice from that buyer a strong match. Merging wrongly invents experience; failing to merge hides it. The error modes are exactly those of merging buyers and suppliers across national registers, only at the scale of one firm instead of a market.

There is a practical consequence for how we work. The firm is the best available authority on its own identity, because it can look at the profile and say that two entries are one project or that one entry is wrongly merged. The market-wide graph has no such authority to ask. Every merge there is an inference from names, addresses and registration numbers, and every inference can be wrong without anyone noticing. We expect what we learn from correcting a single firm's profile, where the answer can be checked, to inform how cautious the larger resolution has to be, but we have not yet tested that expectation.

Where the same gap reappears: bridging classification systems#

Sources describe what is bought using different classification systems. CPV is the common vocabulary on European notices^[1]. The sector codelist used for development aid reporting^[2] is a different vocabulary again, and the Danish national scheme has its own structure too. They were designed for different purposes by different bodies, and they do not nest neatly: one code in one system can correspond to part of several codes in another, and sometimes to none.

A naive bridge is a lookup table. It looks tidy and it quietly lies, because a many-to-many relationship forced into a one-to-one mapping drops the cases that do not fit. We are instead treating each mapping as a weighted edge between codes, learned from notices that carry both, and keeping the weight visible so a downstream question can ask how sure the bridge is. This is the same move a match score makes: an honest weight on an edge, with the reason attached, rather than a yes or no.

Before any of that, the first obstacle is identity. The same supplier appears under different spellings, legal forms and registration schemes, and the same buyer appears as a parent body in one source and a department in another. Merging two nodes wrongly invents a relationship; failing to merge them hides one. We treat entity resolution as the foundation, because every later claim inherits its errors.

A specialist supplier, followed through both systems#

The clearest way to see why the two halves are one argument is to follow a single firm. Take a small consultancy that does one narrow thing very well, say a specialised assessment service for a particular kind of public facility. The work is real, the references are strong, and the firm has won the few contracts of this kind that have come up. It is the sort of supplier a buyer would be glad to find.

Now look at how the market files that work. The classification on a notice^[1] has to pick from a fixed list of categories, and a narrow service rarely has a category of its own. Buyers choose the nearest one, so the notices that the consultancy should see are scattered across neighbouring categories, some of them broad consulting headings shared with hundreds of unrelated services. The same work, described for development aid reporting under the sector codelist^[2], would land somewhere else again. The vocabulary describes the purchase coarsely and describes it differently depending on who is filing.

Capability matching handles this firm well, and the reason is that it never relies on the shared code. The profile is built from the firm's own proposals, references and outcomes, so it knows what the consultancy actually does in the firm's own words. A notice for exactly that work scores high even when it is filed under a broad heading, because the match runs through the text of the requirements and the history of similar wins, not through the category. A keyword alert fails the firm in the opposite way: it either watches the broad heading and drowns the team, or watches a narrow phrase and misses every notice that words the need differently.

The graph, were it built the obvious way, would fail this firm quietly. If the graph routes by category, it files the consultancy under the neighbour category, treats it as one of the many broad consultancies there, and shows it to the buyers who buy broadly rather than the buyers who need its specialism. The same chain runs in reverse for those buyers: a buyer with exactly this need sees a list of generic suppliers and never the one that fits. Nothing in the graph is wrong in the sense of a false fact. Every edge is a true statement about a category. The error is that the category stands in for a capability it cannot express.

That is the causal chain that runs across both subjects. A distinctive offer is poorly served by the classification, so a profile that bypasses the classification scores it correctly, and a graph that depends on the classification routes it wrongly. The profile is therefore not only the shipped product and a node in the unshipped graph. It is also the evidence the graph needs to correct its own bridge: where a firm's profile and the category it is filed under disagree, the disagreement is a signal that the bridge is lossy at that point. We would like the graph to use that signal. We have not built that, and we do not know how large the effect is.

Discussion#

Limitations#

A profile is only as good as the material behind it. A young firm with little win history, or one whose documents are thin or out of date, gets a weaker profile and weaker matches. A score is a ranking aid, not a verdict: it tells a bid manager where to look first, and it will sometimes rank a notice too high or too low. We have not measured how often a bid team would have chosen differently.

The graph carries larger unknowns. We have not shown that it predicts who wins, and we are not entitled to claim it. Award data is public but incomplete: in some sources only winners are published, so the graph sees outcomes far better than it sees competition, and a model trained on winners alone will learn to describe incumbency, which is not the same as predicting a contest. Coverage is also uneven. A supplier in a thinly published region looks inactive when it may only look unobserved, and we have no reliable way yet to tell those apart.

Bridging introduces its own error, and it is not distributed evenly. The codes that map cleanly are usually the common, well-understood categories. The ones that map badly are specialist work, which is exactly where a small expert supplier lives. A poor bridge hurts the firms with the most distinctive offer: they are filed under a neighbour category, shown to the wrong buyers, and missed by the right ones. The profile does not have this weakness, because it describes the firm directly instead of through a shared code, which is one reason the shipped half could be built first.

The incumbency trap, applied to matching#

We said that a model trained on winners alone learns to describe incumbency. The same trap applies to scoring, and it is the strongest limitation in this piece, because it touches the half that is in production. Win history is one of the things a profile is built from. History is evidence of capability, but it is also evidence of having been given the chance. A firm that has won often has, by construction, more edges to match against. A firm that has not won has fewer, and the score cannot tell the difference between a firm that could not deliver and a firm that was never allowed to try.

Consider a newcomer with strong people and little record. If the only evidence the system can lean on is who has won before, the newcomer's score is low for every notice, and the reasons will say, truthfully, that the firm has no matching history. The score is accurate about the evidence and wrong about the firm. The effect compounds: a low score leads the team to pursue fewer notices, fewer pursuits produce fewer wins, and the thin record stays thin. A ranking that was meant to widen the field would then harden it, and it would do so in a way that reads as objectivity.

We think the honest response has three parts, and only the first is something we can state as current practice. The reasons are shown, so a newcomer can see that a low score reflects missing history and not a poor fit, and can choose to pursue anyway. Documents carry weight alongside outcomes, so a firm can bring evidence of capability that does not depend on having won. And the score is a ranking aid for where to look first, never a verdict on whether to bid. What we have not done is measure how strongly the incumbency effect shapes real rankings, and we would not describe the problem as solved. A graph built on awards would make the trap deeper, not shallower, since award data is the purest form of who has won before. That is a further reason to keep the graph out of the product until we can show it does not simply automate the advantage of the firms already winning.

Who is affected#

Bid managers gain the most from matching today, because the decision of what to pursue is theirs and the first pass is where hours disappear. Directors gain a defensible answer to why the firm chased one notice and passed on another, and business development staff gain a shared basis for the go or no-go conversation, since the reasons are on the page rather than in one person's head.

If the graph is ever built badly, three groups carry the cost. Small suppliers are misfiled and never surface. Bid teams waste effort on opportunities wrongly rated as a fit, or skip ones wrongly rated as a miss. Buyers are the quiet third: if a graph overstates how closed a market is, suppliers stop bidding, and the market becomes as closed as the graph said it was.

Next steps#

For matching, we would make it easier for a firm to correct its own profile when it disagrees. A reason that is visibly wrong is the fastest way to find a gap in the underlying documents, and the correction should flow back into the next ranking. For the graph, we want to measure the bridge before we trust it, by checking mappings against notices that carry both classifications and against review by people who know the sectors. We also want a principled way to represent unobserved competition so that thin coverage reads as unknown rather than as empty. We are not committing to an outcome or a timetable for the graph.

Conclusion#

Capability matching swaps an alert that is cheap to set up and expensive to read for a profile that takes real material to build and is cheap to read. The exchange favours firms with a record to draw on; for everyone else it is a better ranking than keywords, with reasons you can check, and not a replacement for judgement. The procurement graph is a sound idea and an unfinished piece of work. Its value depends on two things we have not yet earned: resolving identities well enough to trust the nodes, and bridging classification systems without erasing the specialists. We would rather describe that honestly than present a result we do not have. Read the first half as a description of what Klarum does, and the second as a statement of a problem and how we are approaching it.