System Overview — How Barmus Systems executes operational decisions

1 — System overview

What Barmus is, precisely.

Barmus is a constraint orchestration layer for operational systems. It receives events from your order intake system, evaluates them against a live constraint model, allocates resources, and emits decisions back to your execution stack — all within a single synchronous cycle.

It does not store your operational data permanently. It does not replace your OMS or ERP. It reads state, evaluates constraints, commits decisions, and propagates state changes — then returns control to your systems.

The three modules — Logistics (L1), Connect (L2), Care+ (L3) — are causally coupled: a decision committed at L1 constrains the L2 execution context. A state change at L2 is immediately visible to L3. Each module can be deployed independently, but state propagation only occurs when modules are connected.

// Barmus sits here in your stack [ Order intake ] → WooCommerce / custom API / ERP ↓ [ Barmus L1 ] → Constraint evaluation · resource allocation · slot commit ↓ [ Barmus L2 ] → Route optimization · fleet state · driver dispatch ↓ [ Barmus L3 ] → Interaction resolution · customer updates · escalation ↓ [ Your systems ] → Storefront availability · driver app · customer comms

2 — Architecture diagram

Inputs, processing layers, outputs.

The diagram below shows the full data flow — what enters the system, what each layer processes, and what it emits.

3 — Module breakdown

What each layer does, precisely.

Logistics L1 · Core · Required Supply chain & production constraint engine

Logistics maintains a live constraint graph over production capacity, resource availability, and order state. Every booking request is evaluated against this graph before commitment. If the constraint graph permits the commitment, it is executed atomically. If not, the request is rejected at the boundary — no partial states, no silent failures.

The allocation engine assigns couriers using a temporal availability matrix scored by proximity (via Google Distance Matrix), current run load, and zone capacity. The same engine validates order modifications — a change request triggers a full re-evaluation of the slot, resource, and delivery chain.

Atomic slot commit Availability matrix Distance-weighted scoring Modification re-evaluation Multi-site support Hotspot topology

Connect L2 · AI · Add-on Route optimization & fleet state layer

Connect receives committed delivery assignments from L1 and enters them into a continuous optimization loop. The AI routing model recomputes run composition and sequence as new assignments arrive and fleet state evolves — it does not produce a static plan at dispatch time.

Fleet state is maintained as a live graph of all active nodes: drivers, active runs, and individual delivery states. This graph is the shared state source for both optimization and L3 resolution queries. State changes propagate bidirectionally to L1 (resource availability updates) without polling.

Continuous optimization Live fleet graph Bidirectional L1 feedback Driver mobile app Proof-of-delivery capture ETA propagation

Care+ L3 · AI · Add-on Interaction resolution layer

Care+ resolves inbound customer interactions against live L1 and L2 state. There is no static response model — query responses are computed from actual order state, fleet position, and constraint graph data at the moment of the request.

Executable requests (modifications, cancellations) are passed directly to the L1 mutation engine for constraint validation. If the mutation is feasible, it is committed and the customer is notified. If not, the request is rejected with context. Resolution terminates at state change, not at acknowledgment. Cases outside the resolution scope are escalated with a full context package pre-loaded.

Live state binding Direct mutation execution Contextual escalation Multi-channel Proactive notifications

4 — Decision engine logic

How constraints are evaluated and resolved.

Every decision in Barmus follows the same pattern: evaluate → score → commit or reject. There is no fuzzy logic, no silent overcommit, no eventual reconciliation. If a constraint is violated, the request is rejected at the boundary with a reason code.

// L1 constraint evaluation cycle — simplified function evaluate_booking_request(order, requested_slot) { // 1. Check slot capacity slot = get_slot(requested_slot.interval, requested_slot.site, order.product) if slot.remaining_capacity <= 0: return REJECT("slot_capacity_exhausted") // 2. Score available resources couriers = get_available_couriers(requested_slot.window) scored = score_by_proximity(couriers, order.delivery_address) if scored.is_empty(): return REJECT("no_available_resource") // 3. Validate delivery feasibility travel_time = google_distance_matrix(scored.best.location, order.delivery_address) if travel_time > slot.window_remaining: return REJECT("delivery_window_infeasible") // 4. Atomic commit commit_slot(slot, order) // locks capacity assign_resource(scored.best, order) // updates availability matrix emit("assignment.committed") // propagates to L2 return ACCEPT(assignment) }

Override behavior: human operators retain full override capability on any assignment. An override does not bypass constraint logging — it records the override reason and the state delta. The constraint model is not retroactively updated by overrides; overrides are tracked separately as operational exceptions.

Modification re-evaluation: when an order modification is requested, the engine re-runs the full constraint cycle on the new parameters. If the modified slot is feasible, the commit is executed atomically across production, allocation, and delivery layers. If not, the request returns the specific constraint that blocked it.

5 — Integration model

How Barmus connects to your stack.

