Zephyr: Live Configuration Control Platform

Overview

Zephyr is the integration point where governance and execution converge. It merges Nimbus (configuration release workflows) and Murmur (real-time simulation) into a unified demonstration of how backend architecture decisions directly reshape observable behavior.

Rather than treating these as separate projects, Zephyr shows how thoughtfully architected systems integrate naturally. Nimbus and Murmur remain independent, but communicate through clean APIs, creating a platform where governance decisions are immediately visible in live behavior.

Why This Matters

Most organizations separate concerns: backend systems manage state, frontend systems display it. The relationship between the two often becomes implicit or obscured.

Zephyr makes this relationship explicit. When an engineer proposes a configuration change in Nimbus, approves it, and watches Murmur's behavior change in real-time, they see the direct causal link between architecture and outcomes.

This demonstrates:

• How backend governance shapes runtime behavior
• How systems designed independently can integrate without friction
• How infrastructure decisions become user-visible experiences
• How to architect platforms that evolve safely while remaining responsive

Core Idea

Zephyr is not a new system. It's a composition of two existing systems connected through clean APIs.

At each step, the user sees the causality. Governance is not abstract. It's immediately visible.

Architecture

System Composition

Zephyr consists of three layers:

Integration: From Governance to Execution

Step 1: Configuration Proposal

User fills out a form in the Nimbus panel:

• Separation force weight: 0.8
• Alignment force weight: 0.6
• Cohesion force weight: 0.5
• Max agent speed: 3.0
• Scene styling: [background color, agent color, etc.]

User clicks "Submit." Nimbus validates and stores the proposal.

Step 2: Approval Workflow

The configuration moves through Nimbus's workflow states:

• VALIDATING: Backend verifies all parameters are valid
• AWAITING_APPROVAL: Human reviewer sees the proposed changes
• APPLYING: System performs conflict detection (atomic transaction)
• COMPLETED: Configuration is now active

The user watches this unfold in real-time via SSE updates in the Nimbus panel.

Step 3: Event Broadcasting

When the configuration reaches COMPLETED state, Nimbus publishes an event:

This event is published to Nimbus's internal message queue, which the SSE handler broadcasts to all connected clients.

Step 4: Zephyr Parent Coordination

The Zephyr parent page maintains the SSE connection to Nimbus. When the config_activated event arrives, the parent page passes it to the Murmur iframe via postMessage

Step 5: Hot-Swap in Murmur

Murmur receives the new configuration. Rather than interrupting the simulation, it queues the update for the next frame boundary

At the frame boundary, all new configuration parameters are applied atomically. The steering system immediately begins using the new weights. Agent speed limits change. Scene styling updates.

Step 6: Observable Behavior Change

The user watches the simulation in the Murmur panel. The moment the configuration activates:

• Agent behavior visibly changes (new separation/alignment/cohesion balance)
• Speed limits take effect
• Scene styling updates
• Performance metrics might shift

All in real-time, all because of a governance decision made in Nimbus.

Communication Pattern

The key architectural pattern is unidirectional data flow:

No component knows about the others. Nimbus doesn't know Murmur exists. Murmur doesn't know about Nimbus's workflow. They communicate through:

• SSE (broadcast events)
• postMessage (iframe communication)
• Configuration objects (data contracts)

Why This Integration Works

Separation of Concerns

Nimbus handles governance. Murmur handles execution. Neither has dependencies on the other.

If you wanted to connect Zephyr to a different simulation (particles, network graphs, robotics), you would swap out Murmur's iframe. Nimbus remains unchanged.

Clean APIs

Systems communicate through well-defined events and data structures:

• Nimbus publishes: config_activated { version, params }
• Murmur consumes: same event, applies parameters
• Zephyr orchestrates: passes events between systems via postMessage

Deterministic Updates

Configuration changes are applied at frame boundaries in Murmur, ensuring consistent state throughout each frame. No race conditions, no partial updates.

Scalability

This pattern extends naturally:

• Add a third iframe (another simulation)
• Add performance analytics
• Add recording/playback
• Add multi-user collaboration

All without changing Nimbus or Murmur's core logic.

Tech Stack

Zephyr's tech stack is inherited from Nimbus and Murmur, with one addition:

What This Demonstrates

Platform Thinking

Zephyr shows how to build platforms, not single-purpose applications, but systems that:

• Compose independent pieces
• Communicate through clean APIs
• Remain flexible for future extensions
• Scale without architectural changes

Governance as User Experience

Configuration management isn't just backend infrastructure. When it's designed well, users experience governance directly. They see:

• Clear workflows (proposal to validation to approval)
• Immediate feedback (real-time status updates)
• Observable outcomes (simulation behavior changes)
• Auditability (all changes tracked and versioned)

System Integration Without Friction

Nimbus and Murmur were designed independently, with no knowledge of each other. Yet they integrate naturally because:

• Clean separation of concerns
• Well-defined APIs (events and data schemas)
• Thoughtful communication patterns (SSE, postMessage)

This is the hallmark of good architecture: new systems can be added with minimal coupling.

The Connection Between Architecture and UX

Every architecture decision becomes visible:

• Immutable configuration versioning leads to users being able to rollback safely
• Atomic transactions means no conflicts or partial updates
• Deterministic frame boundaries means smooth, consistent behavior changes
• SSE broadcasting means real-time updates without polling

Architecture isn't abstract. It's felt by users.

User Experience

The Zephyr interface is split 50/50:

The Flow:

1. User adjusts parameters in left panel
2. Clicks submit
3. Left panel shows workflow progression
4. When approved, right panel visibly changes
5. User adjusts agent count or moves mouse in right panel
6. Can propose another config change anytime

Status

Designed.

Architecture and system composition are documented and understood. Implementation depends on Nimbus and Murmur completion:

Integration points:

• Nimbus SSE endpoint exposes config_activated events
• Murmur iframe listens for postMessage events
• Zephyr shell routes events between systems

What This Represents

Together, the three projects form a complete narrative: