AMONG CATS AND BOOKS

Fullstack Refereeing

Fullstack Refereeing Banner

This post is about me taking an analogy way too far, but I think it's useful.

As a referee, you are doing several different jobs at once. A lot of advice about running games gets muddy because it never says which of those jobs it's actually trying to help with.

Sometimes the fictional world feels flat. Sometimes players stumble because they don't know what they can do. Sometimes a session keeps bogging down even though the prep was fine. Those are different problems, and they need different solutions.

So this is my attempt to separate those jobs a bit more clearly.

Ugh, I guess I'm doing taxonomy.

The Basic Split

At the simplest level, I think refereeing breaks into three kinds of work:

That maps pretty neatly to a software analogy:

The analogy helps because it points at a very real failure mode.

You can have a rich Backend and still struggle to run good sessions if none of it becomes playable. A strong Frontend with vivid descriptions, dramatic scenes, and lots of energy will only get you so far if it sits on top of weak underlying logic. And even if you get both working in tandem, the whole thing can still fall apart at Runtime because the pacing feels off, notes are a mess, or people keep losing the thread.

That's why I think the split is useful.

A Very Simple Example

A castle in the Backend isn't the same thing as a castle in the Frontend.

In the Backend, the castle might be:

In the Frontend, that same castle becomes usable information:

Same castle, different job.

The Backend makes it coherent. The Frontend makes it playable.

The Full Stack

The simple split is useful, but it's broad. If we zoom in, the work breaks down further.

What I am calling the Backend is really two things:

What I am calling the Frontend is also really two things:

And what I am calling Runtime becomes:

You don't need to care about the labels for their own sake. What matters is noticing that different parts of refereeing live in different places, do different jobs, and fail in different ways.

The Layers of Refereeing

Data is the world as stored truth.

This is where locations, NPCs, factions, hazards, resources, and unresolved situations live. What's in the crypt? Who serves whom? What's the monster actually doing here? What treasure is really hidden behind the altar? These are data questions.

Logic is how that truth changes.

This is where procedures live: dungeon turns, wilderness travel, encounter checks, reaction and morale rolls, clocks, faction turns, weather changes, and offscreen developments. The Logic layer is what makes the world dynamic instead of static.

Interface is the grammar of action.

This is where the game defines what players can ask, what they can try, what the referee answers freely, what's hidden but inferable, and what counts as a meaningful declaration of action. A lot of trouble at the table is really interface trouble. Players aren't sure what kind of input the world will actually respond to.

Presentation is how the world becomes perceptible.

Players don't act on hidden truth directly. They act on descriptions, clues, NPC behavior, spatial layout, pressure, rumors, visible danger, and consequences they can actually perceive. Presentation isn't fluff. It's how players get the information they need to make plans.

Operations is how the session is run from moment to moment.

This is pacing, spotlight management, note access, turn flow, improvisation under pressure, consequence tracking, and recovery from confusion. You can have a good dungeon and still run a bad session if your operations are a mess.

Platform is everything the game runs on.

This includes table culture, safety practices, venue limits, scheduling, tools, online versus in-person play, voice chat latency, shared note-taking, and all the other brute conditions that shape what's easy or hard in practice. Some games don't fail because the world or procedures are weak. They fail because the platform they are running on is.

Concerns

What a campaign has to do well.

Once the stack is in place, the next question isn't just "where does this belong?" but "what does a campaign need to do well if it's going to feel alive and playable?"

A campaign needs to remember what has happened. If the players burn down the granary in session 3, that should still matter later. NPCs should remember favors, betrayals, and suspicions. This is persistence.

It also needs consequences to spread. A raid disrupts trade. Disrupted trade raises prices. Rising prices worsen tempers and embolden bandits. This is propagation, the world responding instead of merely waiting around for the players.

The referee also needs the right information at the right time. That's retrieval. Closely related is tooling, the systems used to manage the campaign at all—notes, calendars, rumor tables, dashboards, faction sheets, prep documents.

There also has to be some way to tell what is actually happening in play. What do the players understand? What are they fixated on? What are they missing? This is monitoring.

