Cynario Cynario alpha
Browse docs

Concepts

Reuse — Logic Blocks & the Workspace Library

Build something once, use it everywhere. The three reusable nouns (Logic Block, Component, Blueprint), how they live as definitions in the Workspace Library, the inputs you fill in, the full action set (Make, Place, Override, Detach, Push, Swap, Find usages, Rename — never "Extract"), and what real-time collaboration means for a local-first builder.

On this page

You will build the same thing more than once. The same “if you skip the briefing, lose 5 points” rule. The same hotspot-and-feedback pattern. The same scored gate that picks an ending. Reuse is how you build it once, keep it in one place, and have every copy stay in step when you change your mind.

This page is the last of the five concept pages. It assumes you already know the spine:

  • A Scenario is a graph of Scenes, each built on one shared Scene source — see The Scene (the Scene source).
  • That Scene source is markup-centric: Markup, with Bindings (read-only templating) and Logic embossed from it — abstractions that rise out of the one Scene source, not co-equal layers you tab between.
  • Logic is one rule shape, WHEN <trigger> [IF/WHILE <condition>] DO <effects>, where every effect changes exactly one of three things — Memory, Content, or Context — see Logic: Triggers, Conditions, Effects.
  • The Playthrough log is the single source of truth — see The Truth Model.

Reuse sits on top of all of that. It does not add a new kind of behavior. It is a way of naming a piece of your scenario so you can use it again without copying it.


The three reusable nouns

There are exactly three things you can save for reuse. They differ only by what’s inside them.

NounWhat’s insideReach for it when…
Logic BlockJust rules — a pack of WHEN/IF/DOYou want the same behavior in many places (a scoring rule, a penalty).
ComponentContent and logic, bundled togetherYou want the same thing on the page — a hotspot plus the rule it fires.
BlueprintA curated, fill-in-the-form presetYou want a proven starting recipe and just need to fill in the blanks.

Logic Block — a reusable rule pack

A Logic Block is a pure pack of rules: one or more WHEN <trigger> [IF/WHILE <condition>] DO <effects> rules with no content attached. It’s the right home for behavior you repeat — “subtract 5 from score and show the warning block,” “the moment alarmsTriggered reaches 3, go to the lockdown Scene.”

A Logic Block writes through the same three effect families as any other rule — Memory, Content, or Context (this is the whole alphabet of effects; there is no second axis). When you place a Logic Block, you are placing rules, not pixels.

Component — a content + logic bundle

A Component bundles content and logic together. The classic example is a hotspot: the clickable region (Markup), the bit of text that explains it (Markup + a Binding that reads {score}), and the rule that fires when you click it (Logic). Bundle those once as a Component and you can drop the whole hotspot — look and behavior together — onto any Scene.

A Component is the bigger of the two author-made units: a Logic Block is rules only, a Component is rules plus what’s shown.

Blueprint — a curated fill-in-the-form preset

A Blueprint is a curated preset — a recipe Cynario (or your team) ships ready to use. You don’t build a Blueprint by selecting things on a Scene; you pick it off a shelf and fill in a short form. Three shipped Blueprints:

  • Scored gate — “after this Scene, go to one ending if the score is high enough, otherwise the other.” Fill in: the score fact, the threshold, the two destination Scenes.
  • Hotspot triage — a set of clickable regions, each marking itself right or wrong and nudging the score. Fill in: the regions and which are correct.
  • Decision table — a tidy “if these facts, go here” table for branching on several conditions at once. Fill in: the rows.

A Blueprint is the friendly front door to reuse. Once placed, it’s just rules and content on your Scene like anything else — the form was only the way you got there.


Inputs: the blanks you fill in

Every reusable unit has inputs — the blanks you fill in each time you use it. A “lose points” Logic Block has an input for how many points and which fact. The scored-gate Blueprint has inputs for the threshold and the two destinations.

Inputs are what let one definition serve many situations. The same scoring Block is “the same Block, with these blanks filled in differently” on each Scene.

We call them inputs, or blanks to fill in. Never “parameters,” “props,” or “arguments” — those are programming words, and filling in a blank is not programming.

Inputs only fill the gaps the unit’s author left open. Everything else about the unit stays shared. That’s the point: change the shared part once, and every placement follows.


Where they live: the Workspace Library

Reusable units live in the Workspace Library — a panel in the Explorer, alongside your Scenes. It’s searchable, shows a preview of each unit, and lets you drag a unit onto a Scene or type to insert one.

The Library stores definitions. A definition is the one real copy — the source of truth for that Logic Block, Component, or Blueprint. Everywhere you use it, you place an instance: a lightweight, linked reference back to the definition, never a separate copy.

   Workspace Library (in the Explorer)
   ┌─────────────────────────────────┐
   │  DEFINITION  "Skip-briefing penalty"   ← the one real copy
   └─────────────────────────────────┘
            │ placed as linked instances (not copies)
     ┌──────┼───────────────┬───────────────┐
     ▼      ▼               ▼               ▼
   Scene A  Scene C        Scene F          Scene K
  instance instance      instance        instance
  (each may fill its inputs differently)

