Pergamum Pulse Knowledge Document and Metadata Framework
Part III — Assertions, Semantic Knowledge Graph and Crosswalks
3.1 Purpose
Part III defines how Pergamum Pulse transforms governed Knowledge Documents into structured semantic knowledge while preserving:
- source lineage;
- authority boundaries;
- rights;
- uncertainty;
- applicability;
- version;
- provenance;
- Module lineage;
- Component lineage.
The governing principle is:
A Knowledge Assertion is a governed representation of meaning derived from evidence. It is not the source itself, not authority itself and not activated ZAYAZ behaviour.
3.2 Semantic Knowledge Architecture
Source Documents
│
▼
Source Fragments
│
▼
Knowledge Assertions
│
▼
Knowledge Entities
│
▼
Semantic Relationships
│
▼
Crosswalks and Mappings
│
▼
Change Candidates
│
▼
Governed Projections
The semantic graph SHALL preserve:
- origin;
- meaning;
- context;
- applicability;
- confidence;
- authority;
- rights;
- temporal validity.
3.3 Knowledge Assertion Model
A Knowledge Assertion (PP-KA-) is the fundamental semantic unit.
Every assertion SHALL identify:
- assertion identity;
- subject;
- predicate;
- object;
- assertion type;
- source fragments;
- authority;
- applicability;
- confidence;
- review status;
- temporal validity;
- provenance.
Example:
assertion_id: PP-KA-000001
subject:
entity: PP-KE-device-flowiq2200
predicate:
type: supports_protocol
object:
value: wmbus
source_fragments:
- PP-SF-000031
confidence:
semantic: high
status:
review: approved
3.4 Assertion Types
Assertion classes MAY include:
- identity assertions;
- capability assertions;
- requirement assertions;
- relationship assertions;
- value assertions;
- evidence assertions;
- lifecycle assertions;
- compatibility assertions;
- applicability assertions.
3.5 Assertion Authority
Authority SHALL remain separated.
authority:
source_authority:
class: manufacturer_authoritative
evidentiary_authority:
permitted_for:
- device_capability
zayaz_authority:
class: governed_reference
runtime_authority:
class: none
An assertion SHALL NOT automatically become:
- a Registry value;
- a validation rule;
- a policy;
- a Runtime rule;
- a certification criterion.
3.6 Confidence and Review
Confidence SHALL be multidimensional:
- source confidence;
- extraction confidence;
- semantic confidence;
- applicability confidence;
- rights confidence;
- review confidence.
Confidence SHALL NOT replace evidence.
Knowledge Assertions SHALL conform to the universal lifecycle model defined by PP-KORS.
Assertion-specific lifecycle constraints and permissible transitions SHALL be defined by PP-KAS.
Extraction state, review state, conflict state, adoption state, projection state and activation state are orthogonal assertion-state dimensions and SHALL NOT redefine the universal object lifecycle.
For example, extracted is an extraction state and approved is a review outcome; neither is thereby a new universal lifecycle state.
3.7 Knowledge Entity Model
A Knowledge Entity (PP-KE-) represents an entity independent of the documents describing it.
Examples:
- standards;
- regulations;
- requirements;
- devices;
- manufacturers;
- protocols;
- datasets;
- methodologies;
- certification schemes;
- organisations.
A Knowledge Entity SHALL preserve:
- identity;
- semantic identifier;
- entity type;
- aliases;
- lifecycle;
- descriptions;
- assertions;
- relationships;
- provenance.
3.8 Entity Resolution
Entity resolution SHALL determine whether references describe:
- the same entity;
- related entities;
- different entities;
- unresolved entities.
Resolution SHALL consider:
- identifiers;
- names;
- versions;
- manufacturer codes;
- legal identifiers;
- authority;
- temporal context.
Similarity SHALL NOT automatically merge entities.
3.9 Semantic Relationship Model
Relationships SHALL be first-class objects.
Example:
relationship_id: PP-MAP-000001
source:
PP-KE-device
type:
supports_protocol
target:
PP-KE-wmbus
provenance:
PP-PROV-000001
Relationship types MAY include:
- same_as;
- alias_of;
- version_of;
- instance_of;
- contains;
- part_of;
- composed_of;
- depends_on;
- supports;
- compatible_with;
- implements;
- governed_by;
- validated_by;
- certified_by;
- supported_by;
- evidenced_by;
- derived_from;
- supersedes;
- replaces.
3.10 Semantic Knowledge Graph
Pergamum Pulse SHALL maintain a governed semantic graph.
Example:
Manufacturer
|
produces
|
Device Model
|
supports
|
Protocol
|
generates
|
Signal Type
|
maps_to
|
ZAYAZ Property
The graph SHALL prevent:
- orphan assertions;
- unsupported entities;
- relationships without provenance;
- authority escalation;
- rights leakage;
- tenant leakage;
- temporal contradictions.
3.11 Crosswalk Architecture
A Crosswalk (PP-MAP-) connects knowledge systems.
Examples:
- ISO requirement → ZAYAZ Control;
- regulation article → Evidence Requirement;
- device register → canonical property;
- dataset field → schema property;
- methodology → computation model.
A Crosswalk SHALL preserve:
- source;
- target;
- mapping type;
- rationale;
- confidence;
- reviewer;
- version;
- provenance.
3.12 Equivalence and Mapping Rules
Equivalence SHALL NOT be based on:
- similar names;
- marketing language;
- badges;
- common industry usage.
Equivalence SHALL evaluate:
- meaning;
- scope;
- applicability;
- authority;
- version;
- evidence;
- lifecycle.
Mapping types MAY include:
- exact equivalent;
- semantic equivalent;
- broader;
- narrower;
- partial overlap;
- conditional;
- implements;
- evidences;
- derived from;
- incompatible;
- unresolved.
3.13 Framework Crosswalks
Framework crosswalks SHALL compare:
- requirements;
- controls;
- evidence;
- assessment methods;
- decision rules;
- lifecycle;
- authority;
- version.
Example:
External Requirement
↓
ZAYAZ Control Objective
↓
Evidence Requirement
↓
Assessment Method
↓
Certification Impact
3.14 Device and Origin Crosswalks
Device crosswalks MAY connect:
- manufacturer model;
- product family;
- capability;
- protocol;
- signal type;
- unit;
- measurement property;
- connector;
- parser;
- Runtime profile.
3.15 Conflict Management
Conflicting assertions SHALL preserve:
- competing assertions;
- sources;
- authority;
- timestamps;
- confidence;
- reviewers;
- resolution.
The system SHALL NOT silently select one interpretation.
3.16 Applicability Resolution
Every assertion and mapping SHALL identify applicability:
- jurisdiction;
- organisation type;
- sector;
- product;
- device model;
- firmware;
- tenant;
- white-label;
- Module;
- Component;
- Runtime profile;
- time.
3.17 Semantic Change Detection
Semantic changes MAY include:
- new entity;
- removed entity;
- changed property;
- changed relationship;
- changed requirement;
- changed applicability;
- changed equivalence;
- changed confidence.
Material semantic changes SHALL create Change Candidates.
3.18 HECATE Semantic Validation
HECATE MAY validate:
- assertion structure;
- source linkage;
- relationship validity;
- mapping completeness;
- entity identity;
- applicability;
- confidence metadata;
- provenance.
HECATE SHALL NOT:
- invent meaning;
- resolve disputed expert judgement;
- grant authority;
- approve legal equivalence automatically.
3.19 Part III Provenance
Part III provenance SHALL connect:
- Source Object;
- Source Capture;
- Rights Record;
- Knowledge Document;
- Source Fragment;
- Knowledge Assertion;
- Knowledge Entity;
- Relationship;
- Mapping;
- Crosswalk;
- Review;
- Change Candidate;
- Projection;
- Module lineage;
- Component lineage;
- tenant lineage;
- white-label lineage;
- temporal lineage.
3.20 Part III Conformance
An implementation conforms where it:
- represents extracted meaning as governed Knowledge Assertions;
- links assertions to source evidence;
- separates assertions from authority;
- separates entities from documents;
- preserves entity identity;
- represents relationships as first-class objects;
- preserves relationship provenance;
- supports semantic knowledge graphs;
- prevents unsupported inference from becoming authority;
- supports framework, regulatory, device and dataset crosswalks;
- evaluates equivalence by meaning, scope, evidence, authority and version;
- prevents name-based equivalence;
- preserves conflicts;
- supports applicability resolution;
- creates Change Candidates for material semantic changes;
- preserves Module and Component lineage;
- preserves semantic history;
- integrates HECATE validation without replacing expert judgement.
Part III Foundational Principle
Knowledge becomes useful when meaning is structured without losing origin.
Pergamum Pulse SHALL transform documents into semantic knowledge while preserving the evidence, rights, authority, uncertainty and history behind every assertion.
An assertion without evidence is speculation. A relationship without provenance is assumption. A mapping without scope is ambiguity. An equivalence without authority is risk.
By making assertions, entities, relationships and crosswalks first-class governed objects, Pergamum Pulse can become a global semantic intelligence layer for ZAYAZ while preserving constitutional boundaries, legal integrity and explainable automation.