Overview
Enrichment rules let you enrich your knowledge graph after document ingestion is complete. Using prompt-based, LLM-powered rules, you can:- Add or update attributes on existing nodes (e.g., tag projects with domains from a taxonomy)
- Create new nodes inferred from existing data (e.g., generate Obligation nodes from ContractClauses)
- Create relationships between nodes (e.g., link Employees to Skills based on resume content)
- Create nodes and relationships in one step (e.g., create Obligation and link it to the source)
How It Works
Each enrichment rule has three parts:
The system processes each target node through the LLM and applies the results back to the graph.
Creating a Rule
- Click Create Rule
- Enter a name and optional description
- Configure the three sections below
Target Configuration
Input Configuration
Choose what data to send to the LLM for each node:Prompt
Write a natural language prompt that guides the LLM. Placeholders are replaced with actual graph data before the prompt is sent.Target node placeholders
Placeholder names must match the attribute names in your Input configuration. Use snake_case if your graph uses it.
Related data placeholders
When Neighborhood is configured, you can reference related nodes:
The
Label in {related.Label} must match the target label from your neighborhood configuration (e.g., Resume, Skill, Status).
Taxonomy expansion
Use@TaxonomyName to inject taxonomy values into the prompt. The tag is replaced with a list of active leaf values from that taxonomy type.
The LLM receives the full list, which helps it choose from valid options. Define taxonomies in Model & Define > Taxonomies before creating rules.
Example prompt
Output format
The system automatically appends format instructions based on your Output type. For attributes, nodes, and relationships, the LLM is instructed to return valid JSON only — no markdown, prose, or bullet points. You can add Output instructions per attribute to give the LLM extra guidance (e.g., “Use title case” or “Pick the most specific match”).Prompts support the same
@TaxonomyName syntax used in ingestion. Define your taxonomies before creating rules for best results.Output Configuration
For relationships, specify the relationship type and target node label. The LLM will match or create target nodes based on your prompt.
Running Inference Jobs
- Save your rule
- Click Run Job (or use the dropdown on the rules list)
- Optionally enable Overwrite existing to re-process nodes that already have results
- Monitor progress in the Jobs tab
Job Status
Job Actions
- View — See job details and results
- Cancel — Stop a running job
- Resume — Continue a failed or cancelled job from where it left off
Viewing Results
- Per rule: Open a rule and go to the Jobs tab to see execution history
- All jobs: Use the Executions tab on the Rules page to see all enrichment jobs across rules
- Job details: Click any job to view processed nodes, errors, created/updated entities, and lineage record ids linking to graph audit entries when present
Graph lineage
Each successful enrichment write also creates a graph lineage record on the target node. Open the entity in the graph explorer to see which rule and model produced each attribute change. See Graph Lineage for details.Flow Integration
Enrichment rules can be used as steps in Flows. Add an Enrichment node to your flow and select the rule to run. The enrichment step runs when the flow executes, either manually or on a schedule. The flow editor warns when the selected rule is invalid against the current ontology. Fix the rule before you rely on that flow.Asking the copilot
The Admin Copilot has a page pack for the rules list, the create page, a rule’s editor, and its jobs and preview pages. Open it with the Copilot button or ⌘J. It knows the saved ontology, the taxonomies, the other knowledge-model pages and the files you attach in the chat (see The knowledge-model copilot). On the create and edit pages it reads the rule form as you have it, including unsaved edits. It can explain a rule, check it, and propose changes as a card.What a card can change
A card can switch a rule on or off. Switching a saved, active rule off carries a warning that
you acknowledge before Apply: while the rule is off, Run Job refuses it, and a flow whose
Enrichment step names it by id reports an error (uses inactive enrichment rule). Switching a rule
on carries no warning. Every entity type, attribute and relationship a card names must already be in
the saved ontology. When something is missing, the copilot proposes the ontology change first.
You apply it and click Save on the Ontology page; for a rule that is already saved, the copilot
then proposes the rule change it kept. Every placeholder in the prompt must be one the input gives,
and every
@TaxonomyName a taxonomy that exists.
Saving an edit writes over the saved rule, with no history, so a card can’t turn a rule into a
different one. A card that renames a saved rule and also changes what it processes, or what it writes,
carries a warning you acknowledge before Apply (If you meant a new rule, dismiss this card and use
Create Rule). A card that renames it and changes both is refused. A new rule is made on the create
page: the copilot offers to open it and proposes the rule there, or proposes it for the form when
the create page is already open. If you do mean to rewrite that very rule, say so, and the copilot
changes it in steps (the name first, then what it processes, then what it writes), each after you
Save the one before.
Every card is checked on the server before you see it, without saving anything. The rules API’s own
validation and its prompt check run on what the form’s Save would send, and the rule is checked against
the saved ontology before and after the change. An ontology problem the change causes blocks the card;
one the rule already had rides the card as a note (Separately, this rule already has a problem). An
error in the rule’s own settings blocks the card even when the rule already had it, and the copilot is
told how to fix it in the same card. For example, a relationship output’s match attribute that the
target type doesn’t have: the page’s dropdown offers only the target type’s attributes, and a run would
match nothing on another. The copilot is given a ready fix: match on name, or on the target type’s
first attribute when it has no name.
Under Save will also, the card lists what the page’s Save does on top of the change, when it
applies:
- Save drops the rule’s own neighborhood settings: the page keeps only “every 1-hop neighbour”, in neighborhood input mode.
- Save stores a rule’s legacy
nodeoutput as a new node with a relationship to the source node.
Applying a card
- Apply puts the card’s version of the rule into the form (Applied to the rule — nothing is saved until you click Save). Click Save Changes on the edit page, or Create Rule on the create page, to keep it.
- A card holds the whole rule as it would be after the change. If the form changed since the card was made, Apply asks first, because the card replaces those edits too.
- Undo on the card puts back what the form held before, until you edit on top of the applied change.
Cards made on another page
On the rules list, the jobs and preview pages, another rule’s editor, and the other knowledge-model pages (Ontology, Artifact Types, Data Mapping, Matching Strategies and Taxonomies), the copilot checks the rule you name as saved and makes a card for it:- The card reads Made for “Project domain” (Enrichment Rules) and has an Open “Project domain” button. It opens the rule’s editor, where you apply the card and click Save Changes.
- It is refused once the rule has been saved again since the card was made (This enrichment rule was saved since this was proposed — ask the copilot again.), or once the ontology has (The ontology was saved since this was proposed — ask the copilot again.). If the form has unsaved edits, Apply asks first.
- After an ontology Save that breaks a rule’s target, input attributes, filter or output, the copilot makes these cards by itself (see Continue after a Save). A neighborhood relationship the ontology no longer has gets no card: the copilot tells you what to change.
Re-validating, reviewing and deleting a rule
Ask the copilot to re-validate a rule, mark it reviewed or delete it, and it makes a page-action card for the rules list, from any knowledge-model page. Apply on the list opens a confirmation, and only your own click on its confirm button performs the action (see Page-action cards).- Re-validate is offered when the rule’s status is not valid, and Mark reviewed when it is stale or pending review. A rule a re-check would leave as it is gets no card.
- Delete is destructive. The confirmation lists what goes with the rule, counted when the card was made: all its jobs, with their results and processed-node records (a job running now is said). The flows with an Enrichment step on the rule are named: that step then names a rule that does not exist, and the flow’s check reports it. Nothing in the graph is removed: what the rule already wrote stays.
- The card is refused if the rule was saved or its status changed since it was made, and, for a review card, if the ontology was saved since.
Permissions
Enrichment rules and their jobs need the Process Managers role (superusers always have access):
The Ontology Compatibility page lists enrichment rules with the
other configurations. Each row opens the rule’s own page, where Re-validate and Mark as reviewed are,
and that page needs Process Managers read: a user who has only the Graph Managers role sees the row
but can’t open the rule. Data mapping rows work the same way with the Data Source Managers role.
The rule list in a flow’s Enrichment node, and the enrichment job shown in a flow run’s details,
come from the same endpoints, so they need Process Managers read as well. The Flows entry in the
admin sidebar is shown only to Process Managers readers; the Flows pages themselves don’t check the
role, so someone without it who opens a flow by its URL sees the Enrichment node’s rule list fail to
load.
In earlier releases any signed-in user could call these endpoints. After upgrading, give the Process
Managers role (read, or read and write) to everyone who works with enrichment rules.
Configuration
Settings that affect enrichment (available in Administer > System Settings):Best Practices
- Start with taxonomy — Define taxonomies before creating rules;
@TaxonomyNameexpansion improves classification accuracy - Test on a subset — Use a target filter to limit nodes when testing a new rule
- Review results — Check job results after the first run to ensure the prompt produces expected output
- Use specific prompts — Clear, specific prompts yield better results than vague instructions