The canonical artifact of knowledge work should be an interactive HTML file, not a PDF or Doc export — because the moment a document can filter, recompute, and hand a precise instruction back to the model that made it, it stops being a record and becomes an instrument.

Poke the argument: take a position on each claim card below. No claims marked yet — the composer near the end will turn your stance into a precise instruction back to this file.

The dead weight of inert documents

A PDF is a photograph of thinking, not the thinking itself

When you export a report to PDF, you freeze its state at the moment of export. Every subsequent question — show me only the open items, what changed since last week, hide the boilerplate and let me see the numbers — requires a new conversation, a new export, a new file. The format does not survive contact with a follow-up question.

This is not a minor ergonomic complaint. It is an architectural property. The document cannot update itself because it has no model of its own contents. It is a picture of a table, not a table.

Evidence: A 40-page strategy brief exported to PDF. Stakeholder asks "just the risks and owners." Answer: copy-paste to a new doc, manually filter, re-send. Median turnaround: one business day. The artifact failed the first use.

The format we inherited — sequential prose frozen at export time — made sense when reproduction was expensive and revision cycles were measured in print runs. Neither constraint applies now. The only reason we're still passing PDFs and Docs around is that the tools for making something better became available about eighteen months ago and most workflows haven't caught up.

What changed is not the web browser (that's been here). What changed is that the model generating the document can also generate the interaction layer — the filters, the toggles, the copy-as-prompt buttons — in the same pass. The cost of the instrument collapsed to near zero.


A filter is not a feature — it's a different kind of object

Progressive disclosure turns a document into a question-answering machine

A document with a live filter input is not a document with a search bar bolted on. It is a different category of thing. When you type a term and watch unrelated rows collapse, you are performing an operation on a data structure — you are querying it. The document has become queryable. That shift is non-trivial: it means the reader can express intent to the artifact directly, without going through the author.

This matters most when the reader's question was not anticipated. Static documents serve the author's anticipated questions well and all other questions poorly. An interactive artifact serves the reader's actual question — whatever it turns out to be.

Evidence: A network-scan report rendered as dashboard HTML. Security engineer needs "all open ports above 1024 on Linux hosts." In PDF: grep, copy, reformat. In the HTML artifact: two filter inputs, three seconds. Same data, order-of-magnitude difference in access cost.
STATIC EXPORT Author → exports PDF Reader has a question Author again → new export INTERACTIVE HTML HTML artifact filter · query · copy Reader answers directly
Static exports loop through the author. Interactive HTML answers the reader's actual question directly.

The round-trip changes what the model can do

Copy-as-prompt closes the loop: the artifact becomes an editing surface

The most important primitive in interactive knowledge artifacts is the copy-as-prompt button. When you adjust state in the browser — check items, reorder priorities, tune weights — and hit a button that produces a precise, pasteable instruction targeting the specific file by path, you have created a closed-loop system. The reader's intent flows back to the model with zero information loss. No re-explaining the context. No re-typing what changed. The artifact itself is the edit surface, and the model is the actuator.

This is not a UX nicety. It changes the fundamental character of the relationship between a document and its revision history. Instead of the author pushing new versions, the reader pulls them by expressing intent to the instrument.

Evidence: In the render-as-html skill, a triage-board artifact generates prompts like: "In examples/plan.html, re-bucket these items: Now=[auth-flow, rate-limit] Next=[search, notifications] Cut=[legacy-import]". The model applies exactly those changes with zero ambiguity. The round-trip is lossless.

Precision beats prose in the edit channel

A conversational edit request — "can you move the risk items up and deprioritize the infrastructure stuff" — is lossy. The model has to infer which items, what "up" means in context, and which infrastructure items the reader didn't mean. A copy-as-prompt from the artifact is precise by construction: it names the file, names the items, names the target bucket. The diff between intent and instruction is zero.

The upshot is that interactive HTML artifacts are not just better to read — they are better to edit. They make the reader's intent legible to the model without an interpretation layer.

Evidence: A comparison artifact with weighted criteria. User adjusts weights in-browser (security: 40%, cost: 20%, DX: 40%), clicks copy-as-prompt. Output: "In comparison.html, update criterion weights to: security=0.4, cost=0.2, developer-experience=0.4 and recompute the winner row." Unambiguous. Immediately actionable.

The strange-loop argument: the document eats itself

When the artifact can instruct the model that made it, authorship changes shape

The Hofstadter strange loop shows up in an unexpected place here: the artifact you're reading was generated by a model, and it contains buttons that generate instructions back to that same model — instructions that will modify this artifact. The document is eating its own tail. This is not a gimmick; it is a qualitatively different kind of object than anything that could exist before the model generation layer.

The practical consequence: the role of "author" in knowledge work is shifting from someone who produces a finished document to someone who seeds an artifact and then steers it through reader interactions. The HTML file is the seed. The copy-as-prompt buttons are the steering mechanism. The model is the engine.

Evidence: The render-as-html skill ships a "dogfood gallery" of sample artifacts — each generated by the model, each containing copy-as-prompt buttons that produce instructions targeting that very file. The gallery itself demonstrates the loop: the artifact instructs its own revision. See the strange-loop gallery entry in the sample set.

The implication for knowledge management is non-trivial. If the artifact is the edit surface, then the collection of artifacts is the edit surface for a body of knowledge. Version history is not a sequence of frozen snapshots — it is a log of copy-as-prompt instructions, each one a precise diff. The diff log is the reasoning trace.


The cost is already paid

A self-contained HTML file travels exactly as well as a PDF

The objection that interactive documents are harder to share is empirically false in 2026. A self-contained HTML file with all CSS and JS inlined opens in any browser, on any device, without installation. It emails, it Slacks, it commits to git. It renders identically on iOS Safari and desktop Chrome. It has no server dependency, no runtime, no framework. The only constraint is that it must be genuinely self-contained — no CDN calls, no external fonts, no analytics pings.

Evidence: The render-as-html skill enforces self-containment as a hard constraint: zero external network requests in private artifacts. The resulting files average 60–180KB — smaller than a typical PDF with embedded images. They open offline. They diff cleanly in git.

The interaction layer costs ~20 lines of vanilla JS

The copy-as-prompt mechanism — the thing that closes the loop between reader intent and model action — is approximately 20 lines of JavaScript. No framework. No build step. No dependency. The model generates it inline, in the same pass as the content. The marginal cost of turning a static document into an instrument is near zero when the author is a model rather than a human developer.

This is the key economic fact. Before LLMs, building the interaction layer required a developer, a framework, a deployment pipeline, and ongoing maintenance. Now it requires the same request that produces the content. The economics are decisively in favor of the instrument.

Evidence: Every render-as-html artifact includes a copy-as-prompt pattern in ~20 lines. The implementation: collect mutated state from the DOM, format as a precise instruction naming the artifact path, write to clipboard with a visible textarea fallback for blocked contexts. The full pattern is in SKILL.md §Copy-as-prompt.

The round-trip, performed on this page

The essay claims an artifact can hand a precise instruction back to the model that made it. So watch it happen. Below is the exact copy-as-prompt instruction — recomputed live from the position you took on each claim card and the notes you wrote. Change a stance above and this rewrites itself. Flatten the page and it dies.

naming this file by path · only your deltas, not the whole essay

Five things to carry out of here

1 The format constraint is historical, not technical. PDFs and Docs are habits from a world where the interaction layer was expensive to build. That constraint no longer applies when a model generates both content and interaction in the same pass.
2 A filter is a query interface, not a UI decoration. When a reader can express intent directly to the artifact, the author's anticipation of questions is no longer the bottleneck. The reader's actual question is what gets answered.
3 Copy-as-prompt makes the edit loop lossless. Naming the file, naming the items, naming the target state — zero interpretation required. The reader's intent reaches the model without compression.
4 Self-contained HTML travels as well as PDF. Zero runtime dependency, offline-capable, smaller than most PDFs with images, diffs cleanly in git. The sharing objection is empirically false.
5 The artifact that can instruct its own revision is a new kind of object. Not a document with buttons. A different category — one where authorship is steering rather than producing, and where the model is the engine that acts on the reader's expressed intent.