Haute Lumière · The Stack · Standing plan

The Unbuilt Wing

Everything the platform already gives you, and nobody has come to collect.

Eleven capabilities that are provisioned, priced, and sitting idle — and the one product in the house that turns the whole Stack into something no competitor can answer.

This is not a wish list. Every capability below is generally available on the account today, with its real limits and its real price. The question each section answers is the same: what does the house get that it cannot get any other way, and what does it cost to take it.

IThe premise

The Stack was built on a platform that got substantially more capable while it was being built, and almost none of the new capability has been claimed.

That is the ordinary condition of anything shipped fast. You choose a set of primitives at the start, you build against them, and by the time the thing works the ground beneath it has moved. Most houses never go back and look. The cost of not looking is not that you miss a feature — it is that you build the feature badly, by hand, on top of a primitive that would have given it to you.

There are three specific and expensive versions of that mistake already sitting in this codebase. Long-running work is being run inside a request lifetime, where it gets cancelled and strands a row halfway written. Search is a substring match over a list already on screen, in a corpus of eleven million words. And a git host has been built without the ability to run git, because until recently the platform could not run a binary at all.

All three now have first-class answers. This document is those answers, and eight more.

The most expensive thing in software is a workaround for a problem that has since been solved.

IIContainers

You can run a real binary now. Which means Witness can actually host git.

StatusProduction
WhereWorkers Paid plan
ShapeAny language, any runtime, bound to a Durable Object

Containers let you run code written in any language, built for any runtime, as part of an application built on Workers. A Worker instantiates the container and talks to it; a Durable Object holds its state. Resource-heavy work, a full filesystem, a Linux-like environment, an existing Docker image — all of it now sits inside the same request that serves a page.

The consequence for this house is not incremental. Witness is a git host that has never been able to run git. It hashes trees, it anchors them four ways, it serves receipts — but the thing a git host does, which is speak the git wire protocol to a client typing git push, has been out of reach because the runtime could not execute a binary. Phase four of Witness has been blocked on a platform limitation that no longer exists.

With a container, git-upload-pack and git-receive-pack run where they have always run: as processes, against a filesystem. The Worker in front handles authentication, entitlement and routing. The push lands. The post-receive hook computes the new tree hash and drops it on a queue, and the anchoring machinery that already works takes it from there.

That is the difference between a provenance service you upload to and a git host you push to, and it is the entire difference between a product people try and a product people live in.

What else a container unlocks here

Real EPUB and PDF generation. The dossier currently sets its type in Times and Helvetica, because font subsetting inside a Worker is a project in itself. In a container, the ordinary typesetting toolchain runs unmodified, and a dossier can be set in Cormorant and Manrope like everything else in the house. Three hundred and thirty-five books could ship as properly typeset EPUB and print-ready PDF from the same corpus that feeds the reader.

Audio transcoding. A hundred and thirty-nine narrations exist as whatever they were rendered as. A container running the standard tools can produce a proper adaptive ladder, chapter markers, and the embedded metadata that makes an audiobook behave like an audiobook on a lock screen rather than like a file.

Real archive formats. The receipt bundle is currently a hand-rolled uncompressed zip written from scratch, because there was no other option. There is now.

IIIDurable Objects with SQLite

Ten gigabytes of real SQL per object, full-text search built in, and thirty days of undo.

StatusGenerally available
Per object10 GB SQLite
IncludedFTS5 · JSON · math · point-in-time recovery

SQLite in Durable Objects is generally available, with a ten-gigabyte database inside every object, a SQL query interface, the FTS5 full-text search module, JSON functions, and point-in-time recovery that can rewind to any moment in the last thirty days — on by default.

The house currently keeps everything in one shared D1 database, with the collision scars to prove it: members, marks and state were all taken already, and had to become membership, passages and standing. That is what a shared namespace does over time.

