Solutions · Operational knowledge
Business logic and operational knowledge
Deep dive
Software executes decisions the organisation should be able to understand again.
On one page
Systems that reconstruct and make examinable the logic distributed across code, configurations, rules, documentation, data and operational practice.
- 01Business logic rarely lives in a single place. A business application executes decisions continuously: which datum is valid, which state may follow another, which condition blocks an operation, which calculation applies, who may authorise, which exception changes…
- 02We do not generate a single explanation and take it as true. A model can read code or documentation and produce a convincing description.
- 03What can be reconstructed. Depending on the available sources, the system can identify and relate:
Business logic rarely lives in a single place
A business application executes decisions continuously: which datum is valid, which state may follow another, which condition blocks an operation, which calculation applies, who may authorise, which exception changes the path and what effects each action produces.
Over time, those decisions become distributed across:
- code and stored procedures;
- ERP configurations and workflow engines;
- decision tables and rules;
- forms, validations and interfaces;
- functional and technical documentation;
- spreadsheets and templates;
- incidents and tickets that explain exceptions;
- historical data and execution traces;
- knowledge held by particular people.
When the organisation needs to modernise, integrate, automate or audit, it discovers that it knows the system in fragments but has no common representation of the logic that actually governs the work.
We build systems to reconstruct that logic, make it examinable and keep it connected with its evidence and with the people able to validate it.
We do not generate a single explanation and take it as true
A model can read code or documentation and produce a convincing description. That result is useful as a starting point, but it does not demonstrate that the logic is complete, current or correct.
We distinguish several states:
- observed: it appears directly in an artefact;
- inferred: it is deduced from several signals but needs validation;
- confirmed: a person or a sufficient test validates it within a defined scope;
- contradicted: other evidence shows an incompatible version;
- obsolete: it belonged to the system but should no longer apply;
- unknown: there is not enough evidence to represent the decision.
This distinction makes it possible to use models to accelerate the investigation without turning their fluency into authority.
Ø no matching source in corpus
What can be reconstructed
Depending on the available sources, the system can identify and relate:
- business entities and attributes;
- states and transitions;
- conditions, thresholds and validations;
- calculations and transformations;
- permissions and segregation of duties;
- decisions and alternatives;
- dependencies between modules and applications;
- calls, events and side effects;
- exceptions and recovery paths;
- versions and scopes of application;
- duplicated or potentially contradictory rules;
- open questions that need domain knowledge.
The representation can take different forms: navigable maps, graphs, decision tables, process models, rule records, linked documentation, APIs or structured context for assistants and agents.
Provenance is part of every rule
A rule without an origin is hard to discuss and dangerous to reuse.
Every element must preserve:
- the artefact and the location it comes from;
- the relevant fragment of code, configuration, document or trace;
- the version and the scope;
- the method by which it was extracted or inferred;
- the evidence that supports and contradicts it;
- its validation state;
- the people or tests that took part;
- the known relationships and dependencies;
- the questions that are still open.
In this way a person can move from a high-level explanation to the detail that supports it, and correct the knowledge without redoing the whole investigation.
Human intervention validates meaning, it does not copy results
Domain specialists should not have to review an endless list of isolated rules. The system must group and prioritise whatever deserves attention:
- contradictions between sources;
- inferences with weak evidence;
- rules with great impact or many dependencies;
- differences between documentation and execution;
- frequent exceptions;
- behaviours with no clear owner;
- decisions that affect authority, compliance or risk;
- scopes where a rule may have been generalised too far.
The review must make it possible to confirm, reject, edit, narrow the scope, add an exception or declare that the organisational intent should change even though the current software does something else.
The existing system does not always represent the desired system
Reconstructing logic is not the same as preserving all of it.
The code may contain a defect. A configuration may reflect an old decision. An operational shortcut may be reasonable in one context and dangerous if generalised. A frequent exception may indicate that the main rule is badly designed.
That is why we separate two questions:
- What logic does the system appear to execute today?
- What logic does the organisation want to keep or change?
The first can be investigated with artefacts and behaviour. The second needs human responsibility and decision.
Use cases
Modernisation and migration
Before replacing an ERP, a module or an application, it makes it possible to inventory the rules, dependencies and exceptions that must be kept, transformed or retired.
Impact analysis
It connects a proposed change with the processes, data, interfaces, tests and decisions that could be affected.
Automation and agents
It provides a more reliable source of logic and context so that a bot or an agent knows what it may do, under what conditions and when it must consult.
Living documentation
It relates explanations with code, configurations, decisions and tests, so that an update can propagate and be discussed.
Technical and functional auditing
It makes it possible to examine where a policy is applied, what variants exist and what evidence supports each claim about the system.
Process optimisation
It makes visible duplicated rules, branches with high rework, recurring exceptions, unnecessary dependencies and points where the process loses context.
From inventory to operational knowledge
The result should not be a report that starts ageing the moment it is delivered.
It must be maintainable as a layer of operational knowledge:
- versioned;
- consultable by people;
- accessible by software through contracts;
- connected with tests and observability;
- able to represent contradictions;
- explicit about what it still does not know;
- useful for the next decision to change something.
This line of work draws on the experience of DocuLogic: researching how to turn artefacts of enterprise systems into a more auditable representation of their logic, without confusing extraction, inference and approval.
Observed, inferred, validated and agreed
The representation distinguishes four states of one and the same rule:
- observed behaviour: what the software executes today and the traces make it possible to check;
- inferred logic: the candidate explanation an analysis proposes, with its evidence and its uncertainty;
- validated knowledge: what a person with domain authority has confirmed and bounded;
- organisational decision: what the organisation agrees should happen from now on.
This distinction makes it possible to use existing software as a source while keeping authority where it belongs. An implementation may contain a historical workaround, an inconsistency or a behaviour the organisation wants to change.
DocuLogic, KIR and semantic technologies
DocuLogic keeps the reconstructed knowledge as a layer for human authoring and review: it expresses concepts, rules, calculations and exceptions in readable, versionable formats, together with provenance, verification state, period of validity, scope, life cycle and relationships. A person can read it, discuss it and correct it without working on a database or on an execution representation.
KIR — Knowledge Intermediate Representation — is the typed, canonical intermediate representation that receives that knowledge and projects it towards relational databases, graphs, semantic indexes, rule engines, APIs, MCP and agents.
Depending on the case, the structure can rely on LinkML to define schemas, TypeDB or other typed graphs for complex relationships, PostgreSQL and pgvector for relational, lexical and semantic knowledge, Datalog for deduction, DMN for decisions, CEL for validations, and Tree-sitter and LSP for code structure.
This page goes deeper into one capability of informational intelligence: making examinable the logic that today lives spread across software, configurations, documentation and experience.
From scattered artefacts to examinable logic
- 01Gather evidenceTake in code, configurations, tables, procedures, process models, spreadsheets, tickets and other relevant artefacts.
- 02Reconstruct structureIdentify entities, states, conditions, decisions, actions, dependencies and exceptions.
- 03Infer candidate logicPropose rules and paths when they are not expressed directly, preserving the evidence and the uncertainty.
- 04Relate versions and contradictionsDistinguish which logic is in force, duplicated, obsolete or in conflict between systems and documents.
- 05Validate with people and testsConfirm, reject or bound each inference through domain knowledge, examples, data and observable behaviour.
- 06Represent and publishTurn the logic into maps, decisions, tables, graphs, documentation, APIs or consultable knowledge.
- 07Maintain and reuseVersion the changes and connect the logic with modernisation, automation, auditing, agents and optimisation.
Result
A versioned, consultable map of decisions, conditions, exceptions and dependencies, connected with the evidence that supports it and with the state of its validation.
It can feed documentation, impact analysis, modernisation, testing, automation, assistants and agents without presenting as truth whatever the system has merely inferred.
When this need appears
- 01when nobody can explain from end to end why the system takes a decision
- 02when a migration depends on rules spread across several technologies
- 03when the documentation describes the process but not its real exceptions
- 04when different applications apply different versions of the same policy
- 05when an agent needs to act and there is still no reliable source of business logic
- 06when every change requires dependencies and side effects to be located by hand
- 07when a recurring exception is resolved by experience but is never taken into the shared knowledge
The system from the inside
Maturity · Evaluation- How it is organised
- Ingestion processes software and operational artefacts; an analysis layer identifies entities, conditions, branches, decisions and effects; and a common representation relates each element to its source location. Inferred rules are stored as hypotheses, not as facts, and are checked against documentation, data, tests and domain knowledge.
- What can be examined
- The inventory of artefacts can be examined, along with the dependency map, a rule with all its evidence, a contradiction between versions, the validation history and the transformation of confirmed logic into a decision table, documentation or a consultable interface.
- How it is checked
- We check artefact coverage, accuracy of references, consistency between representations and the ability to reproduce known behaviours through tests. Adversarial review looks for invented rules, omitted conditions, badly generalised scopes and differences between what is documented, what is implemented and what is observed.
Conditions and limits
Existing behaviour does not by itself demonstrate the correct intent: it may contain errors, historical exceptions or agreements that are already obsolete. Part of the logic depends on human context that was never recorded. Domain validation and the decision about what should be kept remain organisational responsibilities.