And hidden truth has to become something players can actually notice. A cult meeting becomes footprints, rumors, a strange sound at night, or a nervous sermon. A trade disruption becomes empty stalls, higher prices, and anxious merchants. This is the content pipeline, how Backend state becomes Frontend material.

Finally, the whole thing has to remain legible and stable. Players need to understand what matters and what they can do. That's usability. They also need clear information boundaries. Some things are free, some hidden, some discoverable, some secret. That's permissions. And long campaigns need a way to evolve without collapsing into contradiction. That's change management, things like canon versus draft prep, retcons, updated notes, and new house rules.

You don't need to use all of these terms constantly. The important point is that campaigns fail in recurring ways, and those failures are often easier to understand once you can name what function is breaking.

Content Pipeline Diagram

A referee turns hidden world truth into playable signals, player action, and changed world state. Most failures happen somewhere in that chain.

Using the Framework

Once the framework is in place, you can use it to ask what familiar tools or procedures are actually doing.

A clock, in the Blades in the Dark sense, is mostly Backend state. It tracks the truth of an unfolding situation. But it's also Logic, because it changes that truth procedurally. It's also Monitoring, because it makes progress visible, and often Presentation, because players can see it.

A faction turn is another good example because it touches so many parts of the stack at once. It lives in Logic because it updates the world procedurally, but it also depends on Data, feeds Propagation, rewards Persistence, and usually creates Retrieval and Tooling needs for the referee.

A rumor table or encounter procedure is a good example of the content pipeline at work. Hidden truth is one thing. Players actually being able to notice it is another.

A reaction roll is useful because it pushes uncertainty into procedure instead of pure referee fiat. It sits in Logic, but it also affects Permissions and backend integrity by making NPC response something to be discovered rather than simply declared.

Adjacent Frameworks and Principles

This way of thinking isn't coming out of nowhere. There are already a few frameworks and principles in the TTRPG space that line up with parts of this stack.

Blorb maps very naturally onto the Backend, especially Data, Logic, Permissions, Persistence, and Change Management. It's useful for thinking about backend integrity. Prep has authority, discovery has weight, and the referee is constrained by what has already been established.

Similar ideas in the same orbit push in that direction as well. The fiction shouldn't bend just because an abstraction points elsewhere. Procedures are meant to answer to the world, not replace it. That also maps strongly onto Data, Logic, and Permissions.

ICI Doctrine (Information, Choice, Impact) fits almost embarrassingly well here. Players need enough information to make meaningful choices, and those choices need to have visible consequences. That overlaps directly with Interface, Presentation, Propagation, and really the concerns section as a whole.

Landmark, Hidden, Secret is another very useful design lens. It's basically a way of thinking about how information is distributed. What's obvious, what can be found through engagement, and what remains genuinely secret. That maps especially well to Presentation, Permissions, Usability, and the content pipeline.

The OSR Onion is useful here because it's already a layered model, just with a different center of gravity. It puts Adventure and Procedures closer to the center than Mechanics or Character-build concerns. In my terms, that means adventure material and procedures carry more of the game's real weight than outer system widgets do.

This also helps explain why some tools and frameworks don't combine cleanly. They are often assuming different answers to basic questions like who gets to establish truth, how much information players have, and whether choice is really querying a world or just selecting presentation. The Quantum Ogre is a good example. The problem isn't simply "the GM moved an encounter". The real issue is whether the players' choice was made against established or implied information, and whether the Backend actually commits in a way that lets that choice matter. From a Blorb perspective, once truth has been established, moving it to preserve a preferred outcome isn't just a different style. It's a structural contradiction.

Taken together, these ideas all point at something this essay is trying to name. A lot of refereeing lives in the relationship between established world truth, procedures that change that truth, the way information is surfaced, and the way player choices feed back into the world.

Alignment and Tension Diagram

This isn't a moral map of good and bad ideas. It shows that different tools and styles optimize different priorities, and that some of those priorities stop lining up cleanly.

More than OSR

I think what you call the person running the game matters. I use the term Referee deliberately, because it comes closest to my ideal: fair adjudication and authority granted to the fictional world. That's why the Backend matters so much to me.

