01
Processes and activities
Business flows, per-process activities, stages and value chains — modeled in BPMN or normalized from existing repositories.
EAFLOW · MECHANISM
Operational Graph connects processes, applications, data, documents, events, changes, owners and evidence.
Turns scattered relationships into traceable and actionable operational context for Max, agents and EAFlow solutions. It does not replace existing systems: it connects them as authorized sources.
BLUEPRINT · OPERATIONAL GRAPH
WHAT IT CONNECTS
- Processes and activities
- Applications and integrations
- Data and documents
- Roles and approvers
- Events, logs and transactions
- Changes, tickets and decisions
- Risks, controls and evidence
01 · Why it exists
From scattered sources to actionable operational context.
The Operational Graph is the common layer on top of which Change Impact, Process Knowledge, Quality Document Management and other EAFlow solutions run. It does not replace existing systems: it connects authorized sources and turns scattered relationships into queryable operational context.
It is the substrate from which Max and authorized agents answer — with citations to the node, the version, the owner and the source. Without operational context, AI answers from loose documents. With the Operational Graph, it answers from traceable relationships.
In Service Operations scenarios, the Operational Graph allows every ticket to stop being an isolated record and connect with service, application, process, vendor, SLA/OLA, evidence, knowledge, change and AI-assisted recommendation.
The Operational Graph does not only show relationships: it uses them to classify, prioritize, route, explain and audit operational decisions.
Auditable by design. Traceable node by node. Governed by the same rules as the real operation.
02 · What the graph connects
Seven entity groups, one context layer.
The Operational Graph organizes the operation into seven canonical groups. Each group is a set of first-class entities with traceable relationships to the rest.
02
Applications and integrations
Operational systems, modules, connectors and dependencies between applications that support the operation.
03
Data and documents
Datasets, living QMS documents, SOPs, work instructions, policies, procedures, records, evidence and official sources connected to the process that uses them.
04
Roles and approvers
Who is accountable for each process, document or application; who approves changes, publishing and evidence; who consults.
05
Events, logs and transactions
Operational signals that trigger or record flows — business events, application logs and transactions that leave traceability.
06
Changes, tickets and decisions
Change control, service tickets, documented decisions and traceability of how and why the operation evolves.
07
Risks, controls and evidence
Exposures, control mechanisms, published evidence and the link between control, document, process and owner.
Relationships cross all seven groups: a document links to the process, the responsible role, the control it evidences and the change that updated it. The graph is what makes those relationships count as first-class citizens.
03 · AI with operational context
Without operational context, AI answers from loose documents.
With the Operational Graph, AI answers from traceable relationships. A question like «what changed in the procure-to-pay flow?» is answered from the graph: which processes are part of procure-to-pay, which applications support them, which controls apply, who is responsible and what changed when — with citations to the node and the version.
The graph is the difference between AI that summarizes and AI that explains, traces and justifies. It is the difference between automation that waits for answers and governance that operates with context.
Prompts answer from text.
Max and authorized agents answer from the Operational Graph.
04 · How it is fed
The graph is fed from authorized sources.
It does not require replacing the current systems landscape. It connects to the sources that already hold operational context and constructs the shared model on top.
Processes and architecture
- Legacy BPMN repositories or EAFlow BPMflow
- Application portfolios, CMDBs and in-house inventories
- Capability and domain catalogs
Documents and knowledge
- Microsoft 365/SharePoint, OneDrive, Teams
- Google Workspace/Drive (per scope)
- Official QMS document repositories
Operations and change
- ServiceNow, Jira Service Management or other ITSM
- Change management and approval workflows
- GRC and audit platforms
Connectors are scoped to what the organization governs. EAFlow does not ingest what is not authorized.
05 · How the solutions use it
One layer, multiple solutions on the same context.
The Operational Graph powers horizontal solutions, vertical accelerators, Max and governed-agent assistance, APIs and reporting on the same context base. The current examples do not exhaust the portfolio: the same graph can sustain new solutions and sector use cases.
Horizontal solutions
Change Impact, Process Knowledge, Change Governance, Enterprise Architecture Governance and other cross-industry solutions operate on the same connected context.
Vertical accelerators
Quality Document Management for CPG and other industry accelerators use the graph to adapt processes, documents, evidence, owners and decisions to each sector context.
Max and agents
Max and authorized agents query the graph to answer with context, citations, relationships and evidence from governed sources.
APIs and reporting
Governed APIs, dashboards and reports consume graph relationships to expose impact, traceability, coverage, backlog, documentary risk and operational signals.
Operational flows
Approvals, changes, audits, document publishing and decisions can read from the graph and contribute new context back.
New solutions
The same substrate can extend to new horizontals, verticals or scoped engagements without rebuilding context from scratch.
The graph is proven by the solutions that use it and enrich it. Each new solution can read existing context and contribute relationships, evidence, decisions or signals back.
Example · Multi-hop query
One query. One traversal. One answer.
Here is the kind of question the Operational Graph answers as a single traversal.
Query«Which applications touch PII, whose primary vendor renewal is in Q3, AND which lack a documented change owner.»
Without an Operational Graph
Five spreadsheet joins. Three teams. Hours to weeks of reconciliation.
On EAFlow
One traversal across Application → Data (PII) → Vendor → Contract (renewal=Q3) → Change (change-management record + owner property) — answered in seconds.
Why it matters
Compliance, audit, and architecture decisions stop waiting on reconciliation.
This is one query example. The same graph answers questions about change impact, process owners, control coverage, document evidence, vendor obligations, and dozens more.
06 · Access surfaces
Three ways to query the graph.
People
Through Max
Max is EAFlow's conversational interface. The team asks plain-language questions about processes, applications, documents, risks, owners or changes — and Max answers from the graph, with traceability to the underlying nodes.
Meet Max ↗Agents
Through agentic workflows
Authorized agents query the graph as their context source. When the agent runs on Claude, on a self-hosted open-source model or on the organization's authorized private deployment, the graph is the substrate the agent answers from.
Talk to a specialist →Applications
Through governed APIs
Enterprise applications and EAFlow solutions consume the graph through governed APIs. Change Impact, Process Knowledge, Quality Document Management and others operate on the same substrate.
See solutions on the Operational Graph →07 · Roles on the graph
Architects govern the graph. Agents use it.
The graph is owned by the responsible architecture team. They define the ontology, approve the connectors, govern the version of truth and decide what the substrate covers.
Authorized agents (Max, Claude, Copilot, in-house agents) read the graph as their operational context source. They answer from the graph — not from prompts, not from documents uploaded to a chat, not from generic training data.
The architect role does not disappear. It shifts from documenting architecture in a repository to governing the substrate that agents operate on. The graph stays current because the systems feed it; governance stays sound because the rules remain in the architecture team's hands.
08 · How it is governed
The graph is not a free-for-all.
Every node has an owner. Every edge has a source. Every query is traced. Every change is logged. The graph is built for organizations where compliance, audit and accountability are not optional.
EAFlow does not hide what the AI uses. The Operational Graph exposes the context behind every answer — which nodes were consulted, which relationships were traversed, which version of which document, which controlled change was applied. Auditable by design, not by reconstruction.
- Every answer is traceable to graph nodes.
- Every node carries ownership and provenance.
- Every query is logged and inspectable.
- Every change to the graph is governed by the same controls as the operation.
Auditable by design, not by reconstruction.
The common mechanism that supports the EAFlow solutions.
The Operational Graph is the foundation that powers Change Impact, Process Knowledge, Quality Document Management and Max. It does not compete with the solutions: it is the common layer that makes them possible.
EAFlow is delivered through scoped enterprise engagements. The modular solutions (Change Impact, Process Knowledge, Quality Document Management) operate on the same Operational Graph.