FSM Duality Framework: Payment & Service Cycles¶

Overview¶

The ABS Platform implements a Mealy Finite State Machine (FSM) duality where Payment_Cycle and Service_Cycle operate as mirrored state machines that drive the entire platform's behavior. This framework uses the standardized Mealy FSM formalism with explicit typing and full validation, ensuring that financial and operational states are always synchronized and that every action emits signals that trigger state changes across the system.

Core Concept: Service ↔ Payment Duality¶

The Fundamental Principle¶

Services are what customers consume
Payments are what customers provide
One cannot exist without the other - this duality permeates the entire platform
Every service action has a corresponding payment implication
Every payment action has a corresponding service implication

FSM Architecture¶

1. Payment_Cycle (Financial State Machine)¶

Purpose: Manages the financial relationship between customer and service provider

States: - UP_TO_DATE - All payments current - PAR30 - Payment 30+ days past due - PAR60 - Payment 60+ days past due
- PAR90 - Payment 90+ days past due - OVERDUE - Payment severely overdue

State Transitions:

UP_TO_DATE → PAR30 → PAR60 → PAR90 → OVERDUE
     ↑                                    ↓
     ←────────── Payment Received ←─────────

Signals Emitted: - PaymentReceived → Service_Cycle - PaymentOverdue → Service_Cycle - PaymentFailed → Service_Cycle

2. Service_Cycle (Operational State Machine)¶

Purpose: Manages the operational service delivery to customers

States: - PENDING_ACTIVATION - Service plan created, awaiting payment - ACTIVE - Service is operational and available - SUSPENDED_PAYMENT - Service suspended due to payment issues - SUSPENDED_QUOTA - Service suspended due to quota exhaustion - EXPIRED - Service period has ended - CANCELLED - Service permanently terminated

State Transitions:

PENDING_ACTIVATION → ACTIVE → SUSPENDED_PAYMENT → ACTIVE
     ↓                    ↓           ↓
  EXPIRED ←─────────── SUSPENDED_QUOTA ←───────────
     ↓
  CANCELLED

Signals Emitted: - ServiceActivated → Payment_Cycle - ServiceSuspended → Payment_Cycle - ServiceResumed → Payment_Cycle - ServiceExpired → Payment_Cycle

Signal-Driven State Synchronization¶

Cross-FSM Signal Flow¶

Payment_Cycle                    Service_Cycle
     │                               │
     ├─ PaymentReceived ──────────────┤
     │                               │
     ├─ PaymentOverdue ──────────────┤
     │                               │
     ├─ PaymentFailed ───────────────┤
     │                               │
     ├─ ServiceActivated ←───────────┤
     │                               │
     ├─ ServiceSuspended ←───────────┤
     │                               │
     └─ ServiceExpired ←─────────────┘

Signal Types and Effects¶

Payment → Service Signals¶

PaymentReceived
Trigger: Payment_Record created with COMPLETED status
Effect: Service_Cycle transitions to ACTIVE
Action: Enable service access, unlock assets
PaymentOverdue
Trigger: Payment_Cycle status changes to PAR30/PAR60/PAR90
Effect: Service_Cycle transitions to SUSPENDED_PAYMENT
Action: Disable service access, lock assets
PaymentFailed
Trigger: Payment_Record created with FAILED status
Effect: Service_Cycle transitions to SUSPENDED_PAYMENT
Action: Immediate service suspension

Service → Payment Signals¶

ServiceActivated
Trigger: Service_Cycle transitions to ACTIVE
Effect: Payment_Cycle remains UP_TO_DATE
Action: Start billing cycle
ServiceSuspended
Trigger: Service_Cycle transitions to SUSPENDED_PAYMENT
Effect: Payment_Cycle status may change based on payment history
Action: Pause billing, send payment reminders
ServiceExpired
Trigger: Service_Cycle transitions to EXPIRED
Effect: Payment_Cycle may transition to OVERDUE
Action: Final billing, renewal offers

Record Types as FSM Traces¶

Payment_Record¶

Purpose: Trace of all financial transactions
FSM Context: Records state transitions in Payment_Cycle
Signal Generation: Each record can emit signals to Service_Cycle
Examples:
Payment received → PaymentReceived signal
Payment failed → PaymentFailed signal
Payment overdue → PaymentOverdue signal

Service_Record¶

Purpose: Trace of all service consumption events
FSM Context: Records state transitions in Service_Cycle
Signal Generation: Each record can emit signals to Payment_Cycle
Examples:
Service accessed → ServiceAccessed signal
Quota exhausted → ServiceSuspended signal
Service completed → ServiceCompleted signal

Implementation Benefits¶

1. State Consistency¶

Payment and Service states are always synchronized
No orphaned states where payment is current but service is suspended
Clear causality between financial and operational events

2. Event-Driven Architecture¶

All state changes are triggered by explicit events
Easy to trace the cause of any state change
Enables complex business rules through signal routing

3. Scalability¶

Each FSM can be implemented independently
Signals provide loose coupling between systems
Easy to add new state machines (e.g., Asset_Cycle, Maintenance_Cycle)

4. Audit Trail¶

Complete trace of all state transitions
Clear relationship between actions and state changes
Enables compliance and debugging

Battery Swap Business Application¶

Payment_Cycle States for Battery Swap¶

UP_TO_DATE - Customer has paid for swap plan
PAR30 - Monthly payment overdue
PAR60 - Payment severely overdue
OVERDUE - Account suspended

Service_Cycle States for Battery Swap¶

PENDING_ACTIVATION - Plan purchased, awaiting first swap
ACTIVE - Customer can perform battery swaps
SUSPENDED_PAYMENT - Swaps blocked due to payment issues
SUSPENDED_QUOTA - Monthly swap limit reached
EXPIRED - Plan period ended
CANCELLED - Plan terminated

Signal Examples for Battery Swap¶

PaymentReceived → Enable battery swap access
PaymentOverdue → Disable battery swap access
SwapCompleted → Update usage quota
QuotaExhausted → Suspend service until next cycle

Future Extensions¶

Additional FSMs¶

Asset_Cycle: Manages asset availability and health
Maintenance_Cycle: Manages maintenance schedules
Customer_Cycle: Manages customer lifecycle

Signal Routing¶

Event Bus: Central signal routing system
Signal Filters: Route signals based on business rules
Signal Aggregation: Combine multiple signals for complex decisions

This FSM duality framework provides the foundation for a robust, scalable, and maintainable ABS Platform where every action has clear financial and operational implications.