Barmus connects at the API and webhook level. It does not require schema changes, data migrations, or platform replacements. Your existing systems continue to operate as before — Barmus layers on top of them.

The integration surface is intentionally minimal: three inbound webhook endpoints and two outbound API surfaces. Everything Barmus needs to evaluate constraints is fetched at request time via these surfaces, not replicated into a separate data store.

Direction	Endpoint	Payload	Trigger
Inbound	`POST /events/order.created`	Order ID, product, address, requested slot	New order placed in OMS
Inbound	`POST /events/order.modified`	Order ID, modified fields, requested new slot	Customer or ops modifies order
Inbound	`POST /events/order.cancelled`	Order ID, cancellation reason	Order cancelled, resources released
Outbound	`GET /slots/availability`	Available slots by product/site/date	Storefront availability query
Outbound	`GET /delivery/eta/:orderId`	Live ETA derived from fleet graph	Customer-facing ETA request

Authentication: all endpoints use HMAC-signed webhook payloads (inbound) and bearer token authentication (outbound). Credentials are scoped per deployment and rotated on request.

Deployment time: typical integration takes 4–8 hours of engineering time. The constraint model configuration (capacity rules, resource parameters, zone definitions) is done through a guided onboarding process that typically takes an additional 2–4 hours.

6 — System boundaries

What Barmus guarantees — and what it does not.

This section is important. Barmus makes specific guarantees about system behavior. It also has explicit limitations. Understanding both is required for accurate technical evaluation.

System guarantees

No structural slot overcommitSlot capacity is checked and locked atomically. Concurrent requests cannot both commit to a full slot.

Constraint consistency across modulesA state change in L1 is reflected in L2 and L3 before the next decision cycle. No stale reads across modules.

Rejection with reason codeEvery rejected request returns the specific constraint that blocked it — not a generic error.

Human override capabilityOperators retain full manual override on any assignment or route, with full audit logging.

Modification atomicityA feasible modification is committed across all three layers simultaneously. Partial updates do not persist.

99.97% uptime SLAContractual SLA with compensation clauses. Measured against the constraint evaluation API surface.

What Barmus does not guarantee

Perfect route optimizationConnect's AI minimizes total travel time under live constraints. It does not guarantee the mathematically optimal route — doing so at scale is NP-hard and computationally prohibitive.

Zero human interventionEdge cases exist that the constraint model cannot fully anticipate. Manual override is expected 2–5× per week in typical deployments.

100% Care+ resolution~3% of inbound interactions require human handling. These are predominantly multi-order account disputes or billing issues outside the system's state model.

Deterministic ETA accuracyETAs are computed from live fleet state and Google Distance Matrix. Traffic anomalies and driver deviations introduce variance that cannot be fully eliminated.

Operational completeness without L1L2 and L3 can be deployed independently but operate with reduced capability. L1 is the constraint data source for both; without it, state binding is partial.

7 — Failure modes & fallback behavior

What happens when things go wrong.

Barmus is designed to fail gracefully. Each module is independently resilient — a failure in L3 does not affect L1 or L2 operation. The table below describes the most common failure scenarios and their system behavior.

Scenario System behavior Recovery path

Google Distance Matrix API timeout

Scoring falls back to straight-line distance estimates. Slot feasibility check still runs — it uses cached zone travel-time averages. Assignment proceeds with a reduced confidence score.

→ Automatic retry on next cycle. Full scoring resumes when API responds. No manual intervention required.

L2 (Connect) module offline

L1 continues processing bookings and assignments. The fleet graph is paused — no new route optimization cycles run. Assignments are committed to L1 but not yet dispatched to drivers.

→ Manual dispatch available via L1 admin console. L2 resumes automatically on reconnection and processes queued assignments in order.

Slot capacity misconfiguration

If configured capacity exceeds actual kitchen throughput, the constraint model will accept bookings that production cannot fulfill. Barmus enforces configured constraints — it does not independently validate physical capacity.

→ Capacity parameters must be set accurately at onboarding. Barmus provides a capacity calibration tool during the first two weeks of operation.

Care+ L3 AI resolution failure

If the resolution engine cannot confidently classify an interaction, it escalates immediately rather than guessing. The escalation package includes the full interaction transcript and a suggested resolution path.

→ Human agent receives pre-populated context. Average resolution time post-escalation: <4 minutes.

Inbound webhook delivery failure

Barmus does not receive the order event. The OMS order exists but has no Barmus assignment. The storefront will not reflect slot closure for this order.

→ Webhook retry logic in OMS (standard WooCommerce behavior). Manual re-sync available via Barmus admin API. Monitoring alert fires if delivery failure rate exceeds 0.1%.

A full runbook for each failure mode — including monitoring thresholds, escalation contacts, and manual recovery procedures — is provided during onboarding and updated with each module release.

Technical questions not covered here are addressed in the integration scoping call. Our engineering team maps your specific stack and constraint model before any deployment commitment.

Request a technical evaluation See live results →