Announced, Available, Shipped: Verifying What IP Vendors Deliver

Every buyer of intellectual property software in 2026 has heard the same three words used interchangeably. A vendor announces a capability, a vendor makes a capability available, and a vendor ships a capability. In a market moving as quickly as this one, the distinction between those three states is the difference between a purchase that works on the first Monday and a purchase that works, perhaps, next year.

The confusion is not accidental. A roadmap slide is cheap to produce and impossible to falsify. A press release announcing a partnership costs nothing and reads, to a procurement committee under time pressure, exactly like a delivered feature. The incentive runs one way, and no buyer has the time to check every claim against the product itself.

What follows is the test we apply, and the reason we publish the result rather than keeping it as an internal note.

Four positions, and only four

Any vendor claim about a capability sits in one of four positions. The positions are ordered, and the evidence required to occupy each one is different in kind, not merely in degree.

Shipped means the capability exists in the product today and a buyer can verify it without the vendor present: public documentation, a published endpoint, a release note with a date, or a downloadable artefact. The test is simple. Could a prospective buyer confirm this claim on a Sunday evening, alone, without a sales engineer on the call? If the answer is no, the claim is not shipped, whatever the demonstration showed.

Available means the capability exists but reaches the buyer only through the vendor. It covers private betas, capabilities behind a feature flag, and functions that require a professional services engagement to switch on. This is a legitimate position and many good products sit in it. It is not the same as shipped, because the buyer cannot verify it independently and cannot plan around it without a contractual commitment.

Announced means the vendor has stated an intention, with or without a date. It covers roadmap slides, conference keynotes, partnership press releases and the phrase we are working on that. It carries information about direction and none about timing. Treating an announcement as a delivery date is the single most expensive error a buyer makes in this market, because the renewal it justifies is usually three years long.

No public evidence means the claim exists in conversation and nowhere else. This is the position most often mistaken for the others, and it is not an accusation of bad faith. It means only that we looked, in the places a buyer would look, and found nothing a buyer could cite. A vendor can move out of this position in an afternoon by publishing one page.

Why the distinction matters more this year than last

Two changes have made the gap between announcement and delivery unusually wide. The first is the arrival of model-context protocols as a serious architectural question. A vendor that supports an open protocol is genuinely easier to replace, which is precisely why announcements outnumber implementations. The second is the pace of the AI product cycle, which has trained buyers to expect that anything announced will exist shortly. In enterprise intellectual property software, where a release cycle is measured in quarters and a validation cycle in months, that expectation is simply wrong.

The consequence lands on renewal. A department that renews a five-year platform contract on the strength of an announced integration has bought the announcement, not the integration. If the integration never ships, there is no remedy, because nothing was ever promised in a form that could be breached.

How to run the test yourself

The method requires no special access and takes about twenty minutes per claim.

First, ask the vendor to name the capability precisely, in one sentence, without adjectives. Vague claims cannot be tested, and a vendor that resists precision has answered the question.

Second, ask where a buyer can read about it without the vendor present. A documentation URL, a release note, a changelog entry. Write down the answer.

Third, open that page. Confirm it describes the capability you were told about, and note the date. A page describing a different capability is a common outcome.

Fourth, if the answer was that the documentation is not public, the claim is available at best. Record it as such and price it accordingly.

Fifth, if there is no answer at all, the claim carries no public evidence. That is not fatal, but it belongs in the risk column of the business case rather than the benefits column.

Then put the result in the contract. A capability that matters to the decision should appear as a dated commitment with a consequence attached. Vendors who have shipped agree readily. Vendors who have announced negotiate. The negotiation itself is the finding.

What we publish, and why

We run this test across the intellectual property software catalogue and publish the result each month. Every position above the floor cites a public source a reader can open. Nothing that comes from a private briefing enters the document, however reliable, because a claim a buyer cannot verify is of no use to a buyer.

The point is not to embarrass vendors. Several of the strongest products in this market sit at available rather than shipped, and say so plainly. The point is that a buyer should know which of the four positions a claim occupies before signing, and today that information does not exist anywhere a buyer can reach.

The evaluation load in this market has already passed what a human committee can carry. Two thousand four hundred and sixty-two approved entries across thirty-two categories, counted in the Cblindspot catalogue on 23 September 2026, is not a shortlist problem. It is a measurement problem. Verifying what a vendor actually delivers is the first measurement, and it is the one that makes every later comparison worth making.