One Durable Object per reader changes the shape of the product. Each reader gets their own SQL database, isolated by construction rather than by a WHERE user_id = clause that one careless join can defeat. Their vault items, their marks, their places, their file manifest and their room state live in one object with one lock, which means a write is atomic across all of them without a transaction spanning services.

Two consequences worth naming precisely.

Point-in-time recovery is a customer-facing feature, not an operational one. Thirty days of rewind, on by default, means a reader who deletes a folder can have it back, and a reader whose vault is corrupted by a bad sync can be restored to yesterday. Every competitor sells that as a premium tier. Here it is a property of where the data sits.

FTS5 gives every reader a private search index. Their own documents, their own marks, their own notes, searchable at full-text quality inside their own object — and because the object is theirs alone, the index can be built over decrypted content held only in that object's memory during a session, never in a shared store.

IVAI Search and Vectorize

Point it at the bucket the corpus is already in, and eleven million words become a search engine.

AI SearchFree in open beta
Vectorize~5m vectors per index
BonusAn MCP server on every instance

AI Search — the product formerly called AutoRAG — is the managed version of everything the phrase "retrieval augmented generation" is supposed to mean. You point it at an R2 bucket. It handles chunking, embedding, continuous re-indexing, retrieval and answer generation. When a file is deleted from the bucket, its chunks are removed from the linked index on the next sync. It is free during the open beta, with only the underlying model usage billed.

The entire corpus is already in an R2 bucket. That is the whole prerequisite. The work to turn three hundred and thirty-five books into a semantic search engine is a configuration step and a wait, not a project.

What it replaces is worth stating bluntly. The reader currently has a search endpoint that answers, and a shelf field that does not call it — and even the endpoint is doing keyword work over chapter text. What it should be doing is answering "where does he talk about the difference between growth and development" across a hundred and twelve volumes of developmental canon, with the three passages that actually address it, from three different books, ranked by how well they answer rather than by how many words they share.

That is a different product. In a corpus of this size, keyword search is a filing system and semantic search is a reading companion.

The part that is quietly strategic

Every AI Search instance ships with a built-in MCP server. That means the corpus is not only searchable by readers in the app — it is directly addressable by any AI agent that connects to it. A researcher's assistant, a coding agent, a colleague's Claude, all able to query eleven million words of original scholarship with citations, under whatever access rules the house sets.

The house is already thinking about being read by machines: there are llms.txt and ai.txt files on the public surfaces. This is the difference between publishing a file for crawlers to find and offering a live, queryable, rate-limited, attributable interface to the work. One is a hope. The other is a channel, and eventually a licensing product.

VWorkflows

The stranded dossier is not a bug in the code. It is the wrong primitive.

Witness has a failure mode already documented in its own notes: long work run inside waitUntil is bounded by the request lifetime, so a dossier — a long generation followed by a PDF build — gets cancelled with a warning and leaves a row half-written. The workaround has been to also run the work inline, and to make the operation idempotent so whichever copy arrives second is a no-op.

That is a careful, well-reasoned workaround for a problem that durable execution solves outright. Workflows persist state between steps, survive failures and restarts, retry individual steps with backoff, and can run far beyond any request's lifetime. A dossier becomes a sequence of named steps — scan, cite, draft, lint, typeset, seal — each of which either completes or is retried, with the whole thing observable rather than inferred from a stuck row.

The same primitive fixes three other things at once. The Luminize pipeline, which currently runs a writer at seventy-five seconds and a plates worker after it, becomes a workflow that cannot half-finish. Audio transcoding of a hundred and thirty-nine narrations becomes a fan-out that survives a deploy. And the anchoring ladder in Witness — seal, then authority, then chain, then log, with the Bitcoin commitment maturing eighty minutes later — is the single most obvious durable workflow in the entire house. It is currently a queue plus hope.

The rule this establishes

Anything that takes longer than a page load is a workflow. Anything that must not half-happen is a workflow. Anything a person is waiting for the result of, but not waiting on, is a workflow.

