A rewritable HTML app changes the software update model. If the application can modify itself in place, then an update no longer has to arrive as a new binary, package, or zip file. It can arrive as an instruction: "add this feature," "change this workflow," "migrate this data structure," "fix this behavior."
At that point, the obvious next move is to sign the instruction. If the prompt comes from the originator of the app, the user can distinguish an official update from a random suggestion. But that move exposes a gap that conventional code signing does not have: signing the prompt does not sign the program.
There is a progression here. First, prompts produced answers. Then they produced code. Then, in tools like Claude Artifacts and rewritable HTML apps, prompts began modifying software artifacts directly. The signed-prompt case is the fourth stage: prompts become update artifacts. That is where provenance stops being simple.
Karpathy's Software 3.0 frame treats prompts as programs for models: prompt → model behavior. Rewritable software inserts another step: prompt → model edits application → application behavior. The signed-prompt problem lives in that middle step. The signature authenticates the instruction before the executable artifact exists.
Code signing has been a foundation of software distribution for decades, and its guarantee is deliberately narrow. The signature attests that a specific sequence of bytes came from a specific originator, and that those bytes have not changed since they left. What runs is what was signed. The signature does not say the bytes are safe, or correct, or well-engineered. It says only that these are the bytes the originator stood behind.
A signed prompt is a different kind of object. The bytes the signature covers are not the bytes that will run. They are bytes describing a change — natural-language instructions about what the application should become. The thing that actually runs is produced later, by an LLM, against the user's local copy of the app, at the moment the update is applied. Signature verification confirms the originator wrote the instruction. It cannot confirm what the instruction will produce.
This is not the ordinary source/binary distinction. In conventional release engineering, the vendor controls the build process and signs the resulting artifact. In prompt-updated software, the originator signs the instruction and delegates realization to the user's local model, context, and app state. The build step has moved out of the vendor's controlled environment.
This interpretation step is where the verification gap opens. The signed prompt enters one machine and is realized into code; it enters another machine and is realized into different code. Both realizations may satisfy the originator's intent in some defensible sense. But neither can be verified against a canonical artifact, because no such artifact exists — only the signed description and however the local model chose to read it.
The gap has several structurally distinct surfaces. The most obvious is model variance. The same signed prompt, applied by one user through Claude, by another through a local Llama, by a third through GPT, produces three different programs. Same signature, same recipe, different kitchen.
Local state runs alongside it. Conventional updates apply against a known baseline — the version the vendor shipped, possibly with later patches the vendor also shipped. A prompt update applies against whatever the application has become since installation. Two users running the "same" rewritable app are not running the same code; they are running the cumulative trajectory of every prior signed prompt, plus whatever the LLM produced when interpreting those prompts, plus any local edits the users made themselves. The new signed update lands on that surface. It does not get to ignore it.
And the user is an author. Rewritable applications invite modification — the whole point of the regime is that the user can prompt their own app, in-place, with whatever local model they prefer. Some of those modifications are deliberate; some are experiments the user never reverted; some are byproducts of earlier signed updates the user accepted without closely inspecting. The originator sees none of it. When the next signed prompt arrives, the application it modifies is not the application the originator imagined when writing the instruction.
None of this is fatal to the idea. Prompt-based updates remain a plausible mechanism for software where the artifact is genuinely malleable and the originator genuinely cannot enumerate the local state. But the mechanism is doing less work than it appears to. The signature still authenticates the originator. It no longer authenticates the result.
A signed binary tells you who produced the thing that runs. A signed prompt tells you who requested the thing that might be produced. That difference is the new update problem.
Unlock the Future of Business with AI
Dive into our immersive workshops and equip your team with the tools and knowledge to lead in the AI era.