Process graph: how data is produced, linked, and traced through decisions

What it is

The process graph is the runtime structure that connects entities and events for a given scope (e.g. “this order,” “this customer”). It answers: What entities exist for this order? How are they linked (order → payment → shipment → ticket)? What decisions were made along the way (refund approved by Mike, policy 4.2)? It’s not just a schema — it’s the actual graph of nodes (entities/events) and edges (relationships) that gets built when you ask “tell me everything about this order” or when an AI agent needs full context. In Loxtep, the process graph is a core part of the context substrate — what we build and serve so you and your AI see one connected picture instead of scattered systems.

How it’s made

The process graph is built and maintained as follows:

• Event ingestion and entity resolution. Events stream in from connected systems (Shopify, Stripe, ShipStation, Zendesk, etc.). Each event carries identifiers (order_id, customer_id, etc.). Using the thesaurus and ontology, we resolve those IDs to canonical entities and attach the event to the right node (e.g. “payment received” → Payment entity for Order #4821).
• Link creation. When we see a new event or entity, we create edges based on the ontology: Order #4821 → placed_by → Customer (Sarah Chen); Order #4821 → paid_by → Payment ($247); Order #4821 → fulfilled_by → Shipment #F-2847. Links are stored in a graph store or as relationship records keyed by (source_entity, target_entity, role).
• Decision traces. When a human or system makes a decision (e.g. “refund approved,” “override policy”), we capture that as a first-class node: who decided, when, why (e.g. policy 4.2), and optional precedent (e.g. “same outcome as Order #3190”). Those nodes are linked to the relevant entity (e.g. SupportTicket → resolved_by → Decision). So the process graph includes not only “what happened” but “who decided what and why.” Over time, recurring decision-trace patterns can be promoted into Organizational Skills (procedures) — reusable, versionable units of how work gets done.
• Query and materialization. When you ask “everything about Order #4821,” we traverse the graph from the Order node (following ontology relationships), load the linked entities and decision nodes, and return one coherent payload. The graph can be materialized on demand or kept warm in a context store keyed by order_id or customer_id.

Example of what a process-graph response looks like for one order (conceptually):

{
  "anchor": { "entity": "Order", "id": "4821" },
  "nodes": [
    { "type": "Order", "id": "4821", "data": { "status": "shipped", "revenue": 247 } },
    { "type": "Customer", "id": "sarah-chen", "data": { "tier": "VIP", "ltv": 4280 } },
    { "type": "Payment", "id": "py_xxx", "data": { "amount": 247, "method": "Visa" } },
    { "type": "Shipment", "id": "F-2847", "data": { "carrier": "FedEx", "status": "in_transit" } },
    { "type": "SupportTicket", "id": "891", "data": { "subject": "Where is my order?" } },
    { "type": "Decision", "id": "d1", "data": { "action": "Refund approved", "by": "Mike T.", "policy": "4.2", "precedent": "Order #3190" } }
  ],
  "edges": [
    { "from": "4821", "to": "sarah-chen", "role": "placed_by" },
    { "from": "4821", "to": "py_xxx", "role": "paid_by" },
    { "from": "4821", "to": "F-2847", "role": "fulfilled_by" },
    { "from": "sarah-chen", "to": "891", "role": "opened" },
    { "from": "891", "to": "d1", "role": "resolved_by" }
  ]
}

The process graph is built by Loxtep’s ingestion and correlation pipelines: they consume events, resolve entities using thesaurus and ontology, create and update nodes and edges, and optionally write decision traces when actions are taken in connected tools or in Loxtep.

Why it matters for governed data products and AI

The process graph is what turns “we have data in five systems” into “we have one context for this order.” It’s the backbone of the governed data product’s discoverable, consumable context. For AI, the graph is the structure over which it reasons — so it can answer “what happened?” and “what should we do?” using the same connected picture a human would use. That same graph is what you activate on: when a decision node is written (e.g. refund approved), you can trigger the next step in a workflow or notify a downstream system — delivered through whatever activation dialect fits the consumer (MCP, REST, webhook, SQL). In Loxtep, every governed data product that represents operational context (orders, customers, etc.) is backed by a process graph so the context we deliver is complete, decision-aware, and activatable.