How a knowledge graph stores your business rules

A business rule stored in a knowledge graph is a declarative condition attached to entity types or relationships, such as a discount threshold or an eligibility test, that any traversal can apply consistently. This differs from a rule buried in a spreadsheet formula, a BI calculated field, or a stored procedure, none of which are visible outside the tool that runs them.

Where business rules actually live today

Most mid-market companies do not have their business rules written down anywhere central. They have a spreadsheet with a nested IF formula that decides which reps get commission credit. They have a BI tool with a calculated field that defines "at risk account" one way in the executive dashboard and a slightly different way in the sales dashboard. They have a stored procedure in the database that recognizes revenue on a schedule nobody outside the finance team has read in a year. Each of these is a real rule, doing real work, and each one is invisible to everyone who did not write it.

For the wider context, see our knowledge graph glossary of 40 terms.

This is not a documentation problem that a wiki page fixes. The rule is coupled to the tool that executes it. Move the formula to a new spreadsheet and it can silently break. Ask a different report to apply the same "at risk" logic and someone has to retype it, often slightly wrong. The rule has no independent existence, it only exists as a side effect of a specific piece of software running.

What a graph-encoded rule looks like

A knowledge graph stores entities, such as Account or Order, and relationships between them. A business rule fits naturally into this structure as a condition attached to a type or a relationship: "an Account is At Risk if it has an open Ticket with priority High and no Order in the last 90 days." Written this way, the rule references entity types and properties that already exist in the graph, not table names or cell ranges specific to one report.

Rules held in one place are also what stops why AI in accounting can answer the same question two different ways from happening in the first place.

Because the rule is attached to the entity type rather than to a report, every traversal that touches Account inherits the same definition. A question asked from the CFO's chair and a question asked from a sales manager's chair both apply the identical "At Risk" test, because both are reading the same graph structure rather than two different calculated fields that happened to be typed similarly.

Four rule types worth walking through

Thresholds. A discount above a stated percentage requires manager approval. Encoded as a condition on the Order-to-Approval relationship, this rule fires the same way regardless of which system originated the order, a point-of-sale terminal, a web store, or a manually entered invoice.

Eligibility. A customer qualifies for a loyalty tier if they meet criteria spanning purchase history, account age, and support history. This is a rule that naturally spans several entity types, Customer, Order, Ticket, which is exactly the kind of condition that is painful to express in a single spreadsheet formula but straightforward as a graph traversal, since the relationships between those entity types already exist.

Territory assignment. A lead is routed to a sales rep based on region, deal size, and existing account relationships. Encoded in the graph, this rule can reference the Account's existing assigned rep, avoiding the common failure mode where a new lead from an existing account gets routed to a different rep than the one already working that account, simply because the routing tool did not know about the relationship.

Revenue recognition timing. Revenue for a multi-period contract recognizes on a schedule tied to delivery milestones, not to invoice date. This rule sits on the relationship between Contract and Milestone, and it can be applied consistently whether the underlying transaction came from the ERP, a manually tracked project spreadsheet, or a billing system, because the rule reads the relationship, not the source format.

Declarative rules versus procedural code

A declarative rule states a condition and lets the traversal engine apply it wherever the pattern matches. A procedural rule, the kind written into a stored procedure or a script, states a sequence of steps that must run in a specific order against a specific set of tables. The declarative form is easier to read, easier to reuse across different questions, and easier to audit, because reading the rule and understanding what it does are the same act. The procedural form requires reading code and mentally executing it to understand its effect, which is why business rules written as stored procedures are so often understood by exactly one engineer.

This does not mean procedural logic disappears entirely. Some calculations genuinely need sequential steps, currency conversion followed by tax calculation followed by rounding, for example. But the eligibility, threshold, and classification rules that make up most of what a business calls a "rule" are naturally declarative conditions, and forcing them into procedural code is usually a symptom of the rule having nowhere better to live, not a sign that procedural code was the right tool.

Versioning a rule that changes

Business rules change. A discount threshold gets raised, an eligibility criterion gets tightened, a revenue recognition policy gets updated after an audit finding. In a spreadsheet, changing the rule means editing the formula and hoping every copy of that spreadsheet gets the same edit. In a graph, the rule can be versioned the same way any other fact about the business can be versioned: the old rule applied from one date, the new rule applies from another, and any question about a past period can still apply the rule that was actually in effect at that time, rather than the current rule applied retroactively.

