Frameworks

A framework is a reusable template for a kind of game object. It says what fields exist, what they mean, and how the derived values fall out of the raw inputs. The official D&D 5e framework knows about ability scores, classes, levels, the proficiency bonus, the saving-throw matrix, and the spell slot tables. None of those values belong to a specific character; they belong to the framework, which knows how to compute them once you fill in the inputs.

If you are coming from a programming background, a framework is the type definition; an element is the value. If you are not, the easier picture is a printed character sheet: the blank sheet itself is the framework, and the filled-in copy on the table is the element.

What a framework defines

Three kinds of thing live inside a framework:

• Inputs. The raw values an element will hold. For a 5e character: race, class choices, ability scores, equipment, prepared spells.
• Derived values. Computed from the inputs. AC, hit points, attack bonuses, save DCs, spell slot counts. These never need to be entered by hand because the framework knows how to produce them.
• Action functions. Buttons the player or GM can press: take damage, cast a spell, take a short rest. Each action bundles a few smaller writes into one labelled change.

Frameworks are made of nodes

Inside the framework editor, the rules are wired together visually as a graph of nodes. A node is one small piece of logic: if x then y, sum these numbers, look up this row in a table. The framework editor connects nodes by dragging from one output handle to another node's input handle.

The 5e ability modifier, for example, is a small subgraph: a SUBTRACT node that takes the ability score and the constant 10, feeding a DIVIDE node that halves the result, feeding a FLOOR node that rounds down. The editor produces and stores that graph; authors never write it as text.

The full node catalogue (every primitive you can wire into a graph) lives in the framework node reference in the sidebar. The important fact for this page is that a framework is just a graph of these small pieces, and graph editing is incremental: change one node, the rest of the graph keeps working.

Frameworks are reusable

The same D&D 5e framework powers every D&D 5e character on the platform. Edit the framework once and every character built from it picks up the change next time it loads. There is no per-character copy of the rules to migrate.

Frameworks can also be forked. Forking takes a copy that drifts independently from its source. Useful when a homebrew table wants to start from the official 5e rules and tweak a handful of things without losing the base.

Versioning and campaigns

A campaign can pin to a specific framework version. That keeps the table stable when the framework author ships a change mid-campaign that the GM is not ready to adopt. Pinning is per-campaign, so different tables can run different versions of the same framework at the same time.

Where to go from here

• Read Elements next. An element is what a framework produces; the two concepts are easier to hold together than apart.
• If you are about to build a framework, the framework node reference (sidebar, under Nodes) covers every primitive you can wire into a framework graph.
• For the layout side, jump to Frames.