IncidentMesh

What it does

IncidentMesh is a concurrent incident-response prototype built on Mozaik. Trace, Dependency, and Impact investigate the same incident while an Action Controller may already be planning a response. The key idea is simple: a plan can become wrong while it is still being generated. Every plan remembers the evidence revision it used. If another responder changes the evidence before the plan reaches the action boundary, the old plan is rejected as stale. The repo includes an authenticated Gemini run with 1,389 ms of three-way provider-call overlap, a controlled concurrent-vs-serialized experiment, real Mozaik interception of rollback_production into request_corroboration, and a 10,000-case safety stress test. The demo uses proposal-only tools and never modifies production.

How the agents run concurrently

One incident.opened event wakes Trace, Dependency, and Impact together. They run independently and publish evidence into shared IncidentState. In one historical authenticated Gemini Flash-Lite run, all three provider calls were simultaneously in flight for 1,389 ms. Meanwhile, the Action Controller can already be planning. If it starts at revision 1 and other responders advance the evidence to revision 3 before it finishes, its revision-1 plan is stale and cannot cross the action boundary. The controlled ablation keeps the incident, eventual evidence, planner, policy, target, and candidate action the same. Only scheduling changes. With concurrent peers, the plan becomes stale before the boundary. With serialized peers, the same bounded proposal is still fresh at that point and can cross as a proposal-only diagnostic. Destructive rollback remains blocked in both cases. That is why concurrency matters here: it changes which decisions are still valid.