Edited the preset, nothing changed? Check whether it was ever sent.

Three scenes, and most tavern players have lived at least one. You rewrite a block in your preset and the replies don’t move an inch. The world info test panel lights green for an entry, yet the request log shows no trace of it. You wrote three example dialogue blocks for a card, and the model has never once spoken in that voice.

All three symptoms point at the same step: assembly — everything that happens between pressing send and the request leaving your machine. SillyTavern barely shows you this step, so failures turn into guesswork. While building the assembly inspector we read SillyTavern 1.18’s assembly code function by function. This post lays out the dark rules we found — each one maps to a pile of “mysteriously dead” cases from the community.

The skeleton: how one send gets built

On the Chat Completion track, a send produces a list of role-tagged messages, and the order of that list is decided by one thing: the preset’s prompt manager order (prompt_order). The sequence of blocks in the order is the sequence of messages sent. There is no second, hidden sort.

Blocks come in two kinds. Literal blocks carry their own text — main and post-history instructions are the famous ones. Markers are placeholders: their position lives in the order, their content gets filled at send time — the card’s description, personality and scenario, your persona, the two world info positions, plus the two big regions, example dialogues and chat history. The 1.18 factory order opens with main, then world info (before), persona, card description, personality, scenario, the auxiliary block, world info (after), example dialogues, chat history, and post-history instructions as the anchor leg. The preset you downloaded almost certainly reshuffled this — that is what makes it valuable, and what makes it break.

Symptom one: you edit the preset, nothing happens

Four root causes, ranked by how often we see them.

The most unfair one first: the block is not in the order at all. The prompt pool and the order are two separate lists; sitting in the pool does not mean standing in the queue. A literal block outside the order plays no part in assembly — no error, no hint, nothing grayed out. Hand-me-down presets are the classic case: the original author deleted the order entry and left the definition behind, and you have been polishing text that never ships.

The second is plain: the block is in the order but disabled. The third hides better: the block was switched to depth injection (injection_position set to absolute). Such a block leaves the trunk entirely and gets spliced into chat history, N messages back from the newest — depth counts backwards from the latest message, with 0 hugging the very end. The order list shows it second from the top; in the actual request it sits deep in the history stack, surrounded by chat lines.

The fourth gets blamed on the model most often: main was silently replaced by the character card. “Prefer character card prompt” ships enabled, so whenever a card’s system_prompt field is non-empty, its text replaces your main block — unless the block forbids overrides, or the card author spliced your main back in with the {{original}} macro. You can rewrite main forever; what ships is the card’s version. Post-history instructions and the card’s matching field follow the same mechanism.

Symptom two: the entry triggered, the content never arrived

Triggering and delivery are different events, with several gates in between.

Beyond that pair, three more gates. Depth-injected entries (and the Author’s Note) are spliced into the history pool before budget filling, so they compete with history for the same tokens — budget runs out, the deepest ones die first. If the order has no enabled chat history marker, depth injections have nowhere to land, and history plus all injections are dropped wholesale. Entries aimed at the example region depend on the example dialogues marker being present — and their content needs a name prefix, or they die the symptom-three death: silent discard.

One placement rule worth keeping: injections at the same depth and role merge into a single message — preset absolute blocks first, world info and Author’s Note after; the Author’s Note defaults to depth 4. The world info docs cover triggering well; the placement half mostly lives in the source.

Symptom three: example dialogues vanished

Almost always the same root cause: attribution prefixes. On the Chat Completion track, example dialogues get split into individual messages, and the splitter keys on lines starting with YourName: or CharName:. A block with no attribution prefix anywhere — say, a prose-style writing sample — ships zero characters. Silently. No warning. Of all the dark rules in this post, this one claims the most victims.

Two smaller causes: examples fill after chat history, so they are the first thing sacrificed when tokens get tight; and each <START> block is all-or-nothing — it ships whole or not at all. So “my examples stopped working thirty turns in” is not superstition. The budget pushed them off the bus.

The three-step check

Every dark rule above is a visible diagnosis in the assembly inspector. Drop the preset in (card and world info optional), then three steps: read the block diagnosis — unplaced, disabled and card-overridden blocks are named outright; simulate one send and find your block in the source-colored message stream; open the entry placements and the budget waterfall, where every entry states where it landed or which gate it died at. Semantics aligned to 1.18, everything local in your browser, nothing uploads.

Back to the three scenes. What they share: you thought you were tuning content, but the failure lived in assembly. Next time a preset “does nothing”, skip the eleventh rewording — spend two minutes confirming the text was actually sent, and where it landed. Most cases crack right there.