Some of the Conformance in Our Product Was Written by Somebody Else, and You Should Know Which Parts

This page separates what we built from what we assembled, using our own stack as the example, because the distinction is one nobody volunteers.

The specification in question

There is a standard for treating a web server as a place to create, read, update and delete resources through plain HTTP, with containers that behave like folders and a defined way to discover what is inside one.

It is the interoperability contract underneath Solid, the personal-data-store ecosystem. An application written against it works with any conformant server, which is the entire promise: your data lives where you choose and applications come to it.

What "we support it" can mean

Three different things, routinely stated in the same words.

We implemented it. Our code handles the verbs, the containers, the discovery, and we can be tested against the specification.

We ship a component that implements it. Somebody else's server is part of our product, and the conformance is theirs. Our code sits beside it or in front of it.

We are compatible in spirit. A REST API with similar-looking URLs. This is the one that gets described as support most often.

These have different consequences when something breaks, when the specification moves, or when you ask who to call, and a buyer who cannot tell them apart has not learned what they think they learned.

Why we are drawing this line ourselves

Because inherited conformance is the most common overstatement in infrastructure, and it is almost never a lie. Every word of "our platform supports it" is defensible when a dependency does the supporting.

What the buyer loses is the ability to predict. If the conformance is a dependency, then upgrading it is your upgrade path, its bugs are your bugs, its abandonment is your problem, and the vendor's own roadmap has very little to do with any of it.

The question that separates the cases is not "do you support it" but "did you write the part that supports it." That is a fair question to ask us, and the answer is above.

What to ask any vendor about a standard they support

"Did your team write the implementation, or does a dependency provide it?" The single question, and most material will not have answered it.

"Which conformance suite have you run, and can I see the result?" For us: none, and we are not claiming otherwise.

"If that dependency stops being maintained, what is your plan?" A vendor who inherited conformance and has no answer here has an exposure they have not priced.

"Does your own API speak the protocol, or does the component beside it?" For us: the component. Ours does not.

Where this leaves a decision

If your requirement is that your own client works against our endpoints, it does not, and the presence of a conformant component elsewhere in our stack should not be read as it does.

If your requirement is a working personal data store with an exit path, that runs today, part of its conformance is inherited and part of our stack has none, and you now know exactly which is which, which is more than the phrase "standards-based" would have told you about anyone.