This matters more than it sounds. A common and expensive mistake is recalculating a historical quarter's commission or revenue recognition using the current rule instead of the rule that was live during that quarter. Rule versioning tied to a timeline avoids this by making "which rule applied when" an answerable question rather than something reconstructed from memory or old email threads. This is the same logic that underlies a temporal knowledge graph, where facts and the rules applied to them both carry a validity window.

Who should be allowed to edit a rule

A rule with real financial or operational consequence, a commission threshold, a revenue recognition policy, should not be editable by whoever happens to have edit access to a spreadsheet. The healthier pattern gives edit rights to a small, named group, usually finance or operations leadership for financial rules, sales operations for territory and eligibility rules, and requires a visible change log: who changed the rule, when, and what the previous version stated. This is not bureaucracy for its own sake, it is the difference between a rule change being a deliberate decision and a rule change being an accidental edit nobody notices until a downstream number looks wrong.

Read access to the rule definitions themselves should be far broader than edit access. Anyone affected by a rule, a sales rep subject to a territory assignment rule, should be able to see the current rule stated in plain language, even if they cannot change it. Rules that only the person who wrote them can read tend to become disputed the first time someone questions an outcome.

Comparison: where rules live across four approaches

Approach	Visibility	Reusable across reports	Versioned by date	Typical failure mode
Spreadsheet formula	Low, buried in a cell	No, must be retyped	Rare, usually overwritten	Silent divergence between copies
BI calculated field	Medium, visible inside one tool	Limited to that tool	Rare	Different tools define the same metric differently
Stored procedure	Low, requires reading code	No, tied to one database	Sometimes, via migration history	Understood by one engineer only
Graph-encoded rule	High, stated as a readable condition	Yes, inherited by any traversal	Yes, tied to a validity window	Requires an initial modeling pass

Where SIGNLD fits

SIGNLD encodes business rules as part of the private knowledge graph it builds from a company's connected systems, rather than requiring rules to be re-created inside a dashboard or a script for every new question. A rule defined once, an eligibility threshold, a territory assignment, applies consistently across every Decision Brief that touches the entities it governs, and each Brief shows the evidence and the reasoning behind the answer, including which rule was applied, with links back to the source records. Connections are read-only, spreadsheets are treated as first-class sources, and rules can be reviewed in plain language rather than reverse-engineered from a formula, described further in how it works. See the full knowledge graph glossary for related terms.

Key takeaways

Most mid-market companies do not have their business rules written down anywhere central.
A knowledge graph stores entities, such as Account or Order, and relationships between them.
A rule with real financial or operational consequence, a commission threshold, a revenue recognition policy, should not be editable by whoever happens to have edit access to a spreadsheet.
A well-versioned rule structure retires the old rule with an end date rather than deleting it outright, so any question about a period before the change still applies the rule that was actually in effect then.
Encoding one rule requires identifying which entity types and relationships it touches, which is usually a short exercise for a single rule.

FAQ

Is a graph-encoded rule the same thing as a business rules engine?

They overlap in purpose but differ in structure. A standalone business rules engine typically runs rules against data fed into it from elsewhere. A rule encoded in a knowledge graph is attached directly to the entities and relationships it governs, so it applies wherever those entities appear in a traversal, without a separate integration step.

Can a graph-encoded rule handle exceptions?

Yes. An exception is simply a more specific condition that overrides a general one, such as a discount threshold that is waived for a named strategic account. Because both the general rule and the exception are stated as conditions on the graph, the exception does not require separate code, it requires a more specific pattern.

What happens to old rules when a new one is defined?

A well-versioned rule structure retires the old rule with an end date rather than deleting it outright, so any question about a period before the change still applies the rule that was actually in effect then. This preserves the ability to explain a historical decision accurately.

Does moving rules into a graph replace the need for finance or operations to define them?

No. The graph is where the rule lives once defined, not where it originates. Finance, operations, or sales leadership still decide what the threshold or eligibility criterion should be. The graph makes that decision consistent and visible once it has been made.

How much modeling work does this require before a rule is usable?

Encoding one rule requires identifying which entity types and relationships it touches, which is usually a short exercise for a single rule. It does not require modeling every rule in the business up front, rules can be added incrementally as each one becomes worth encoding.

Try SIGNLD free to see how your business rules map onto a private knowledge graph, or see how it works.