How frameworks, elements, and frames fit together

By itself, each of the three building blocks is small. The reason Fabled puts the work into separating them is that, together, they cover almost everything that happens at a table without any one layer needing to know how another works internally. This page is the capstone: a single picture of how the layers compose.

If you have not yet read Frameworks, Elements, and Frames, start with those. This page assumes the one-line definitions are already familiar.

Reading the stack bottom-up

A player or GM looks at a frame. The frame is bound to an element. The element references a framework. The framework runs the rules. Every read flows in that direction; nothing higher up the stack ever depends on a specific lower-layer implementation.

A worked example: the player clicks the Attack button on Lirien's sheet.

• The frame (the sheet) handed the click to the action function the button is bound to.
• The framework (D&D 5e) ran the action: rolled the attack expression with the right modifiers, applied advantage if a buff was active, decided the result.
• The element (Lirien) absorbed the result. If the attack landed and the target took damage, that translates to a ledger entry on the target's HP variable; if a smite-style buff was consumed, its temporary ledger entry comes off.
• The frame (and every other frame currently displaying Lirien) re-read the values that changed and refreshed.

The three layers are independent

Independence is the whole reason the three layers exist as separate things. Each layer changes on its own schedule:

• Rewrite a framework without touching any frames. The bindings keep working as long as the value names stay the same.
• Redesign a frame without rewriting the rules. The framework does not know or care what the sheet looks like.
• Fork an element off another and keep both up to date as the underlying framework evolves. Changes to the framework propagate to both forks.

What sits across the three layers

A few platform features touch all three layers without belonging to any one of them:

• The ledger. A list of modifier entries on each element. The framework decides what a modifier means and when to read it; the element stores the entries; the frame displays the values that result. Re-derive a variable and the framework folds every relevant ledger entry into the answer.
• Permissions. Who can edit a framework, who owns an element, who can see a frame. Permissions are set per-campaign and apply across all three layers consistently.
• Marketplace bundles. A bundle commonly ships a framework, several elements built on it, and a frame or two for displaying them. The buyer gets all three together.

Action functions sit across the three layers

Action functions are the cleanest place to see all three layers cooperating. The frame's button is bound to an action; the action is defined on the framework as a small node graph; running it writes ledger entries on the element. The action graph is authored visually inside the framework editor, the same way the rest of the framework is. There is no separate scripting layer.

Where to go from here

• If you are about to build something custom, pick the layer it most belongs to and start with the matching concept page: Frameworks, Elements, or Frames.
• If you are picking a tier so you can author your own content, the Subscriptions and tiers page covers what each tier unlocks for framework and frame authoring.
• If you are running a session right now and just want to get something done, the how-to guides in the sidebar are the fastest path. Concepts are for when something needs explaining, not for daily play.