VIBrowser Rendering

Ten hours a month of a real browser, included, and the house has three jobs waiting for it.

Free plan10 minutes a day · 3 concurrent
Paid plan10 hours a month · 10 concurrent
SinceAugust 2025

A real headless browser, on the edge, with a free allowance that is generous enough to run a small publishing house on.

Covers. Three hundred and thirty-five books have no covers, and the house style already knows exactly what a cover looks like — a register, a plate, Cormorant at display size, a hairline at the golden section. Render the cover as HTML, which is the thing this house is best at, and screenshot it. Three hundred and thirty-five covers is a few minutes of browser time, and every one of them is on system because it was laid out by the same stylesheet as everything else.

Open Graph images. The same trick, per book, per issue, per chapter. Every link shared out of the house arrives with a properly set image instead of a default.

Luminize gets its own eyes. The pipeline currently receives HTML from an extension, which works when a reader is present but not for a page that renders client-side. Browser Rendering lets the worker fetch and render a page itself, which means luminizing can be triggered from anywhere — a link in a message, a scheduled watch on a source, a whole reading list at once.

VIIRealtime

A thousand gigabytes of free real-time media, and a reading house is exactly what it is for.

Price$0.05 per GB egress
Free tier1,000 GB, shared across SFU and TURN
ShapeAnycast WebRTC, managed

The room is currently text. It is good text — sealed on the device, delivered as envelopes the server cannot open, rendered without a single tick or unread badge. But a house built around reading has an obvious unbuilt room, and it is the one where people read aloud to each other.

A reading circle. Eight people, a chapter, voices. An author's hour. A study group working through the developmental canon a volume at a time. None of that is a video conferencing product and none of it should look like one — no grid of faces, no raised hands, no chat panel with an unread count. In this house it would be a page with a hairline that fills in gold when somebody is speaking, and the chapter open beside it.

A thousand gigabytes of free egress is a great deal of talking. At ordinary voice bitrates it is thousands of hours before a bill starts, and voice-only is a fraction of the cost of video, which is the correct choice here anyway.

The honest note: real-time media is not end-to-end encrypted through an SFU in the way the text room is. If the house builds this, it must say so in the same sentence it announces it — a live voice room is a different privacy promise from a sealed message, and the Covenant already sets the precedent of saying which is which rather than letting a reader assume.

VIIIBucket locks

Retention you cannot delete around — with a limit worth publishing rather than hiding.

R2 bucket locks set retention policies on a bucket or a prefix within one, preventing deletion and overwriting for a fixed period, until a named date, or indefinitely. For a provenance product this is close to load-bearing: Witness claims that the original is preserved beside the anchors, and a lock is what turns that claim from a policy into a property.

And here is the caveat, which belongs in the product rather than in a footnote: R2 does not offer certified compliance-mode immutability or legal hold. A lock rule can be removed by an administrator. For a regulated firm that requires certified write-once storage, this is not sufficient and S3 Object Lock remains the answer.

That limitation does not damage Witness. It sharpens it. Witness's actual argument was never "trust our storage" — it is that four independent attestations of the same content hash would each have to be defeated separately, and one of them is a commitment aggregated into a Bitcoin block that nobody, including the house, can move afterwards. The lock is a fifth belt on top of that. Publishing exactly what it does and does not guarantee is completely consistent with a product whose own documentation file is called HONESTY.md.

A provenance company that overstates its storage guarantees has undermined the only thing it sells.

IXEmail

The Covenant makes a promise that no code currently keeps.

It says, in writing: "We will write to you a week before the free part ends. Not a receipt buried in an inbox — a note that says the date and how to leave in one click."

There is no mailer wired. Signing in to Witness today requires inserting a row into a table by hand and visiting a URL, because there is nothing to send a magic link with. The most trust-building sentence in the entire Covenant is currently a sentence.

