Addendum 02 (State Machines): A Cross-Platform “Hello State Machine”

Supplementary Use Case to the Main BRCC Paper

1. Introduction

State machines are a ubiquitous tool for modeling systems with well-defined states and transitions—ranging from workflow engines to embedded device controllers. This addendum demonstrates how Business Rule Completeness Conjecture (BRCC) principles can be applied to state machine definitions, reducing the ripple effect caused by syntax-locked implementations and facilitating seamless updates or expansions over time.

Key Insight

• BRCC encourages defining the what (states, transitions, triggers) in a single, declarative form.

• Each environment’s how (execution logic or syntax) can be automatically derived from that core definition.

• By eliminating manual rewrites, teams can quickly adapt to new requirements and maintain consistency across multiple platforms or programming languages.

2. Declarative “Rulebook” for State Machines

Following BRCC’s five primitives—Schema (S), Data (D), Lookups (L), Aggregations (A), Calculated Fields (F)—we can store state machine information in an ACID-compliant datastore in a JSON-like format. This separates the design-time semantics from the implementation details:

1. Schema (S)

   • The structure of states, transitions, and triggers.

2. Data (D)

   • Specific state names, event triggers, or other parameters.

3. Lookups (L)

   • References among states or transitions.

4. Aggregations (A)

   • Potential roll-ups or composite behaviors (not shown here, but can be added for complex event logic).

5. Calculated Fields (F)

   • Derived information about states (e.g., “isFinal,” “hasTimedOut,” etc.).

3. Example: A Simple Workflow

Below is an illustrative JSON file, stateMachine.json, capturing a trivial three-state workflow:

json


Copy

{

  "name": "ExampleStateMachine",

  "states": [

    { "name": "Start", "type": "initial" },

    { "name": "InProgress", "type": "intermediate" },

    { "name": "Completed", "type": "final" }

  ],

  "transitions": [

    { "from": "Start", "to": "InProgress", "trigger": "StartWork" },

    { "from": "InProgress", "to": "Completed", "trigger": "CompleteWork" }

  ],

  "metadata": {

    "description": "A simple workflow for a task from start to completion."

  }

}

• States: Listed with their roles (initial, intermediate, final).

• Transitions: Each includes a “from” state, a “to” state, and a “trigger.”

• Metadata: Additional context (e.g., descriptions, version info).

4. Generating Code Snippets

A templating engine such as Handlebars can convert the above JSON definition into environment-specific implementations. Below is a simplified Python example using the transitions library.

4.1 Handlebars Template (Python / transitions)

handlebars


Copy

from transitions import Machine


class {{name}}(object):

    states = [

    {{# each states}}

        '{{name}}'{{# unless @last}}, {{/unless}}

    {{/each}}

    ]


    def __init__(self):

        self.machine = Machine(

            model=self,

            states={{name}}.states,

            initial='{{states.[0].name}}'

        )


        {{# each transitions}}

        self.machine.add_transition(

            trigger='{{trigger}}',

            source='{{from}}',

            dest='{{to}}'

        )

        {{/each}}

4.2 Example Usage

python


Copy

# Instantiate the state machine

workflow = ExampleStateMachine()


# Trigger a transition from 'Start' to 'InProgress'

workflow.StartWork()


# Trigger a transition from 'InProgress' to 'Completed'

workflow.CompleteWork()

5. Benefits and Observations

1. Centralized State Logic

   • All states and transitions live in one JSON file, eliminating the need to modify multiple codebases when logic evolves.

2. Fewer Ripple Effects

   • Updating the name of a trigger or adding a new state only requires changing the JSON definition—no manual rewrites in each language.

3. Easier Testing and Validation

   • With a declarative approach, QA teams can run automated checks on the JSON directly (e.g., ensuring no unreachable states), independent of specific runtime implementations.

4. Interoperability

   • By generating code for different programming environments from one source of truth, mixed-tech stacks can share the same state logic consistently.

5. Scalability

   • In more complex systems, additional layering (e.g., nested states, composite transitions) is still captured in the JSON. Advanced constructs (guards, conditions, dynamic transitions) map naturally to BRCC’s primitives.

6. Conclusion

Applying BRCC to state machines showcases how a single declarative rulebook can unify logic across diverse platforms. This approach mirrors the strengths highlighted in the main paper—minimizing manual synchronization, accelerating iteration, and enabling consistent, transparent evolution of the system’s stateful behaviors. While simple at first glance, this example points toward powerful transformations in how teams define, maintain, and deploy stateful logic at scale.

Citation

Addendum 02 (State Machines): A Cross-Platform “Hello State Machine.” In Business Rule Completeness Conjecture: Foundations & Falsifiability, 2025.