Edit the definition once, and every instance updates. That’s the whole payoff. Because an instance is a link rather than a copy, there’s nothing to chase down and re-do when you change your mind — the change flows to every place the unit is used. The only thing that varies per instance is the inputs you filled in there.

This mirrors the truth model elsewhere in Cynario: just as the engine keeps one log and rebuilds the screen from it, the Library keeps one definition and every placement reflects it. One source, many views.


The action set: what you can do with a Library object

A reusable unit is a first-class object with many actions, not a one-shot button. Here is the full set — these are the verbs you’ll see on a Logic Block, Component, or Blueprint:

ActionWhat it does
MakeTurn a selected rule, group, or content+logic selection into a reusable unit. The original stays right where it is and becomes the source.
Place / InsertDrop a linked instance onto a Scene (drag from the Library, or type to insert).
OverrideFill this instance’s inputs differently. The link stays intact — it’s still the same unit.
DetachBreak the link, turning this instance into plain inline rules/markup. Warned loudly — it can’t be undone, so try Override first.
Push to definitionSend a change you made on one instance up to the definition, so every instance gets it.
SwapPoint this instance at a different definition (e.g. swap “soft penalty” for “hard penalty”).
Find usagesList every Scene where this definition is placed.
RenameRename the definition everywhere at once.

A few of these deserve a closer look.

  • Make is promote in place. You select something you already built, and it becomes the source — the original doesn’t move or vanish. You are not cutting it out; you are naming it.
  • Override is how you customize without forking. Same definition, different blanks filled in. It’s the answer to “I need this almost everywhere, but slightly different here.”
  • Push to definition is the reverse flow: you tweaked one instance, decided it should be the new standard, and pushed it up so everyone gets it.
  • Detach is the escape hatch, and the only one with sharp edges. Once detached, the instance is just ordinary rules and markup with no link home — there’s no “re-attach.” Cynario warns before you do it and steers you toward Override first.

The word is always Make, never “Extract.” Extracting implies you’re carving a chunk out of your scenario and leaving a hole. You’re not — the original stays put; you’ve just given a piece of it a name and a home in the Library.


Grouping is not reuse

There’s one trap worth naming. While authoring conditions and rules, you’ll use group boxes — the indented and/or sub-boxes that say “these conditions belong together.” A group box is cosmetic: it sets precedence and keeps things tidy on screen. It is not a reusable object.

Grouping organizes what’s in front of you. Reuse creates a real Library object with a definition, instances, and the action set above. They look a little alike, so keep them straight: a group box is a visual bracket; a Logic Block is a thing in the Library. Putting rules in a group box does not make them reusable, and it never silently creates a copy.

If you find yourself rebuilding the same group of rules on Scene after Scene, that’s the signal to Make a Logic Block out of it.


A note on real-time collaboration

Cynario is local-first and shares peer-to-peer, so two authors editing the same Scenario at the same time is something the model has to handle — and reuse makes it easier, not harder.

  • One shared definition is safer to co-edit than many copies. When a Logic Block lives once in the Library and is placed as linked instances, two people editing it converge on the same unit. Copy-pasted logic, by contrast, drifts apart and there’s nothing to reconcile to. “Never copy on place” is both the clearer mental model and the one that survives two people typing at once.

  • Stable names under the hood. Every Scene, rule, effect, and Library definition+instance carries a stable internal identity, so when two authors’ edits come together, the builder always knows which rule or unit each change refers to. (You never see this; it’s the plumbing that makes co-editing and undo behave.)

  • Your edits, your undo. Undo is per-author — pressing undo rolls back your last change, never your collaborator’s. One shared undo stack would mean one person could undo another’s work; Cynario doesn’t do that.

  • Presence is separate and momentary. Live cursors, “who’s here,” and the highlight showing which rule a teammate is focused on are presence — they’re shown live but never saved into the Scenario. The Scenario itself (Scenes, rules, the Library) is what’s kept and merged; presence is the moment-to-moment overlay on top. This is the same persisted-vs-momentary split you already know from the truth model: facts in Memory are kept; what’s shown right now is rebuilt and leaves no mark.

You’ll see plain words for all of this — “everyone’s editing live,” “your cursor,” “who’s here,” “this is a shared Component.” The machinery underneath stays underneath.


In one breath

Build something once; name it; it lives in the Workspace Library as a definition. A Logic Block is reusable rules, a Component is reusable content + logic, a Blueprint is a fill-in-the-form preset. You Place linked instances, fill in their inputs, Override them locally, Push changes up, Swap one definition for another, Find usages, and Rename — and edit the definition once to update everywhere. Grouping tidies the screen; reuse makes a real object. And because there’s one shared definition instead of scattered copies, two authors can build the same Scenario together without stepping on each other.