Cloudflare's email sending, bound directly into a Worker, closes this — and it should be near the front of the queue, not the back, because an unkept promise in a document titled The Covenant costs more than the feature would have.

The things it turns on: the ninety-day warning, exactly as promised. Magic-link sign-in, which removes the last manual step from Witness. The warden's replies, which the Covenant says a person answers inside a day. A monthly note about what has been added to the shelf, which for a publishing house is not marketing but the actual product news. And the receipt that says what was charged and how to stop it — a thing this house would set beautifully while everyone else sends a table with a logo in it.

XWitness, joined to the Stack

Free encrypted repositories are the best acquisition channel this house will ever have.

A record that can be withdrawn was never a record.

Witness already exists, is deployed, and is more finished than most things that get launched. Hosted git with provenance: every change hashed, signed with Ed25519, timestamped by an independent RFC 3161 authority, committed into a Bitcoin block through OpenTimestamps, and included in an append-only Merkle log whose signed roots publish hourly. Four anchors, each of which would have to be defeated separately.

All four have held in production. All four verify offline, from a downloaded zip, by a stranger with no account and no call back to Witness. That last property is the entire product and it is very rare: most provenance services are a database you have to keep trusting. This one hands you a bundle and walks away.

Why it belongs in the Stack rather than beside it

Because the Stack already has the key ladder, and a repository is a content type.

The master key derives a vault key, an identity key, and — as proposed for files — a file key. It derives a repository key exactly the same way. A private repository sealed under a key the house does not hold is the same construction as a sealed vault item, at a different scale, with a chunked envelope instead of a single-shot one.

And that combination is genuinely unavailable elsewhere. GitHub can read your private repositories. So can GitLab, and Bitbucket, and every hosted alternative — encryption at rest means the host holds the key. An encrypted git host where the host cannot read the code, that also timestamps every commit into a public chain, is a category with nothing else in it.

What free repositories do for the rest of the house

Witness's current price list starts at $29.99 a month for a repository. That is a defensible price for provenance, and it is the wrong price for acquisition.

Consider instead: the repository is free with the Stack. Every member gets encrypted, anchored, unlimited-in-practice hosting for their code, inside the hundred and eleven gigabytes they already have. Nothing extra to buy, nothing extra to decide.

The reasoning is the same as the free first chapter. An encrypted git host that nobody can try is a thing people read about; one that comes free with something they already pay eleven dollars for is a thing they move a repository into on a Tuesday afternoon, and once one repository is in, the rest follow. And a developer who has moved their work into a house is not a subscriber — they are a resident.

The money then sits where it belongs, on the things that are genuinely expensive to produce: the Resonance Dossier at $99 a repository, the Payload's encrypted delivery channel, a fresh tasting, the market seat. Those are appraisal and distribution products, and they are worth more to somebody whose work already lives here.

The whole architecture in one sentence

The library brings people in, the free repository keeps them, the vault and the room make leaving expensive, and the dossier and the market are what the house sells to the people who are already home.

XIThe anchors, turned on the books

The provenance engine was built for code. The corpus needs it more.

This is the idea in this document with the highest ratio of value to remaining work, because both halves already exist and have never been introduced to each other.

Witness anchors content hashes four ways. The house publishes eleven million words of original scholarship, deposits editions with DOIs, and licenses everything so that it may not be resold, republished, or fed to a machine as training data.

That licence is currently a sentence in the Covenant. Run every volume through the four anchors and it becomes a demonstrable fact: this text, in exactly this form, existed on this date, and here is a Bitcoin block and an independent timestamping authority that say so, verifiable by a stranger with no account.

What that is worth, concretely:

ClaimWhat the anchors give you
Priority of authorshipA date no party can move, including the house
A model trained on the corpusProof the text predates the model, in a form a court reads
Text altered and redistributedA hash comparison that ends the argument in one line
An academic depositAn independent attestation alongside the DOI
A reader's own writingThe same protection, included, for anything in their vault

