We Are the Junior Party in This Relationship, and Saying So Is the Point
Our data-store product is compatible with this protocol rather than conformant to it, and we did not build any part of the protocol itself.
What it specifies, and who built it
A personal data store the person controls, applications that request access to it rather than holding copies, and permissions the person grants and withdraws.
It comes from Tim Berners-Lee's project and the community that has developed it through a W3C community group over many years. The server implementations, the specifications and the tooling are theirs. We contributed none of it.
That sentence is doing real work, because the pattern in this industry is to compose somebody else's protocol and then market as though the composition were the invention.
Why the relationship matters more than the technology here
Composing an open protocol is not like buying a component. It is joining somebody else's project, and it comes with obligations you cannot purchase your way out of.
Conformance has to be earned against a specification you do not control. Changes arrive on the community's schedule, not yours. And the credibility you borrow by naming the protocol is credibility somebody else built, which means misrepresenting your relationship to it costs them as well as you.
So the honest description of our position is junior: we run their server software with our own identity bridge in front and our own storage underneath, and the protocol work is theirs.
The word we use, and the one we do not
Compatible, not conformant.
Our store runs a genuine Solid server implementation plus a bridge to our identifier method, with our own authorisation and storage layer. It does not implement the full protocol, and full conformance is real, undone work rather than a rounding error.
Compatible means today's applications mostly work against it. Conformant would mean an application written for any store works against yours, and your data moves to another provider without a migration project, which is the entire portability property, and the reason anyone should care about the protocol at all.
Why we are honest about it rather than quiet
Because the failure mode is specific and it damages the wrong party.
A vendor that implies conformance and delivers compatibility does not only mislead a buyer. It spends the protocol's reputation on its own product, and when the gap surfaces, the community that built the specification wears part of the cost.
We are also aware that this project has been used as a credibility prop before, by more than one company. Naming our position precisely is the minimum owed to a community whose work we are standing on.
What to ask any vendor invoking this protocol
"Conformant or compatible?" Ask for the word, then ask what fails. A vendor without a ready answer has not tested against the specification.
"Which parts did you build?" Most of this stack is community software. That is entirely fine, and you should know which parts are the vendor's.
"Has anyone migrated a store off you?" Portability that has never been exercised is a claim.
"What do you contribute back?" Not a moral question. A vendor that only consumes an open protocol has no influence over where it goes, which is a risk to your roadmap as well as theirs.
Where this leaves a decision
If you need the portability guarantee, conformance is the thing that delivers it, we do not have it, and the honest answer is that it is work we have not done rather than a difference of opinion.
If you want a data store where applications request rather than copy, anchored to an identifier that also carries your credentials, that runs today, and the accurate way to describe it is as compatible with a protocol other people built.