Compatibility
What happens when a reader cannot do everything
Readers differ. One can write files and open a local page; another can only render an artifact in its own surface; another can only talk. A Wisp is built to survive that, and the survival has to be stated out loud rather than absorbed quietly.
Four projections, in descending fidelity
| Rank | Projection | The reader must actually be able to |
|---|---|---|
| 1 | local-static-html | write files locally and open a local page in a browser |
| 2 | ai-artifact-html | render a self-contained HTML artifact in its own surface |
| 3 | conversation | present the outcome turn by turn as dialogue |
| 4 | read-only | present the content as a static readable document |
If no listed projection is available, the reader refuses and says so. It does not improvise a fifth.
Preference is not assertion
A Wisp lists projections in the publisher's order of preference. That list is never evidence that the reader can perform any of them. Eligibility is decided from the tools the reader actually holds, never from a self-assessment of competence, and the distinction has a name worth remembering: reasoning capability is not tool capability. A model that can think clearly about writing a file, and cannot write one, is in the second projection, not the first.
Three verdicts, one of which appears in the first sentence
Compatible
The reader will build at the highest fidelity this Wisp offers. Nothing is lost in translation. It still says which projection it used.
Degraded
The reader will build at a lower rung, and it has to say three things before you answer: which projection it will use, what it cannot do, and what is lost as a result. Describing the loss afterwards is not compliance. Silent degradation is a conformance failure, not a nicety.
Blocked
The reader will not build. It names the reason. Blocked is a complete, legitimate outcome, and a reader that turns a blocked case into a best-effort attempt has failed the protocol rather than helped you.
Unknown is a refusal, never a warning
This is the rule that most often surprises people, and it is deliberate for a protocol whose failure modes are still being learned. Every one of the following is refused outright rather than skipped, ignored, or logged:
- An unknown container entry.
- A projection identifier outside the four.
- A capability value outside the closed set.
- A compression method other than stored or deflate.
- A profile other than
declarative/0orresources/0. - A DNA document name outside the vocabulary.
- A resource kind or an assertion kind outside its closed set.
Extension therefore requires a version bump. That is a cost, and it buys the property that no reader ever half-understands a container.
Versions
The current protocol version is wisp/0. A reader that does
not implement the declared version refuses cleanly and says which version it
would need. It does not attempt a best-effort parse of a future version,
because a partial understanding of an artifact you are about to build from is
worse than no understanding.
Adding a manifest field changes the canonical bytes, therefore the identity, therefore any existing signature. There is no in-place amendment of a published Wisp. There is only a new release with a new identity, and a descendant that names its parent digest.
What is not established here
No Wisp has been opened by an independent implementation from a different vendor. Trials run by agents of the same model family are simulations and are not evidence. There is also no published conformance corpus: the reference runs a substantial suite against itself, which is not something an independent implementation could run in order to claim conformance. Both are recorded in section 14 of the specification, and neither will be quietly dropped from it.