Calling yourself a Game Master, an MC, or a Director usually implies different relationships to authority, different priorities, and different areas of focus. Sometimes that has to do with play culture, sometimes with play style, and sometimes with the specific game. You can run an OSR game in a trad style and vice versa.

But I don't think this framework only works for my preferred mode. A Fullstack GM or a Fullstack Director still has to deal with Backend, Frontend, and Runtime. The difference is which parts of the stack get emphasized and optimized. That produces different experiences, and often different needs.

Diagnostic Tool

The most practical use of this framework is that it helps identify what kind of problem you are actually having. A lot of bad fixes come from solving the wrong layer.

If the world feels shallow, that's often a Backend problem before it's anything else. There may be too few established truths in the Data layer, too little motion in the Logic layer, or too little Propagation making past actions matter. More lore or voice acting won't fix that if the world isn't actually changing.

If players never know what to do, that's usually a Frontend problem. The Interface may be unclear, the Presentation may not surface useful information, or the game may simply have poor Usability. The necessary information exists, but not in a form players can turn into plans. More roleplaying won't help if the players still can't tell what they can do.

If the session drags, that's often an Operations problem. Pacing may be weak. Retrieval may be too slow. Tooling may be too clumsy to support play under pressure.

If consequences never stick, the problem is often Persistence, Propagation, or Change Management. The world isn't remembering, responding, or stabilizing its changes.

Once you separate the jobs of refereeing, you can stop trying to solve every problem with the same kind of advice.

Case Study: Pipes on Droomen Knoll

Spoiler note: This section discusses the design of the starter adventure Pipes on Droomen Knoll from the Dolmenwood Campaign Book and lightly touches on some adventure secrets.

The starter adventure Pipes on Droomen Knoll in the Dolmenwood Campaign Book is a good example of how this framework can be used on a real location. It's a small ruined fairy site with hostile occupants, buried history, interlocking secrets, and consequences that can spill outward into the wider campaign.

On the Backend, it gives the referee a lot of solid material to stand on: the history of the site, current occupants with motives, hidden ties to the surrounding settlement, concealed rewards, and several hooks that connect the location to the nearby region. These are durable truths, not just scene prompts.

On the Logic layer, it also gives real movement: there are turn-based random happenings, alarm states can spread through the site, creatures can alert one another, and deeper parts of the location can be accessed through site-specific procedures. The site isn't just stocked—it's procedural.

On the Frontend, the module is strong on Presentation. The approach to the site is full of cues players can act on: strange music on the wind, unusual flora, smoke from the ruin, a leaning tower, firelight, and the chance of being spotted. Inside, the site keeps doing that work with murals, eerie signs, hidden routes, environmental clues, and objects that imply history and danger.

It's also unusually strong on Interface because the adventure format is explicit about how it expects the referee to use it: scan the area name, scan bolded description terms, describe the important details, then answer further questions and use the listed actions and details as needed. That's almost a miniature interface manual for running the site.

At Runtime, it asks the referee to do real work: track turns and random happenings, manage alarms and reactions, handle multiple routes into the site, notice when clues connect, and keep the pressure moving without burying players in explanation. The format helps with retrieval, but it still expects the referee to operate the place actively.

And for campaign concerns, the module already points beyond itself. Its epilogue suggests continued consequences in the wider world rather than treating the adventure as a sealed-off episode. That's persistence and propagation already sketched into the design.

That's why I think this framework is useful. It lets you say more than "this module is good" or "this module is flavorful". It lets you ask: what truths does it establish, what procedures does it provide, what signals does it surface, what burdens does it place on the referee, and what kinds of campaign consequences does it support?

Conclusion

The Backend makes the world coherent.

The Frontend makes the world playable.

The Runtime makes the session work.

The fuller stack explains where different parts of refereeing live, and the concerns explain what a campaign has to do well.

So fullstack refereeing isn't just hidden worldbuilding plus vivid description. It's the work of making a world coherent enough to matter, legible enough to act on, and alive enough to push back.

#advice #fullstack #guide