Why Semantica Is Getting Attention: AI Conclusions Need to Show Their Work

At an internal AI agent demo at a bank, the system read through a 200-page credit file and delivered its verdict: the loan can be approved. The Chief Compliance Officer didn't ask how fast it answered. She asked one question — what's the basis for that conclusion?

That question cuts right to the weakness of most AI systems today: they can produce answers, but can't explain which documents they used, which relationships they followed, or which rules they applied. Semantica has attracted attention precisely because it attempts to reconnect AI conclusions back to facts, relationships, sources, and timestamps — turning them into a reviewable chain of evidence. This article doesn't claim that "evidence chain capability" is the proven reason for Semantica's rise, but rather unpacks how it turns this into a system-level capability.

It's Not a Chatbot — and Not Just RAG Either

Sematica is not a chatbot, nor is it simply a RAG (Retrieval-Augmented Generation) tool that splits documents into chunks. What it aims to do is more substantial: take sentences from files, databases, and APIs, organize them into machine-queryable facts and relationships, and record where those facts came from, when they were valid, and how they participated in a decision.

Take the loan example. The system doesn't just store "a person named Zhang San and an apartment appeared in the file." It needs to know that Zhang San is the applicant, the apartment is the collateral, and a certain liability belongs to Zhang San's spouse. Only when these relationships are stored in a structured way can the agent — when asked "should this be approved?" — trace back exactly what it relied on.

This mechanism can be understood across three layers: relationships, evidence, and governance. Try a small exercise: pick a question that requires explaining its basis, write down the facts, relationships, and rules it depends on. Each layer below will come back to this exercise.

The Relationship Layer: Ontologies Can't Just Live in Documents

An ontology can be thought of as the "grammar table" of a business system: it defines what objects exist, what relationships are allowed between them, and what constraints fields must satisfy. The people who design these objects, relationships, and constraints are ontology engineers.

The key insight is that an ontology can't just be a diagram in a document. If it stays there, the system only knows the words "customer" and "contract" without necessarily knowing how they relate in business terms. Semantica connects the ontology further downstream — to data ingestion, entity recognition, querying, reasoning, and validation — making it the business rules layer that every agent action must pass through.

On the retrieval side, vectors and graphs each do half the work. Vector retrieval converts text into numbers to find potentially relevant materials; the knowledge graph stores nodes and edges, then chains multiple relationships together along paths like "applicant → liability → branch." In short: vectors handle where to find, graphs handle why it's relevant.

Knowledge Graph is the core data structure for this layer — composed of nodes (entities) and directed edges (relationships), it efficiently answers questions like "what path connects these two entities?" Compared to relational database tables, graphs handle multi-hop associations (e.g., "the bank where the applicant's spouse's liability is held") without complex JOIN operations — just traverse the edges. Common graph storage solutions include Neo4j and Amazon Neptune, with query languages typically being SPARQL (the standard semantic web query language) or Cypher. An Ontology is the "schema layer" of the graph, using standards like OWL or RDFS to define types, properties, and constraints — essentially adding a typed business-rules system on top of the graph, enabling machines to automatically infer relationships that weren't explicitly recorded.

The Evidence Layer: Every Fact Carries Its Origin and Timestamp

Sematica's provenance module uses the W3C PROV-O standard to record data origins and processing history. A record can include the source document, processing action, timestamp, original text excerpt, and confidence score — and can use a cryptographic fingerprint like SHA-256 to detect whether the record was tampered with afterward.

This goes a step beyond "just returning a retrieved text snippet": it answers how a fact entered the system and how it participated in subsequent relationships and decisions. A companion Decision Recorder component logs decision context, applied policies, causal relationships, and approval history.

The time dimension is also explicitly modeled. A supplier being compliant today doesn't mean they were compliant last year; an updated approval rule today doesn't mean it should have been applied six months ago. The system distinguishes between "when a fact became true in reality" and "when the system learned and recorded it," and uses Allen's interval algebra to express temporal relations like before, overlaps, and contains. This ensures that when reviewing a past approval decision, you don't mistakenly apply today's state to yesterday's judgment.

W3C PROV-O (Provenance Ontology) is a data provenance standard published by the World Wide Web Consortium. It has just three core concepts: Entity (data artifact), Activity (processing performed on data), and Agent (the person or system responsible for the activity). Together, they fully describe a process such as: "A PDF file (Entity) had its facts extracted by an OCR parsing program (Activity), which were then written into the knowledge base by a data ingestion service (Agent)." Allen's interval algebra, proposed by logician James F. Allen in 1983, defines 13 basic temporal relations (such as before, simultaneous, contains, overlaps), enabling systems to precisely express and reason about event sequences — not just record individual timestamps. The combination of these two standards allows provenance records to answer both "where did this come from?" and "during what time period was this valid?"

The Governance Layer: Machines Draft, Humans Make Business Judgments

Sematica supports automated ontology generation and also supports SHACL — which checks whether fields, types, and relationships meet predefined shape constraints. Machines can infer objects and relationships, but they don't know why "Customer" in the sales system and "Debtor" in the finance system use different definitions, or whether a particular special business case is allowed to accept exceptions.

Consistency governance can't be solved by "last write wins." The same customer might appear under three different names and codes across CRM, finance, and contract systems. The system can use string similarity, semantic similarity, and merge strategies to detect duplicate entities; when contradictory facts are found, it should flag them and — when necessary — route them to a domain expert for confirmation, while preserving the original sources. This is also the new focus for ontology engineers: machines handle drafting and checking, humans determine business meaning, resolve conflicts, and approve exceptions.

SHACL (Shapes Constraint Language) is a W3C standard for defining "shape" constraints that RDF data graphs must satisfy — analogous to how JSON Schema constrains JSON data. It can verify whether a node has required properties, whether property values fall within valid ranges, and whether the count of relationships between entities meets business rules (e.g., an applicant can have at most one primary loan). Constraint violations generate structured validation reports for human or automated processing. Entity Resolution is another key technology in the governance layer, addressing the problem of "the same real-world object being represented differently across systems." Common approaches include edit-distance-based string similarity, word-vector-based semantic similarity, and rule engines (e.g., matching by unified social credit code takes priority over name matching). Candidate pairs that cannot be automatically resolved should enter a human review queue — not silently default to one version — to prevent data errors from propagating through downstream decision chains.

Boundaries and Implementation Guidance

Sematica's approach has clear limits. Auto-generated ontologies are still just drafts; Chinese-language and multimodal scenarios (handling text, images, and audio/video simultaneously) may require additional adaptation; and large-scale deployment brings storage and operational costs.

Looked at from another angle: for simple document Q&A, vector retrieval with reliable citations may already be sufficient. Ontologies and knowledge graphs only start paying off clearly when questions involve cross-system entities, multi-hop relationships, historical state, compliance rules, and accountability tracking.

If your organization is preparing to let AI agents enter approval, contract, payment, or supply chain workflows, start with three steps:

1. Pick one question that requires explaining its basis, and map out which facts, relationships, and rules it depends on.
2. Add source and timestamp annotations to key facts, and get one complete evidence chain working end-to-end.
3. Define in advance which entities can be automatically merged, which conflicts require human confirmation, and which decisions need an approval trail and audit log.

For acceptance testing, randomly sample one agent conclusion — it should be able to reconstruct the source document, key entity relationships, applicable rules, and the valid time window. Conflicts that can't be automatically resolved must enter human review, not be silently overwritten.

Large language models handle language generation; semantic infrastructure like Semantica keeps the facts, relationships, rules, and accountability chain inside the system. Once AI genuinely participates in decision-making, what enterprises need to add is precisely everything beyond the answer itself.