Schema-driven
“Look up my record.”
Forms · SQL · EDI
Humans defined the schema. Systems executed against it. To get an answer, you had to already know the shape of the data.
What is a Knowledge Asset
The shape of information is changing. The Knowledge Asset is the shape it's changing into.
Healthcare has spent four decades organising information around schemas, then around data, then around decisions. AI now demands a different organisation again - one built around inference. A Knowledge Asset is the artefact that makes inference, at the point of clinical or operational use, defensible.
The shift
From schema-driven to data-driven to decision-driven to inference-driven.
Each era required more of the system and less of the user. Each shift was also a shift in what the system had to be grounded in - to remain trustworthy as it took on more of the work. The Knowledge Asset is what grounds the inference-driven era.
Data-driven
“Aggregate the data and show me trends.”
Lakes · Warehouses · ETL
Humans collected everything; systems stored and aggregated. Information became plentiful, but answering a question still meant authoring a query.
Decision-driven
“Summarise this and tell me what to do.”
Dashboards · BI · Decision-support tools
Information was packaged around decisions. Software did some of the interpretation; humans still made the call. The decision was the unit of value.
Inference-driven
“Answer my question.”
AI agents · Reasoning models · Grounded inference
The system reasons. The user asks in their own words. Whether the answer is correct depends entirely on what the model is grounded in. That ground is what a Knowledge Asset is.
How information access has changed
The user used to come to the system. Now the system reasons for the user.
The user had to know the schema before they could ask.
- The user had to know the schema before they could ask.
- The answer was a row or a chart, not a recommendation.
- The system could not justify its output beyond pointing at the table.
- Cross-system queries required new integrations, every time.
The user asks. The system reasons over grounded knowledge.
- The user asks in plain language. The system reasons.
- The answer is sourced, country-stamped, and version-pinned.
- Every assertion ships with the reason it can be made and where it came from.
- Cross-system queries work because every system reads from the same substrate.
What it is not
First, the five things a Knowledge Asset is often confused with.
On first encounter, almost every reader reaches for the nearest concept they already have. A Knowledge Asset is none of these five.
Not a dataset
A dataset carries values; it does not carry meaning. Two datasets that use different definitions for “adverse event” cannot be combined.
Not a database
A database indexes and queries data. Its schema is structural - tables, columns, types - not semantic. A database can hold a Knowledge Asset, but it is not one.
Not a document corpus
A PDF library is human-readable and AI-retrievable, but it does not reason. It does not tell a model what a thing is, what it relates to, or what rule applies.
Not an API
An API is the surface a Knowledge Asset is exposed through. The surface and the substrate are two different things.
Not a fine-tuned model
A fine-tuned model has internalised patterns from a training corpus. It has not retained a traceable map from each output back to the source that justifies the output. The weights moved. The audit trail did not.
What it is
A versioned, structured, sourced, jurisdiction-aware bundle of healthcare knowledge.
Six layers, each load-bearing. None is optional. A document corpus with a few cross-maps is not a Knowledge Asset. A graph database with no provenance is not a Knowledge Asset. A model that quotes guidelines is not a Knowledge Asset.
Layer 06
Access
How the substrate is consumed.
Layer 05
Evidence
Where every claim traces back to.
Layer 04
Rules & logic
What the substrate can execute.
Layer 03
Knowledge graph
How entities relate to each other.
Layer 02
Terminology
How concepts are named.
Layer 01
Concept
What things are - the ontological foundation.
Layer 01
Concept
What things are. The ontological foundation - the formal answer to “what is a hypertension diagnosis?” or “what is a Class IIb medical device?” Without it, every downstream system makes its own answer up.
Layer 02
Terminology
How concepts are named. Cross-mapped where standards exist - SNOMED to ICD to LOINC, RxNorm to ATC. Where standards conflict, the asset declares the conflict; it does not silently choose.
Layer 03
Knowledge graph
How entities relate. Typed nodes, typed relationships, both with sources. A drug contraindicated-with a condition is a different fact from a drug interacts-with another drug. The graph captures the difference.
Layer 04
Rules and logic
What the asset can execute. Diagnostic thresholds, dose-adjustment rules, escalation criteria, eligibility logic - encoded so software runs them, not so a human reads them and decides what to do.
Layer 05
Evidence
Where every claim traces back to. The published guideline, the trial result, the regulator listing, the source ontology version. Provenance is recorded at the time the assertion is added - not retrofitted later.
Layer 06
Access
How the asset is consumed. As an MCP server an AI agent connects to. As a REST or GraphQL endpoint a backend calls. As a SPARQL endpoint an analyst queries. As a downloadable package for an air-gapped deployment.
Where it sits
The substrate between the AI and its sources.
A Knowledge Asset is not at the application layer (it is not the copilot or the EHR module) and it is not at the standards layer (it is not SNOMED or FHIR). It is the layer in between - and that in-between layer is the missing one.
Consumption
Applications, agents, and clinical systems that need answers.
Healthattica Knowledge Assets
Curated, versioned, jurisdiction-aware healthcare knowledge. The substrate the layer above consumes from, consolidated from the layer below.
Sources
Standards, regulator publications, and primary literature.
Why this shape, now
AI in healthcare needs grounding, not attachment.
The risk is not that the AI is wrong, in the abstract. The risk is that the AI is plausible. A model that hallucinates a drug interaction is harder to catch than one that fails outright. A model that cites an invented guideline is harder to flag than one that refuses to answer. In any healthcare workflow that will eventually be inspected - and that is most of them - the binding question is not "is the output good?" but "can the output be defended, on the record, when an auditor asks where it came from?"
Attached knowledge - the retrieval-and-quote pattern, the fine-tuning pattern - cannot answer that question. The retrieval was suggestive, not binding. The context was advisory, not architectural. The fine-tuning shifted weights but left no traceable line. Knowledge Assets are the architecture that answers the question by construction: the model is bounded by the asset, the output cites the asset, and the asset's version is recorded at the time the output was generated.
What changes when you adopt this shape
Five operational consequences. They compound.
I
The audit trail is the artefact
When every assertion carries its source, version, and timestamp, there is no parallel log to maintain. The audit trail is the work itself. A regulator asking “where did this output come from?” is asking a question the asset answers itself.
II
Cross-jurisdiction work stops being heroic
A jurisdiction-aware asset carries the answer for each market it knows about, stamped with which one. A regulatory team launching in eight markets queries the asset eight times and gets eight stamped answers - with conflicts surfaced, not silently resolved.
III
AI builds become composable
When two teams build on the same Knowledge Asset version, their AI outputs are reconcilable. Combine a cardiology copilot with a pharmacovigilance system and the terms refer to the same concepts. Cross-system queries become possible by construction, not by translation layers built per integration.
IV
Refresh becomes a versioned event, not a project
When a guideline updates, the asset's next release captures the change. Consumers pinned to the old version see what changed, when, and why. Consumers not pinned receive the change with their next read. There is no migration project. There is a version bump.
V
The substrate becomes legible to the buying organisation
An IT director can read the Knowledge Asset's specification. A clinical curator can trace any claim back to its source. A regulator can examine the asset itself. The artefact is not a black box - it is an engineered work built to be inspected.
Operationalisation
From substrate to surface. We can build either - or both.
A Knowledge Asset is the substrate. What sits on top - the app, the chatbot, the API, the model - is the surface a consumer interacts with. Most consumers need both. We can engineer the substrate, the surface, or both - for the use case in front of you.
Custom apps
Domain-specific software your team uses every day. The app is the surface; the Knowledge Asset is the substrate it reads from. We can engineer both - or just the substrate, if you have the app already.
Chatbots & copilots
Conversational agents inside the EHR, the LIMS, the Slack channel, the clinical tool your team already runs. The chatbot's facts come from the Knowledge Asset - so what it says is what the asset can defend.
REST & GraphQL APIs
Standard programmatic surfaces. Your existing backend calls out; it gets sourced, version-pinned, jurisdiction-stamped answers. Fits any stack that speaks HTTP.
LLMs, grounded
Large language models bounded by the Knowledge Asset. The model can synthesise; what it asserts is constrained by the substrate. Hallucination becomes structurally difficult - not just discouraged.
SLMs, specialised
Small language models fine-tuned or grounded on the Knowledge Asset for narrow, high-performance tasks. Faster, cheaper, deployable on-device or air-gapped where compliance demands it.
MCP servers & domain agents
Autonomous reasoners that consume the Knowledge Asset as a tool. Specialist agents - clinical reasoning, drug safety, regulatory triage, integrative care - built as the asset wrapped in agentic logic.
None of the surfaces above are off-the-shelf today. Each one is engineered for the operational use case in front of the consumer - and grounded in the same Knowledge Asset underneath. Ask us to build the surface, the substrate, or both.
Now, the dimensions we work across.
That's the shape of a Knowledge Asset and why this shape is what healthcare needs now. The catalogue itself - the dimensions of healthcare we're built to engineer Knowledge Assets across - is on the next page.