Schema Layers A–E
A UKS packet is organized into five layers. You use only the layers your conformance level requires — L1 packets use just Layer A; L3 packets use all five.
Layer A — Data Contracts & Sources
The foundation, required at every level. Layer A answers what the data is.
sources[]— each source carriesid,title,source_type,credibility_score,evidence_grade,clinical_status, plus optionaldoi, authors,license_label+rights_url, summary, and key findings.data_contracts[]— the shape and semantics of fields the packet describes.
Additive, optional siblings extend a source without breaking older consumers: claims[] (claim-level grade/status), temporal_validity, and quality_dimensions.
Layer B — Scrape Targets
Where to acquire more data. URLs, APIs, authentication, and pagination — everything needed to fetch the next batch of source material reproducibly.
Layer C — Extraction Rules
How to parse and normalize what Layer B fetches — CSS/JSON selectors, regex, or LLM extraction prompts that map raw content into the data contracts.
Layer D — Directives
Under what rules the data is processed — validation, routing, enrichment, and governance logic. Directives are a closed, executable vocabulary (directive_type), because an unrecognized rule is one no runtime can apply.
Layer E — Actions & Agent Instructions
What an AI agent should do with the knowledge — typed actions, triggers, and step definitions. Layer E is what makes a packet executable rather than merely descriptive.
The knowledge graph
Across layers, entities and typed relationships form a knowledge graph. In the Registry, these relationships become first-class edges that power graph-aware retrieval, consensus detection, and authority scoring — see Trust & safety.
Normative source
This is an overview. The binding definitions live in the normative specification:
- Full specification
- Canonical JSON Schema (draft/2020-12)
→ Next: Conformance Levels · Governance