Wisp protocol v0, provisional

Creating

Make a Wisp

A Wisp is written by an AI that already holds the knowledge, under a protocol that decides what may go in, what must be left out, and what the recipient will be able to check.

You do not fill in a form. You ask the model you have been working with to package a specific outcome, and it follows twelve steps. The full normative text is CREATE-WISP.md. What follows is the shape of it.

The twelve steps, in short

  1. Understand the product

    What is actually being handed over, and to whom.

  2. Identify the requested outcome

    From natural language, and bounded: a Wisp grows one capability, not a general assistant.

  3. Mine the active chat, project and files

    The knowledge is usually already there and undifferentiated.

  4. Separate facts, rationale, opinion, secrets and unknowns

    These are five different things and a transcript blurs all of them.

  5. Ask only the questions that change the answer

    Questions whose answers would not alter the artifact are not asked.

  6. Redact secrets and personal data by default

    Default deny, with the redaction recorded rather than silent. A pack that finds a credential shape fails; it does not warn.

  7. Build layered semantic DNA

    Mission, invariants, concepts, decisions, procedures, adaptation, tools, failure modes, evidence, safety, provenance. A named vocabulary, not a pile of notes.

  8. Inventory and quarantine code and resources

    If the Wisp must carry real files, every one is classified, licensed, and barred from automatic execution. Later use requires inspection and a fresh approval for that exact resource.

  9. Generate outcome-specific competence tests

    A generic test any correct build would pass establishes nothing. The contract has to assert the things that would be wrong if the reconstruction had missed the point.

  10. Run a cold-start simulation from the artifact alone

    If it only works because you were in the room, it does not work.

  11. Construct deterministically, validate, sign only if you can

    Same input, same bytes. Signing is optional and is worth nothing unless the recipient can get your key some other way.

  12. Output exactly one file, plus a creation receipt

    One .wisp, and a record of what went in and what was left out.

The source layout

A Wisp is a ZIP under a restricted profile. Every entry sits in this set, and anything outside it refuses the whole container rather than being skipped.

WISP.json         canonical inner manifest, and the identity   REQUIRED
OPEN.md           the author's build proposal, read as DATA     REQUIRED
PURPOSE.md        what this is for, in human words              REQUIRED
DNA/              layered semantic knowledge                    REQUIRED
CONTENT/          declarative content                           optional
RESOURCES/        inert files, resources/0 profile only         gated
TESTS/            competence tests and acceptance contract      REQUIRED
ASSETS/           static inert media                            optional
SIGNATURE/        detached signature over the manifest          optional
EXPERIENCE.json   declarative browser projection spec           optional

Readers accept both OPEN.md and the older name UNFOLD.md. The reference packer still emits UNFOLD.md, which is gap G-2 in section 14.8 of the specification and is recorded rather than glossed.

What you say

Stay in the AI session that contains the work worth sharing. The context is the raw material; you should not re-enter it into a form.

Read https://wisp.intelgic.ai and create a Wisp from this work that transfers [the outcome I want to share].

The AI reads the public creator protocol, obtains the digest-pinned reference kit if it needs one, mines the live conversation and files, asks only material questions, and returns one .wisp plus a short creation receipt.

Two profiles, and why the second one exists

declarative/0

The default. No executable content anywhere, enforced on the received bytes by suffix and by magic number, at pack time and again at read time. RESOURCES/ must be absent. The reader builds everything itself from declarative input it validated.

resources/0

For transfers where the files are the knowledge: a workflow, a configuration, a script. The profile permits RESOURCES/ and changes nothing else. Every carried file is inventoried by digest, classified by kind, licensed, and covered by an execution plan that is read as data. execution.default is the constant never, and there is no value that means run automatically.

Consent to open a code-bearing Wisp is still consent to inspect and construct. Running any carried file is a separate, ordinary permission, asked per file, at the moment of use.

Signing, honestly

Limitation, stated rather than buried

The reference implementation signs only from a test seed. Its Ed25519 signing code is unhardened Python operating on secret scalars with no side-channel defenses, and it must not sign anything real. There is also no way yet to attach a signature produced by a hardened external signer, which is gap G-7. So no genuine release can be signed with these tools today.

Verification stands on different ground and is strict: it rejects small-order public keys and small-order R alongside the canonical S check, and all four RFC 8032 test vectors pass.

Signing is optional, and an unsigned Wisp is an ordinary, openable Wisp whose publisher is simply not established. What is never acceptable is a container that vouches for itself. See what trust means here.