That last row is the one that sells. Every writer who joins the house gets their own manuscripts anchored the same way the published corpus is — a timestamped, independently attested record of what they wrote and when, for no extra money, in a world that has recently become extremely interested in who wrote what first.

Nobody else can offer that, because nobody else has both halves. The provenance companies have no library. The libraries have no provenance engine. This house has been running both since the middle of August and has not yet joined them.

XIIOne key, everything

The strategic argument underneath all of it, stated once.

Everything in this document is an addition, and additions are how products become bloated. So it is worth saying plainly what stops that happening here, because it is a real architectural property rather than a discipline anybody has to maintain.

There is one key ladder, and every new thing is a branch of it. A master password stretched on the device produces a master key. From that key, an HKDF branch with a different label produces each domain's key — luminize-vault-v1 for the vault, hl-identity-v1 for the room's identity, and the same construction, one label apart, for files, for repositories, for anything that comes next.

That means adding a product to the Stack is not adding a system. It is adding a label, an envelope shape, and a surface. The security review is the same review. The recovery story is the same story. The thing a customer has to understand is the same one sentence: one password, held only by you, opens all of it, and the house cannot open any of it.

Compare what the alternative looks like. Four products from four companies means four passwords, four recovery flows, four privacy policies of varying honesty, four billing relationships, and four separate answers to the question of who can read your things. The bundle is not cheaper because bundles are cheaper. It is cheaper because it is one system, and one system costs less to build, less to operate, and very much less to explain.

What this rules out, on purpose

The same property draws a boundary, and boundaries are what keep a product from sprawling. Anything that cannot sit behind the reader's own key does not belong in the Stack. Server-side full-text search across encrypted content does not fit, which is why the reader's private index belongs inside their own Durable Object rather than in a shared one. Collaborative editing of an encrypted document does not fit without a key-sharing design that does not exist yet, and pretending otherwise would be the first dishonest thing in the whole house. Machine learning over a member's private files does not fit at all, and never will.

That list is short and it is worth publishing, because a customer choosing an encrypted product is really asking one question — what have you decided you will not do — and almost nobody answers it.

A product with no boundary is not generous. It is only undecided.

XIIIThe order

What to take, and when.

Ranked by what each returns against what it costs, with the ones that unblock others first.

  1. Email. The Covenant already promises it, Witness cannot sign anybody in without it, and it is a binding. Smallest job on the list and the only one that closes a written promise the house is currently breaking.
  2. AI Search over the corpus. The bucket is already there. This is configuration, and it turns the reader's weakest feature into its most distinctive one. The free MCP server is a second product arriving inside the first.
  3. Workflows for anything long. Retire the waitUntil workaround, the double-run, and the idempotence guard that exists to paper over a cancelled request. Anchoring, dossiers, Luminize and transcoding all move at once.
  4. Browser Rendering for covers. Three hundred and thirty-five covers and every Open Graph image in the house, laid out by the stylesheet that already exists, in a few minutes of included browser time.
  5. Containers, and git push. The largest single unlock, and the one that turns Witness from a service you upload to into a host you live in. Everything in phase four of that product has been waiting on this.
  6. The four anchors, turned on the corpus. Both halves are built. This is an integration and a batch job, and it produces the strongest defensive claim the house owns.
  7. The free repository, folded into the membership. A pricing decision more than an engineering one, and it changes what the eleven dollars is for.
  8. A Durable Object per reader. The deepest change and the one to do deliberately rather than quickly — it is a migration, and migrations done in a hurry are how houses lose data.
  9. The reading room, in voices. Last, because it is the only one that is genuinely new product rather than the completion of something already begun.

Eight of the nine are completions. That is the actual finding of this document: the house does not need new ideas. It needs to collect what it is already owed, from a platform that has been quietly making the hard parts free while the hard parts were being built by hand.

A wing is unbuilt for exactly as long as nobody walks into it.