Business knowledge and rules,
implemented in your systems.
We analyze policies, documents, data, and practitioner experience, and assess relevant consulting methods and industry best practices to define business concepts and decision criteria. We define terms, relationships, formulas, and exceptions, then implement them for use by AI agents and business systems. Existing documents, search, and SQL remain in use where sufficient; ontologies and knowledge graphs support tasks that require relationship queries.
Finding a document is not the same as applying a business rule
RAG is useful for retrieving relevant material and supporting answer generation. Applying knowledge to analysis and decisions also requires explicit definitions, rule conditions, order of application, thresholds, exceptions, effective periods, approval status, and procedures for handling conflicting evidence.
Meaning & Context
Define business concepts, attributes, relationships, states, and events so terms can be interpreted in their business context.
Rules & Exceptions
Represent calculation criteria, decision conditions, thresholds, the order in which rules apply, exceptions, and approval procedures explicitly.
Evidence & Conflict
Record source references and effective periods, and distinguish conflicting assertions so their evidence and conditions can be compared.
Ownership & Change
Manage owners, approval status, versioning, access, and change impact to define which knowledge is approved for use.
Knowledge models and query services
We assess the task and existing sources to select the required scope from the capabilities below.
Business Ontology
Define the core business concepts, attributes, relationships, states, events, responsibilities, and decision context.
Knowledge Graph
Represent documents, data, policies, organizations, business objects, and supporting evidence as identifiable nodes and relationships.
Knowledge Extraction & Linking
Extract knowledge candidates, resolve the same entities across different names and codes, map relationships, and handle duplicates and conflicts.
Decision Knowledge & Business Rules
Structure business questions, metrics, decision conditions, thresholds, exceptions, approvals, and execution conditions.
Knowledge Services & APIs
Implement APIs for agents and applications to retrieve business rules and evidence, and query related entities and relationships.
Knowledge Governance
Define governance procedures for source tracking, ownership, quality status, versioning, permissions, approval, change, and retirement.
Make identity, conflict, approval, and change rules explicit
A graph of entities and relationships is not enough for operational use. The knowledge model also needs explicit rules for deciding what represents the same entity, which relationships are permitted, and how conflicts, approval, and change are handled.
Identity & Meaning Rules
Define unique identifiers, names, attributes, business meaning, and the scope in which each entity and relationship applies.
Merge & Conflict Rules
Define when duplicate entities can be merged and how conflicting assertions, exceptions, and effective periods are handled.
Constraint & Quality Rules
Apply rules for required attributes, permitted relationships, value ranges, completeness, and consistency.
Provenance & Approval Rules
Track sources, supporting evidence, owners, validity periods, and approval status, and define which knowledge is approved for use.
Access & Change Rules
Define access rules for people and agents, together with versioning, change, retirement, and impact-review procedures.
Business-Question Validation
Use representative business questions to check whether the model provides the required knowledge and evidence and to identify gaps and unresolved areas.
Use LLMs to prepare structured candidates, then validate them against sources and rules
LLMs can extract candidate concepts, relationships, and business rules from documents and data. Schemas guide the extraction; outputs from multiple models can be compared; and each candidate is checked against source documents, data definitions, rules, and representative business questions. Designated reviewers separate approved knowledge from unresolved items before publication.
Source Analysis & Extraction
Identify candidate concepts, relationships, rules, and source references in policies, manuals, data dictionaries, SQL, reports, and interview notes.
Schema-Guided Ontology
Define entity types, attributes, permitted relationships, and output structures to control what is extracted and how it is represented.
Entity Resolution & Linking
Identify when different names and codes refer to the same customer or product. Define matching criteria and record mappings to related documents, data, and evidence.
Evidence & Multi-Model Review
Compare outputs from multiple LLMs and verify candidates against source documents and data definitions to identify omissions, unsupported inferences, and conflicts.
Rule & Quality Validation
Check identifiers, required attributes, permitted relationships, and business rules, and use representative questions to validate the structure and content.
Approval, Versioning & Change
Separate approved knowledge from unresolved items and manage approval status, versioning, change and retirement history, and impact on agents and applications.
Business meaning belongs in the AI design
Even “revenue” can mean different things across departments and reports. Customer definitions, cost allocations, and exceptions also vary by business. Knowledge engineering makes those distinctions explicit and implements the criteria an AI system needs to use.
Business terms and relationships
A sold-to account and an end customer answer different questions about sales performance. An ontology defines those concepts and their relationships, mapped to source data. RDF and OWL are options where systems need a shared vocabulary or formal inference across relationships.
Missing data and invalid records
A product with no recorded cost must not appear to be highly profitable. Checks for required values, permitted relationships, and ranges identify records that need attention. RDF graphs can be validated with SHACL; tables can use SQL checks and supported database constraints.
Metric calculations and aggregation
When returns enter revenue, or how overhead is allocated, changes what a number means. A semantic model captures formulas, reporting grain, periods, and join rules for implementation in semantic views or approved SQL. Results are reconciled to reference reports or test data.
Evidence relevant to the analysis
Once a policy changes, finding a similar document is not enough. A knowledge service checks effective dates, approval status, and access before providing evidence. Keyword and vector search, SQL, and graph queries are selected to suit the material, with source and version information retained.
The boundary between analysis and action
Proposing a price change and applying it require different permissions. Code checks tool inputs, business conditions, and approvals before execution. Writes and external transmissions need duplicate-action prevention, retry rules, and audit records.
The impact of a changed definition
One revised allocation rule can affect metrics, reports, and an agent's explanation. Version and dependency records identify the knowledge, rules, skills, and query services involved. Affected analyses are retested, with release and rollback scope based on those dependencies.
Architecture fitted to the client — Existing data and search services can be used, with graph databases or OWL reasoners selected for specific traversal and inference requirements. A dedicated Knowledge Graph product is not a prerequisite. The technology configuration is determined during architecture assessment.
What explains a decline in profitability?
The question “Which products have become less profitable, and why?” requires more than a calculation. This design example shows how the underlying definitions shape both the knowledge model and the analysis.
Choose the right basis for comparison
Gross profit and contribution margin answer different questions. Specify the metric, comparison period, allocation rules, and treatment of one-off costs, then map those definitions to product, customer, and transaction data.
Identify gaps before calculating
Check missing costs, duplicate codes, and currency or unit mismatches. Rather than fill unresolved costs with silent assumptions, distinguish what can be analyzed from what needs further investigation.
Calculate the drivers of change
Use tested SQL and calculation modules to assess price, volume, mix, and cost effects. The LLM supports analytical sequencing and interpretation; code checks that individual contributions reconcile to the total variance.
Support review and follow-up
Keep metric and rule versions, the data cut-off, assumptions, and exceptions with the result. Provide evidence for a pricing or portfolio review, while actual changes remain subject to the relevant permissions and approvals.
Put governed knowledge into search, analysis, workflows, and change-impact review
Knowledge Search & RAG
Provide relevant documents, concepts, and evidence together with source references and the scope in which the knowledge applies.
Agentic Analytics
Provide the metrics, analytical steps, decision conditions, exceptions, and evidence an agent uses to prepare analysis for review.
Decision Support & Workflow
Use business conditions and approval rules to identify the next items for review and prepare alternatives for human approval.
Impact & Change Analysis
Review related concepts, rules, agents, and applications when policies or data definitions change.
Discuss how to define and use your business knowledge
Tell us about the task, available sources, and difficulties in using business knowledge. We will assess the work needed to define decision criteria and implement them in your systems.
Discuss Enterprise Knowledge Engineering →