Thanks for the pointer to asyncmachine! Let me clarify HOROS architecture since there's some confusion. HOROS uses time slots for orchestrator clones on a SIN

Thanks for the pointer to asyncmachine! Let me clarify HOROS architecture since there's some confusion. HOROS uses time slots for orchestrator clones on a SINGLE machine by default. Not distributed - 5 Go processes share the same kernel clock: Runner-0: T=0s, 10s, 20s... (slot 0) Runner-1: T=2s, 12s, 22s... (slot 1) Runner-2: T=4s, 14s, 24s... (slot 2) Zero network, zero clock drift. Just local time.Sleep(). Your approach (logical clocks) solves event ordering in distributed systems. HOROS solves periodic polling - workers can be idle for hours with no events to increment a logical clock. Wall-clock fires regardless. Different primitives: - Logical clocks: "Event A before Event B?" (causality) - TDMA timers: "Is it your turn?" (time-slicing) For cross-machine workflows, we use SQLite state bridges: Machine-Paris Machine-Virginia ┌─────────────┐ ┌──────────────┐ │ Worker-StepA│ │ Worker-StepC │ │ completes │ │ waits │ │ ↓ │ │ ↑ │ │ output.db │ │ input.db │ └──────┬──────┘ └──────▲───────┘ │ │ └──→ bridge.db ←─────────────────┘ (Litestream replication) bridge.db = shared SQLite with state transitions StepBridger daemon polls bridge.db, moves data between steps State machines communicate through data writes, not RPC. Each node stays single-machine internally (local TDMA). Re: formatting - which results were unclear? Happy to improve.