Composable Information Machine (CIM): State Machines

Summary

Mealy State Machines are integrated into the CIM architecture for event generation based on message state transitions.

Overview

In a Mealy State Machine, each state transition is governed by both an input and an output. In the context of CIM, the inputs are Messages—comprising Commands, Queries, and Events—and the outputs are Events generated as a result of the message processing.

States as Homotopy Types

Homotopy is a way of classifying geometric regions by studying the different types of paths that can be drawn in the region.

Each state in the Mealy State Machine can be considered a Homotopy Type. This classification of states into types enables a rigorous, mathematical framework for reasoning about the system's behavior. Moreover, state transitions can be viewed as morphisms between these types.

Functional Morphisms for State Transitions

Each transition function (or morphism) should adhere to the standards of a Grothendieck construction, ensuring a strict and well-defined transition process. For example, a message in state A triggering a transition to state B would involve a morphism f: A -> B.

Event Generation Process

Message Reception: Upon the receipt of a message, an MessageReceived event is generated as the initial output. This event also serves to log the incoming message for tracking and auditing purposes.
Authorization: The message undergoes an authorization check.
- For Commands, this produces a CommandAuthorized event.
- For Queries, a QueryAuthorized event is generated.
State Transition and Event Emission: The authorized message initiates a state transition, effectively triggering another morphism that reflects the change from one Homotopy Type to another. An associated MessageProcessed event is emitted to signify this transition.
Persistence: Finally, the new state is persisted, and a MessagePersisted event is generated.

Communication Architecture

CIM employs a gossip protocol to disseminate messages across its internal network. Each node in this network hosts a messenger service managed by systemd and NixOS. This decentralized approach ensures that the Mealy State Machine's transitions and event generations are consistent across all instances.

Properties of the CIM Model with Mealy State Machines

Functional Integrity: The system is structured so that each state and each transition function (morphism) adheres to functional programming paradigms. This facilitates easier reasoning and proofs about the system's behavior.
Immutability: All events are immutable and uniquely identified via CIDs (Content Identifiers), contributing to the integrity and traceability of the system.
Modularity: Following the UNIX philosophy of "Do one thing and do it well," each module in the system is designed to handle a specific function or process, reinforcing the principles of modularity and separation of concerns.

In summary, the integration of Mealy State Machines into the CIM architecture offers a structured, mathematical, and functional approach to event generation based on message state transitions.

Mealy State Machine for Messages

States:

New: When a message is just created.
Serialized: Post-serialization.
Deserialized: Post-deserialization.
Sent: Message sent.
Received: Message received.
Acknowledged: Acknowledgment received.
Failed: Processing or sending failed.
Persisted: Saved for auditing or debugging.

Transitions:

New -> Serialized: Triggered by MessageSerialized
Serialized -> Sent: Triggered by MessageSent
Sent -> Received: Triggered by MessageReceived
Received -> Acknowledged: Triggered by MessageAcknowledged
Any -> Failed: Triggered by MessageFailed
Any -> Persisted: Triggered by MessagePersisted

Mealy State Machine for Commands

States:

Issued: Initial sent state.
Validated: Post-validation.
Authorized: Post-authorization.
Processed: Successfully carried out.
Rejected: Failed validation or execution.

Transitions:

Issued -> Validated: Triggered by CommandValidated
Validated -> Authorized: Triggered by CommandAuthorized
Authorized -> Processed: Triggered by CommandProcessed
Any -> Rejected: Triggered by CommandRejected

Mealy State Machine for Queries

States:

Made: Initial sent state.
Validated: Post-validation.
Authorized: Post-authorization.
Processed: Query execution complete.
Responded: Response sent back.

Transitions:

Made -> Validated: Triggered by QueryValidated
Validated -> Authorized: Triggered by QueryAuthorized
Authorized -> Processed: Triggered by QueryProcessed
Processed -> Responded: Triggered by QueryResponded

Each state machine will drive the state transitions of its corresponding message type based on the events listed.

State Graph

        graph TD;
        %% Message State Machine
        subgraph "Message State Machine"
            MNew[New]
            MSer[Serialized]
            MDes[Deserialized]
            MSent[Sent]
            MRec[Received]
            MAck[Acknowledged]
            MFail[Failed]
            MPers[Persisted]

            MNew -->|MessageSerialized| MSer
            MSer -->|MessageSent| MSent
            MSent -->|MessageReceived| MRec
            MRec -->|MessageAcknowledged| MAck
            MNew -->|MessageFailed| MFail
            MSer -->|MessageFailed| MFail
            MSent -->|MessageFailed| MFail
            MRec -->|MessageFailed| MFail
            MAck -->|MessageFailed| MFail
            MNew -->|MessagePersisted| MPers
            MSer -->|MessagePersisted| MPers
            MSent -->|MessagePersisted| MPers
            MRec -->|MessagePersisted| MPers
            MAck -->|MessagePersisted| MPers
        end

        %% Command State Machine
        subgraph "Command State Machine"
            CIssued[Issued]
            CVal[Validated]
            CAuth[Authorized]
            CProc[Processed]
            CRej[Rejected]

            CIssued -->|CommandValidated| CVal
            CVal -->|CommandAuthorized| CAuth
            CAuth -->|CommandProcessed| CProc
            CIssued -->|CommandRejected| CRej
            CVal -->|CommandRejected| CRej
            CAuth -->|CommandRejected| CRej
        end

        %% Query State Machine
        subgraph "Query State Machine"
            QMade[Made]
            QVal[Validated]
            QAuth[Authorized]
            QProc[Processed]
            QRes[Responded]

            QMade -->|QueryValidated| QVal
            QVal -->|QueryAuthorized| QAuth
            QAuth -->|QueryProcessed| QProc
            QProc -->|QueryResponded| QRes
        end

State Diagram

        stateDiagram
        %% Message State Machine
        [*] --> New : Message State Machine
        New --> Serialized : MessageSerialized
        Serialized --> Sent : MessageSent
        Sent --> Received : MessageReceived
        Received --> Acknowledged : MessageAcknowledged
        New --> Failed : MessageFailed
        Serialized --> Failed : MessageFailed
        Sent --> Failed : MessageFailed
        Received --> Failed : MessageFailed
        Acknowledged --> Failed : MessageFailed
        New --> Persisted : MessagePersisted
        Serialized --> Persisted : MessagePersisted
        Sent --> Persisted : MessagePersisted
        Received --> Persisted : MessagePersisted
        Acknowledged --> Persisted : MessagePersisted
        
        %% Command State Machine
        [*] --> Issued : Command State Machine
        Issued --> Validated : CommandValidated
        Validated --> Authorized : CommandAuthorized
        Authorized --> Processed : CommandProcessed
        Issued --> Rejected : CommandRejected
        Validated --> Rejected : CommandRejected
        Authorized --> Rejected : CommandRejected
    
        %% Query State Machine
        [*] --> Made : Query State Machine
        Made --> Validated : QueryValidated
        Validated --> Authorized : QueryAuthorized
        Authorized --> Processed : QueryProcessed
        Processed --> Responded : QueryResponded