Behavior Templates: reusable configuration patterns with full topology awareness

[JohnSL]

Context

Inspired by the LayoutCommandControl thread on "Node templates?" (June 2026). The thread explored how to share and reuse node configurations, and concluded that naive clone/replace approaches break as soon as cross-node event relationships are involved.

The Problem with Cloning

Tools that operate on a single backup file (like lcc-cdi-clone) can replace a node ID via search-and-replace, but:

• They can't see the other side of cross-node event links
• Replacing event IDs on one node severs or corrupts connections to other nodes
• The user must manually reconcile shared events — an O(producers × consumers) problem
• They don't help with the hard part: programming logic blocks

Why Bowties Can Do This Differently

Bowties already has the full layout topology: every node, every configured event, who produces and consumes what, and what's unallocated. This means it can apply configuration patterns correctly across multiple nodes — it doesn't have to guess or ask the user to manually reconcile.

Proposed Approach: Behavior Templates

Instead of cloning nodes, Bowties would work with behavior templates — reusable patterns that capture what a configuration accomplishes rather than the raw state of a specific node.

Key concepts:

1. Information Channels — a higher-level abstraction over raw event IDs. "Block occupancy" is one information channel implemented by two events (occupied/clear). Users think in terms of information, not event pairs. Templates work at this level.

2. Two template types:

   • Hardware templates — declare physical configuration (daughter boards, pin modes). Trigger automatic creation of typed information channels. "BOD-8 on Connector A" → 8 occupancy channels appear, ready to be named.
   • Behavior templates — compose existing channels into functional patterns via logic. "ABS 3-Aspect Signal Block" → takes occupancy channels as inputs, programs the logic that determines signal aspect, outputs to signal channels.

3. Logic blocks are first-class — behavior templates include the logic programming (TowerLCC logic blocks, TowerLCC+Q STL). This is where the real cognitive load lives and where templates provide the most value. The expert writes the signal engineering once; users apply it by selecting their channels.

4. Composable, not monolithic — templates claim specific resources on nodes (pins, logic lines) without owning the whole node. Multiple templates can coexist on one node. One template can span multiple nodes. A "facility" is the named result of applying a template — a higher-level grouping for understanding your layout.

5. Hardware first, then behavior — set up daughter boards (creating typed channels), then apply behavior templates that compose those channels. The behavior template never dictates hardware — it just declares "I need a block-occupancy channel" regardless of how it was created.

What the User Experience Looks Like

1. Assign daughter boards → information channels auto-created with default names
2. Rename channels ("Block 7 Occupancy", "Eagle Creek Turnout")
3. Browse behavior templates by intent ("I want ABS signaling")
4. Template shows what it needs — select matching channels from your layout
5. Assign logic resources → template programs the logic
6. Done — facility created, everything wired correctly, printable pin documentation available

Addressing the Discussion's Concerns

Concern	How this addresses it
Cross-node links break with replace (Balazs, Paul)	Full topology visibility — Bowties sees both sides
Templates should be partial, not whole-node (Dana)	Templates claim resources, not nodes — compose freely
Parameterized with named events (David)	Information channels are the named parameters
Average user never touches event IDs (Jim)	Templates + auto-created channels handle it all
Sharing configs between users (Dwight)	Templates are shareable files

Questions for Discussion

1. What common behaviors would be most valuable as shipped templates? (ABS, CTC, approach lighting, route interlocking?)
2. Are there boards where the logic model doesn't fit this pattern?
3. For those familiar with TowerLCC STL — is parameterized STL (with event ID substitution points) practical, or are there structural barriers?
4. What should we call the "facility" concept? (A live instance of applied behavior — "Eagle Creek Siding" as a named grouping of channels, logic, and resources.)
5. JMRI layout model integration — JMRI maps LCC events to its own Sensors, Turnouts, SignalHeads, etc. for panel display and automation. When Bowties creates information channels with specific event IDs via templates, how should the corresponding JMRI objects get created? This is a future research area — not blocking the template design, but worth considering.

Full Proposal

Detailed writeup covering all aspects (information channel types, template anatomy, abstraction hierarchy, hardware tiers, workflows for capture and apply, logic block integration, pin documentation, and more):

specs/proposals/behavior-templates-proposal.md