Technology / Knowledge Architecture
We give company knowledge a structure.
The layer between a company's documents and what its AI can actually use.
Companies have an epistemic infrastructure problem.
Decisions, expert reasoning, contradictions, abandoned hypotheses, version drift: none of it is typed in a CRM, a wiki or a vector DB. Ingested as undifferentiated text, it retrieves by similarity — current or stale, verified or assumed, all weighted the same.
Knowledge architecture is the layer that decides how that information becomes computable: how it is typed, sourced, versioned, decayed, contradicted and retrieved.
RESEARCH
Active collaboration with MIT on knowledge ingestion and inference optimisation
There is no off-the-shelf pipeline.
The right shape depends on what knowledge the organisation actually produces, who creates it, where decisions live, and what the AI underneath is meant to do. Two companies in the same industry rarely need the same pipeline.
KVA runs the engagement — knowledge surface, pipeline, OBS — on the technology and research of Project OIDA, the KVA-accelerated venture working on epistemic knowledge infrastructure. The seven stages below are the reference components; we calibrate them per context.
Source ingestion
Documents, email, meetings, CRM, code, structured databases, expert interviews. Whatever the organisation actually produces, not just whatever sits in SharePoint.
Semantic segmentation
Decomposed by claim, not by token count. The unit of knowledge is the unit of meaning, not whatever fits in a chunk.
Entity & actor resolution
Who said what, in what role, with what authority. The same sentence from a junior analyst and from a board member is not the same sentence.
Epistemic classification
Each unit typed by its epistemic role before storage. A hypothesis and a decision carry different retrieval weight, decay rate and contradiction sensitivity — conflating them degrades everything downstream.
Provenance tracking
Every Knowledge Object anchored to its source span and to its dependency chains. Every claim reconstructable back to the document it came from.
Confidence & decay
Scored by formula, not by an LLM that read the sentence and felt strongly about it. Same input, same score, every time. Decay rates assigned at ingestion by content type and domain, so stale knowledge is flagged before retrieval, not after a wrong answer.
Lifecycle & contradiction
Conflicting claims are surfaced as a first-class signal instead of being silently averaged. Versioning, supersession and archival: knowledge ages, and the system has to age with it.
Nine epistemic types
Every knowledge unit is classified at ingestion. The type drives retrieval weight, decay rate and contradiction sensitivity — it is the field the rest of the pipeline reads.
Decision
A resolved choice with documented rationale
Evidence
Verified data that supports or refutes a claim
Hypothesis
An untested proposition under investigation
Observation
A recorded fact without causal interpretation
Open Question
A problem without a current answer
Contradiction
Two pieces of information in conflict
Assumption
A premise accepted without verification
Claim
An assertion awaiting validation
Signal
A weak indicator requiring accumulation before action
LLMs read the schemas; the system defines them.
The model maps natural language to pre-validated epistemic schemas, without inventing ODE parameters or proposing new epistemic classes.
Schema violations hard-fail, with no fallback path.
It is the only way to keep schemas uniform across instances and graph integrity intact over time.
OIDA — epistemic knowledge for the AI era.
OIDA is the tech company accelerated by KVA and dedicated to epistemic knowledge infrastructure; Project OIDA is its research arm, where the framework is formalised before it goes into clients.
The framework models organisational knowledge as four interlocking layers. It works at the epistemological layer — what is known, how confidently, what is decaying — distinct from ontological platforms (think Palantir) that model what entities exist and how they relate. The two layers are complementary.
Knowledge Objects (KOs)
The atomic unit: typed, sourced, scored, carrying its own epistemic state and its edges to what it supports, contradicts and derives from.
Knowledge Gravity Engine (KGE)
Importance and decay computed by ODE, not by LLM mood. Stable across queries, stable across months.
Hybrid Retrieval
Dense, sparse and structural retrieval, weighted by what is actually being asked. None of the three on its own is enough.
Organisational Belief System (OBS)
The aggregate: what the organisation believes, with what confidence, and how those beliefs move under new evidence.
Project OIDA position paper in preparation for H2 2026.
What a Knowledge Object actually looks like.
The dataclass on one side, on the other the API the agent layer uses to query the OBS. Schemas are calibrated per domain.
knowledge_object.py
from dataclasses import dataclass
from datetime import datetime
from typing import Literal
EpistemicType = Literal[
"decision", "evidence", "hypothesis",
"observation", "open_question", "contradiction",
"assumption", "claim", "signal",
]
@dataclass(frozen=True)
class KnowledgeObject:
id: str
claim: str
type: EpistemicType
# provenance
source_id: str
source_span: tuple[int, int]
actor: Actor # who, role, authority
# epistemic state — deterministic
confidence: float # [0, 1]
decay_half_life_days: float
created_at: datetime
# graph relationships
supports: list[str]
contradicts: list[str]
derived_from: list[str]obs_query.py
# What does the org currently believe about X,
# and how has that belief evolved?
belief = obs.query(topic="pricing strategy")
belief.consensus
# weighted by confidence and decay state
belief.contradictions
# explicit conflicts among KOs, with sources
belief.evolution(window="18m")
# trajectory over time, decision points marked
belief.decisions_made_under(
snapshot=obs.snapshot_at("2025-Q4"),
)
# which decisions stood on now-decayed beliefs?OBS — what the organisation believes, in writing.
The Organisational Belief System aggregates Knowledge Objects into a queryable belief state, weighted by confidence and decay. KVA instantiates it per client during the engagement.
It answers questions no current enterprise system can:
- 01
What does this organisation currently believe about X — and how confidently?
- 02
How has that belief shifted in the last eighteen months?
- 03
Which decisions were made under which beliefs, and have those beliefs since decayed?
- 04
Where do internal experts disagree — and what evidence is each of them holding?
What an engagement produces.
Knowledge architecture audit — current epistemic state
Knowledge Object schema, calibrated to your domain
Ingestion pipeline with epistemic governance
Validation Gate — hard-fail, no fallback
OBS instantiation — your organisation, modelled
Retrieval and reasoning interfaces
Hand-off to the agentic layer
Let's see what your organisation actually knows.
Most engagements open with a focused audit of the knowledge surface. From there we design the pipeline, instantiate the OBS and hand off to the agentic layer.