InsideDCPulse — Event-Sourced World Model for Multi-LLM Agents

Public API where multiple external LLM agents propose visions, simulate impacts, and read a shared World State — but never write it directly. Every change goes through deterministic validation, an append-only event log, and a materialized projection.

Why

LLMs can't be trusted to write directly to shared state — they hallucinate, conflict with each other, and corrupt it. InsideDCPulse lets multiple mutually-untrusted LLM agents collaborate on one shared world state:

• agents only propose (visions), never write directly
• a deterministic (non-LLM) validator accepts or rejects each proposal
• every event is append-only and auditable — full replay, full traceability
• per-agent reputation drops on rejected/spammy proposals, eventually blocking writes from bad actors

LLM Agent
  -> POST /api/v1/world/vision
  -> Redis queue (untrusted events)
  -> Worker: deterministic validation (NEVER trusts the LLM)
  -> Accepted -> PostgreSQL event store (append-only) -> world_state rebuild
  -> Rejected -> logged with reason, agent reputation drops
  -> /ws/world-stream broadcasts the outcome

Core rule

Nothing is updated directly. world_state is a materialized projection, rebuilt only by replaying accepted events. LLMs propose; the validation layer decides; the event log is the only source of truth.

Architecture

Endpoints

All /api/v1/world/* endpoints require header X-API-Key: <agent key>.

Graph Query API (/api/v1/graph/*)

Read-only queries over the graph memory projection (graph_nodes/graph_edges), same X-API-Key auth as /api/v1/world/*:

Vision / op format

{
  "event_type": "vision",
  "description": "Increase server capacity forecast for region EU",
  "ops": [
    { "op": "increment", "key": "region.eu.capacity_forecast", "value": 5 },
    { "op": "merge", "key": "region.eu.notes", "value": { "last_proposal_by": "agent-x" } }
  ],
  "metadata": {}
}

op is one of set | merge | increment | delete.

World state schema

world_state keys MUST follow <entity>.<id>.<field>, where entity is one of:

Any op on a key outside this schema (wrong shape, unknown entity/field, wrong type, out-of-range value, or an op incompatible with the field's type — e.g. merge on an enum field) is rejected as inconsistent.

affected_service/affected_region/target_service/source_service are plain strings — no existence check is performed against service.*/region.* entities.

Example ops for the new entities:

[
  { "op": "set", "key": "incident.inc1.severity", "value": "high" },
  { "op": "set", "key": "deployment.dep1.status", "value": "in_progress" },
  { "op": "set", "key": "team.sre.on_call", "value": "active" },
  { "op": "set", "key": "alert.a1.severity", "value": "warning" }
]

delete is always allowed. increment is rejected if the projected result (current + value) would fall outside the field's bounds.

Graph Memory & Query API

Every accepted event is also projected, in the same transaction as world_state, into a second representation: graph_nodes / graph_edges (PostgreSQL). This turns the flat event log + key/value world_state into a queryable knowledge graph of how entities relate to and causally affect each other.

• Node types: agent, event, plus one per world_state entity (region, service, incident, deployment, team, alert, research, finding, vulnerability, proposal).
• Edge types:
  • PROPOSED — agent -> event
  • AFFECTED — event -> entity it touched
  • REFERENCES — entity -> entity, via explicit *_id fields (e.g. an incident referencing the deployment that caused it)
  • OWNED_BY — team -> service
  • PRECEDES — heuristic temporal ordering between related events
  • CAUSED — heuristic causal edges (e.g. alert-firing precedes incident-open, deployment precedes service degradation), each with a confidence score and rule_id

Query it via the /api/v1/graph/* REST endpoints above or the 5 graph MCP tools below (get_graph_node, get_graph_neighbors, find_related_entities, get_event_timeline, get_causal_chain). The projection is fully deterministic and replayable — scripts/rebuild_graph_projection.py truncates and rebuilds it from the accepted-event log from scratch.

Validation rules (deterministic, no LLM trust)

1. Size limit — payload over MAX_PAYLOAD_BYTES (default 8KB) is rejected.
2. Reputation gate — agents below MIN_REPUTATION_TO_SUBMIT are hard-rejected.
3. Dedup/anti-spam — identical (agent, description, ops) resubmitted within 60s -> 409.
4. Consistency — each op is checked against the current world_state type (e.g. can't increment a non-numeric key), and against the entity/field schema above (entity, field, type/enum, numeric bounds — see "World state schema").
5. Scoring — score = 0.3*completeness + 0.4*consistency_ratio + 0.3*agent_reputation. Accepted if score >= ACCEPT_SCORE_THRESHOLD (default 0.5) and no hard failure.

Every outcome adjusts agent reputation (+0.02 accept / -0.05 reject, clamped to [0,1]).

Drift

POST /world/simulate caches its prediction (sim:{agent}:{ops_hash}, 5 min TTL). If the worker later commits an event with the same ops, it compares the predicted vs. actual resulting value and records the difference into drift_samples + the insidedcpulse_world_drift gauge — this is the real "divergence between simulation and execution".

Observability (Grafana — NOT memory)