#Reasoning and Validation

Your ontology says every Doctor is a Person. You query for all Persons. Does your graph database include the Doctors? In most systems, no — unless you wrote a pipeline to materialize that inference, maintain it when the data changes, and hope it stays in sync.

WWKG does this automatically.

#What you could not do before

In most graph databases, the data is exactly what you put in — nothing more. If you assert that Alice is a Doctor and that every Doctor is a Person, the system does not know that Alice is a Person unless you also assert that explicitly. This means:

• Queries miss results that are logically implied but not explicitly stored.
• Maintaining a complete picture requires external pipelines that materialize inferences, running alongside the database.
• Those pipelines must be re-run when the data or the rules change, introducing lag and operational complexity.
• Validation — catching data that violates your schema or business rules — is typically done outside the database, in custom code.
• Rules live in application logic, not in the data layer, so different applications enforce different rules inconsistently.

The result: teams build elaborate ETL and validation layers around the database, doing work the database should do itself.

#What WWKG enables

Always-on inference. WWKG can automatically derive new facts from your data using the relationships defined in your ontology. Say “every Doctor is a Person” once, and every query for Persons includes Doctors — across every branch, in every query language, with no pipeline and no setup.

Two layers, your choice. Lightweight inference rewrites your queries on the fly to walk class and property hierarchies — always available, zero configuration. For larger ontologies where performance matters, WWKG can also materialize the full set of inferred facts into a dedicated computed workspace — direct lookups instead of hierarchy traversals, with storage overhead proportional only to the subjects that gain new inferred facts.

Extensible rules. The built-in inference covers standard vocabulary hierarchies (class and property inheritance). Beyond that, WWKG supports additional rule profiles — equivalence, inverse properties, symmetric and transitive relationships — each building on the previous level. Each level is independently queryable. You choose the depth of reasoning your use case needs.

Rules are data. Inference rules are stored in the graph itself — versioned, branched, encrypted, and queryable like everything else. Change a rule on a branch, and the inferred facts on that branch update accordingly. The main branch is unaffected until you merge.

Validation built in. Define shapes and constraints that your data must satisfy. WWKG validates incoming data against those constraints and reports violations — before bad data reaches production. This is not a separate tool; it is part of the data layer.

#A concrete scenario

An insurance company builds a knowledge graph of policies, claims, customers, and regulatory requirements. The ontology defines that every MotorPolicy is a Policy, every Policy has a PolicyHolder, and every PolicyHolder must be a Person or an Organization.

With inference, a query for “all Policies” automatically includes MotorPolicies, HomePolicies, and every other subclass — without listing them. With validation, a submission that creates a Policy without a PolicyHolder is rejected at write time, not discovered weeks later in a data quality report.

The actuarial team trusts the query results because the graph enforces its own rules. The compliance team trusts the data because violations are caught at the source.

#What makes this different

Most graph databases that offer inference treat it as a plugin or an external service with its own lifecycle. WWKG integrates inference into the query engine and the storage model. Inferred facts are versioned alongside asserted facts. They participate in branching and merging. They are encrypted with the same workspace key.

Because inference is part of the engine, it works across all three query languages — not just SPARQL. Cypher and GQL users benefit from class hierarchies, property inheritance, and transitive relationships automatically, without any SPARQL knowledge. A developer querying in Cypher for all Persons sees Doctors included, because the ontology says so. This has traditionally been impossible: inference was an RDF-only capability that property graph databases simply did not offer. WWKG is, to our knowledge, the first graph database to make this available to property graph users as a built-in feature.

Rules are not configuration files living outside the database. They are data inside the graph — which means they have history, they can be branched, and you can ask the graph “what rules were active when this report was generated?”

This is not bolt-on reasoning. It is reasoning as a native property of the knowledge graph — available to every user, in every language.

#Next steps

Related features: Three Query Languages, Branching and Merge Workflows, and Vector Search for Graph Workloads. See the Vocabulary section for public terms used across the WWKG product and docs.