Define what you mean by inference
Semantic inferencing is often used loosely. In a formal knowledge system, it means deriving statements from facts and declared semantics. In a language-model application, people may use the same phrase for interpreting intent or suggesting relationships. Those operations have different guarantees and should be labeled accordingly.
W3C's RDF semantics specifies entailment regimes: rules about which conclusions follow from a graph under particular assumptions. For example, if a class is a subclass of another class, RDFS can support a corresponding type inference for its members. A model-generated association is not automatically an entailment of that kind.
Give the system a shared vocabulary
Our proposed starting point is a small domain model. Identify the entities your product actually uses, the relationships between them and the owners of those definitions. In a service directory, that might mean Provider, Service, Location and Availability. Give each entity a stable identifier instead of relying on a name that may be ambiguous.
Keep asserted facts separate from extracted candidates and derived conclusions. Attach a source, observation date and review state where the application needs them. If a document says a provider operates in Karen, preserve the evidence; do not silently expand that into a claim that every service is available everywhere in Nairobi.
Separate retrieval, reasoning and explanation
A useful architecture can have five stages: ingest permitted sources, resolve entities, retrieve relevant evidence, apply defined reasoning or validation, then compose an answer. Keyword and vector retrieval can help find candidate material. A graph or structured database can make relationships queryable. Neither mechanism removes the need to check whether the evidence supports the answer.
Consider a request to find a service near a user. Similarity search might retrieve a promising provider description. Structured checks can then test the stated service and location. The answer layer should explain the match and identify missing details, rather than presenting a plausible candidate as verified availability.
Make uncertainty part of the interface
In our proposed design, every answer has an evidence state: supported, conflicting or unresolved. This is a product convention, not an RDF standard. It lets a person distinguish a recorded fact from a suggestion that still needs confirmation. Source dates also matter when the underlying information changes frequently.
Authorization must apply before private material is retrieved and again before an action is performed. A beautifully connected knowledge graph is still unsafe if a user can infer restricted information through an unrestricted answer. Evaluate the access policy across the whole flow, including logs and caches.
Evaluate the chain, not just the prose
Build a small evaluation set with expected evidence and acceptable outcomes. Include duplicate names, conflicting documents, missing relationships and questions the system cannot answer. Measure retrieval relevance, entity resolution, rule correctness and whether the final response stays within its evidence.
This architecture is a design proposal for teams developing knowledge-backed products, not a claim about a deployed Harmosoft implementation. It reflects the direction of our work: clear data foundations, useful interfaces and systems whose reasoning can be inspected. Start with a narrow question and expand only when the evidence supports it.
Sources & further reading
Original commentary by Harmosoft, with the following references for the underlying concepts.
Explore Harmosoft’s structured knowledge, API and AI infrastructure capabilities.
Connect your knowledge↗