# The knowledge layer for enterprise: Processes > Source: > Published: 2026-09-30 08:51:00+00:00 # The knowledge layer for enterprise: Processes Principal Consultant, Neo4j 12 min read ## The knowledge layer for enterprise AI: **Processes** *This series is the practical build companion to* *Jesús Barrasa’s knowledge layer manifesto**. This chapter is built on the previous* *chapter 1: Operating Structure* Rosa Delgado runs Risk & Compliance at AcmeBank. In the first review meeting after the org graph went live, she asked a question nobody in the room expected to be hard: “Who owns the loan approval process?” Chapter 01 gave AcmeBank a graph that answers who’s accountable for a ***team***, right now and at any point in time. It’s already better than the org chart but Rosa didn’t ask about the team. She asked about the process: the sequence of tasks, who performs each step, where the handoffs are, and where it stalls. That knowledge isn’t in the org structure. It lives in BPMN tools if your company has one, in procedure documents nobody has opened since the last audit, in ticket histories, and most often than it should, in people’s heads. *And if the people in the room can’t get a straight answer, an agent has no chance. You can’t ask an agent to do the work if nobody can describe it.* That’s the problem this chapter solves. By the end you’ll have the second slice of the knowledge layers for enterprise AI, loaded at AcmeBank: - the SMB loan approval process as a graph, - with every task, handoff, escalation queryable, - and Rosa’s question answered in one go. Here’s the shape of what’s ahead: - What this layer is - How to design it - What it’s worth - How it connects - What lives in it - The build - Asking it questions - What’s next ## **What this layer is** Why model a process as a graph and not a BPMN diagram? Because a diagram is a picture and a process is a set of facts. AcmeBank has BPMN diagrams. They’re in a folder, they were perhaps accurate the week they were drawn, and nobody can query them. When Rosa asks who owns the process, a diagram can’t answer. When an agent needs to know which step comes after affordability fails, a diagram can’t answer that either: someone has to look at it, interpret it, and type the answer somewhere else. The process layer takes the same knowledge and ***makes it data***. A process breaks into activities, activities break into tasks, tasks connect to each other with conditions, and tasks connects to the role that performs it. The role, not the person: we did that work in Chapter 01, and it pays off immediately here. When Eleanor left, the tasks didn’t change. What changed is who fills the role that performs them, and the graph already knows that. ## **How to design it** So where does process knowledge actually come from, and how does it get into the graph? The diagram above is this whole chapter in one diagram, and it’s intentionally in the same shape as the first chapter, the sources change but the approach does not. Process knowledge lives in three places: **Procedure documents.** Official and versioned but unstructured knowledge. Good for the process outline: the process exists, it has roughly these stages. **Workflow and ticket systems.** What actually happened in the process. Captures the actual execution: the sequences, escalation and handoff points, the paths the documents sometimes miss. **People.** The conditions, the exceptions, the judgement calls and all the undocumented knowledge around specifics. Whichever source you draw from, the same rule from this series applies: extraction output is a draft input, not a fact. If you mine ticket histories for task sequences, or point a language model at the procedure library, what comes back is a candidate process. It enters the graph as proposed, with provenance stamped at write time: source, extraction date, confidence. It only becomes canonical when a human who does the work confirms it match. The risk of skipping that confirmation step to save time is you end up with a confident graph of processes nobody follows because they mismatch with the reality. *The rule is simple: extraction gives you candidates and governance decides what’s true.* ## **What it’s worth** So what does this buy the business? **Ownership of the work, on demand.** Chapter 01 answered who’s accountable ***for a team***. This layer answers who’s accountable *** for a process or task***, which is the question regulators, auditors, and Rosa actually asked, and eventually, what your agent will need to automate your processes. One owner per process, resolvable to a named person through the operating structure graph, with history. **A process an agent can walk, one step at a time.** An agent needs the process and the next steps to the current task that compose a process. With this, from any task, the graph answers what comes next, under which condition, and which path is the default. And when the step ahead isn’t the agent’s to take, the graph says that too: hand the file to the underwriter here, escalate to the Head of Credit Risk there. The same edges that route the work also mark its limits. **The automation inventory.** Every task in the graph carries a simple flag, determined through existing automation or manually by the owner of the process: could this step be automated, or does it need human judgement? This will give you a queryable inventory of exactly which steps of a process an agent can take over, which must stay human, and who owns the boundary. When someone asks “what could we automate in lending?”, the answer is a simple consumption of your graph, not a workshop. ## **How does it connect to other stages** **Downwards**, this layer uses work from Chapter 01: every task is performed by a role, and roles resolve to people through the structure we already built. **Upwards**, it points at our next chapter 03: Domain Ontology. The tasks in this chapter use words like “affordability” and “risk appetite” as if everyone in the organisation agrees what they mean, but the reality is: terminologies and business term definition varies through different organisation, business functions and units. In Chapter 04 (Data Products) some of these tasks will read data products. ## **What lives in the process graph** **BusinessProcess** is the unit of ownership: a named piece of end-to-end work with a criticality and an SLA. **BusinessActivity** is the stage: a coherent chunk of a process that a reader can hold in their head. **BusinessTask** is the working unit: the thing a role actually performs, with inputs, outputs. Tasks chain together with **NEXT** relationships that carry the routing: a condition, an outcome where a path terminates, and an ***isDefault*** marker for the happy path. **PERFORMS** connects a role to a task while **OWNS** connects one role to the process. **HANDOFF_TO** marks where a task passes responsibility across a role boundary, and **ESCALATES_TO** marks where the normal path needs help. The design decisions, from production experience: 1. **Hierarchy of three levels:** Process, activity, task. A task is the kind of thing that consumes a dataset or gets delegated to an agent: “Assess affordability”, or “Pull customer X dispute history”. 2. **Routing lives on the edges.** NEXT carries condition, outcome, and isDefault, so the flow logic is real data, not just documentation. The happy path is a relevant traversal as much as the decline paths, nothing is implied or made up. 3. **Roles perform tasks, people don’t.** PERFORMS points at Role, not to a Person. People change, but the work assignment doesn’t. Chapter 01’s FILLED_BY history does the rest, which is exactly how the graph shows us Eleanor’s gap without a single process edge changing. 4. **One owner per process.** OWNS is a single edge to a single role. 5. **NEXT is a sequence, HANDOFF_TO is a responsibility.** A task can flow to the next task performed by the same role (no handoff) in a sequence based on conditions. But when the next step of a task require a human intervention, the HANDOFF_TO carry the task and responsibility to a role that owns this piece. ## Building this architecture The requirement is the same as Chapter 01: Neo4j 2026.02 or later, Enterprise Edition, Cypher 25. Run Chapter 01’s three files first, then this chapter’s slice. Everything in this article is loadable, it ships with: Inside chapter 2’s folder, you will find: - [01-create-graph-type.cypher](https://github.com/msenechal/enterprise-knowledge-layer-series/blob/main/chapter2/01-create-graph-type.cypher) , the graph type (schema) for the blog series - [02-load-data.cypher](https://github.com/msenechal/enterprise-knowledge-layer-series/blob/main/chapter2/02-load-data.cypher) , this chapter’s dataset. - [03-queries.cypher](https://github.com/msenechal/enterprise-knowledge-layer-series/blob/main/chapter2/03-queries.cypher) , every query you can run against this graph to get value from this layer and answer the initial question. All the above are additive on top of Chapter 01, the organisation slice stays enforced throughout. First run the graph type ([01-create-graph-type.cypher](https://github.com/msenechal/enterprise-knowledge-layer-series/blob/main/chapter2/01-create-graph-type.cypher)) Then load the data ([02-load-data.cypher](https://github.com/msenechal/enterprise-knowledge-layer-series/blob/main/chapter2/02-load-data.cypher)). It creates - one process, - three activities, - ten tasks, - two handoffs, - and two escalations onto roles that already exist in the Chapter 01 graph. The dataset contains: - 1 process, - 3 activities, - 10 tasks, - 13 NEXT edges, - 10 PERFORMS, - 2 handoffs, - 2 escalations, - and 1 owner, Loaded on top of the first chapter’s 18 organisations, 32 roles, and 58 people. ## **Asking it questions** Before we start, all the queries below are available in the same repository as it was in the chapter1, in a separate chapter2 folder: *03-queries.cypher* ### **Rosa’s question first: who owns the loan approval process?** One result: the SMB Loan Approval process, owned by the Head of SMB Lending, filled today by Yusuf Rahman. Not just the business unit, not a unsubstantiated guess, not a person like Eleanor. That’s this whole chapter in a single query and result. ### **What’s the happy path, end to end?** Capture, verify, assemble, affordability, risk, terms, decision, offer: eight steps from application to offer letter, read straight off the edges. The decline paths come from the same shape of query, filtering on outcome instead of the default flag. ### **Audit of who was and still perform this task up to today?** Two results. - Marginal case review is performed by the Head of SMB Lending; - Eleanor Fairbairn held that role for three years and her interval is closed; - Yusuf holds it now. The task and the role didn’t change. What changed is the person who was performing this task in a certain period, and this allow you to list and audit who was performing what tasks at any point in time. ### **What could an agent actually take over?** Ten tasks, five of them automatable: 1. capture, 2. verification checks, 3. affordability calculation, 4. offer issuance, 5. decline letters. The human judgement stays, and now that decision is recorded as a fact in the graph not an opinion in a discussion. ### **And when the normal path isn’t enough, where does it go?** Risk assessments outside appetite reach the Head of Credit Risk; decisions above mandate reach the Head of SMB Banking. Names are attached, because escalation to a role that is not assigned, is risk that needs to be escalated. ## **What’s next** There are questions this graph still can’t answer. “Assess affordability” assumes everyone agrees what affordability means. At AcmeBank, with two core banking systems and a definition of churn that is not agreed upon, that assumption doesn’t survive contact with the data. What ***is*** affordability here? Which fields, from which systems, under which rules? That’s the domain ontology, and it’s the next chapter. Until that chapter comes out, we suggest you try two things. First, **sketch one real process** from your own organisation in these shapes: one process, a handful of activities, honest tasks, and see how far you get. Second, if you loaded the graph, point the official Neo4j MCP server at the database similar to what we did in chapter 1 (read-only) and ask it Rosa’s question in plain English. Watching an agent answer “who owns the loan approval process?” correctly, with history, is a quick way to demonstrate the essence of this series to someone who hasn’t read it. Similar to how we wrapped up in chapter 1, here is a concrete example of using the knowledge layer we are building, in claude, through MCP: The org chart told you who’s in charge. The process layer tells you what they’re in charge of, what are all the steps that compose a business process, what pieces you can automate through agentic AI, and which requires human intervention. [The knowledge layer for enterprise: Processes](https://medium.com/neo4j/the-knowledge-layer-for-enterprise-processes-f0fc54157e0a) was originally published in [Neo4j Developer Blog](https://medium.com/neo4j) on Medium, where people are continuing the conversation by highlighting and responding to this story.