Skip to main content

Pergamum Pulse Knowledge Assertion Specification

Version 0.1 — Normative Assertion Contract​

This specification defines the canonical Knowledge Assertion model for Pergamum Pulse.

A Knowledge Assertion is the smallest governed semantic statement that Pergamum Pulse may preserve, review, compare, relate, query or use as evidence for a proposed change.

This specification governs:

  • assertion identity;
  • assertion type;
  • subject, predicate and object structure;
  • source-fragment evidence;
  • normative force;
  • value and unit representation;
  • formulas and thresholds;
  • authority;
  • rights;
  • applicability;
  • confidence;
  • uncertainty;
  • extraction provenance;
  • review and approval;
  • conflict;
  • supersession;
  • withdrawal;
  • graph integration;
  • assertion-to-relationship conversion;
  • Change Candidate generation;
  • tenant and white-label isolation;
  • historical reconstruction;
  • HECATE validation;
  • conformance.

The governing principles are:

A Knowledge Assertion SHALL be a governed representation of meaning derived from identified evidence.

An assertion SHALL NOT be treated as the source from which it was derived.

An assertion SHALL NOT gain authority merely because it is structurally valid, machine-readable, approved for knowledge use or stored in the semantic graph.

Every material assertion SHALL preserve exact source evidence, authority, applicability, rights, temporal validity, confidence, review state and provenance.

Confidence SHALL NOT replace evidence, authority or review.

An approved assertion SHALL NOT automatically become a Registry value, policy, validation rule, certification criterion, computation rule or Runtime instruction.

Conflicting assertions SHALL remain visible until governed resolution.

Unknown, absent, prohibited, not applicable and not evaluated SHALL remain distinct semantic states.

Every machine-generated or AI-assisted assertion SHALL remain distinguishable from source-authored content and human-approved meaning.

1. Scope​

This specification applies to every first-class KnowledgeAssertion identified by the PP-KA- prefix.

It applies to assertions derived from:

  • laws and regulations;
  • standards;
  • regulatory guidance;
  • court decisions;
  • certification and accreditation schemes;
  • methodologies;
  • scientific literature;
  • datasets;
  • code lists;
  • device manuals;
  • data sheets;
  • protocol specifications;
  • API specifications;
  • certificates;
  • supplier documentation;
  • internal Viroway documents;
  • ZAYAZ architecture and governance documents;
  • tenant-provided knowledge;
  • white-label-provided knowledge;
  • approved human interpretation;
  • machine extraction;
  • AI-assisted extraction.

It applies whether the assertion is:

  • proposed;
  • extracted;
  • reviewed;
  • approved;
  • approved with conditions;
  • disputed;
  • rejected;
  • superseded;
  • withdrawn;
  • historical.

This specification does not grant any assertion:

  • constitutional authority;
  • legal authority;
  • publication permission;
  • Runtime authority;
  • certification status;
  • activation eligibility.

Those states require separate governed decisions.

2. Normative Language​

The terms SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY and MAY NOT are normative.

Where this specification conflicts with PP-KDMF, the framework prevails.

Where this specification conflicts with PP-KDMS, the stricter assertion requirement prevails unless an approved version relationship states otherwise.

A domain Profile MAY tighten this specification but SHALL NOT weaken:

  • identity;
  • evidence;
  • authority separation;
  • rights;
  • applicability;
  • provenance;
  • tenant isolation;
  • activation boundaries.

3. Assertion Architecture​

The canonical assertion path is:

Source Object
      ↓
Source Capture
      ↓
Knowledge Document
      ↓
Source Fragment
      ↓
Knowledge Assertion
      ↓
Knowledge Entity or Literal
      ↓
Relationship / Crosswalk / Change Candidate
      ↓
Governed Decision
      ↓
Projection
      ↓
Separate Activation

An assertion SHALL remain distinguishable from:

  • the source;
  • the source fragment;
  • the entity described;
  • the relationship inferred;
  • the mapping proposed;
  • the Change Candidate generated;
  • the projection compiled;
  • the active Runtime state.

4. Canonical Assertion Object​

A conforming assertion SHALL implement the following structure:

knowledge_assertion:
  assertion_id: PP-KA-000001
  semantic_id: pp.assertion.device.flowiq2200.supports.wmbus
  assertion_version: 1.0.0
  assertion_type: capability
  canonical_statement: "The device model supports W-MBus."

  subject:
    kind: entity_reference
    entity_id: PP-KE-000101

  predicate:
    predicate_id: pp.predicate.supports_protocol

  object:
    kind: entity_reference
    entity_id: PP-KE-000202

  source_evidence:
    source_fragments:
      - PP-SF-000031

  normative_force:
    class: descriptive

  authority: {}
  rights: {}
  applicability: {}
  confidence: {}
  temporal: {}
  review: {}
  status: {}
  relationships: {}
  provenance: {}

4.1. Required Fields​

Every machine-actionable assertion SHALL include:

  • assertion_id;
  • assertion_version;
  • assertion_type;
  • canonical_statement;
  • subject;
  • predicate;
  • object or a permitted objectless form;
  • source_evidence;
  • normative_force;
  • authority;
  • rights;
  • applicability;
  • confidence;
  • temporal;
  • review;
  • status;
  • provenance.

4.2. Optional Fields​

Optional fields MAY include:

  • semantic_id;
  • original_statement;
  • normalised_statement;
  • language;
  • translation;
  • qualifiers;
  • exceptions;
  • conditions;
  • threshold;
  • unit;
  • formula;
  • uncertainty;
  • candidate_targets;
  • conflict_set_id;
  • assertion_set_ids;
  • derived_relationship_ids;
  • change_candidate_ids.

4.3. Canonical Statement​

The canonical statement SHALL be a concise human-readable representation of the assertion.

It SHALL NOT replace the typed subject–predicate–object structure.

4.4. Original Statement​

Where available, the original source statement SHOULD be linked through a Source Fragment rather than duplicated without rights review.

4.5. Normalised Statement​

A normalised statement MAY standardise terminology while preserving:

  • source wording;
  • transformation;
  • reviewer;
  • semantic differences;
  • provenance.

5. Assertion Identity​

5.1. Assertion Identifier​

Every assertion SHALL possess an immutable identifier using:

PP-KA-<SEQUENCE>

5.2. Semantic Identifier​

A reusable assertion SHOULD possess a semantic identifier.

Example:

semantic_id: pp.assertion.standard.control.requires.risk-assessment

5.3. Identity Non-Reuse​

An assertion identifier SHALL NOT be reused for a materially different statement.

5.4. Assertion Equivalence​

Assertions SHALL NOT be treated as identical solely because their canonical statements are textually similar.

Equivalence SHALL consider:

  • subject;
  • predicate;
  • object;
  • qualifiers;
  • applicability;
  • authority;
  • temporal validity;
  • source evidence;
  • normative force.

5.5. Duplicate Candidate​

Potential duplicates SHALL be represented as candidates for review rather than automatically merged.

6. Assertion Versioning​

Every assertion SHALL have an independent version line.

version_line:
  assertion_id: PP-KA-000001
  assertion_version: 2.0.0
  predecessor: PP-KA-000001@1.0.0
  successor: null

A new major or minor version SHALL be created where any of the following materially changes:

  • subject;
  • predicate;
  • object;
  • normative force;
  • applicability;
  • authority;
  • source evidence;
  • rights;
  • temporal validity;
  • threshold;
  • formula;
  • interpretation.

Editorial changes MAY increment a patch version.

Approved assertion versions SHALL be immutable.

7. Subject Model​

The subject identifies what the assertion is about.

7.1. Subject Kinds​

Permitted subject kinds MAY include:

  • entity_reference;
  • object_reference;
  • class_reference;
  • role_reference;
  • jurisdiction_reference;
  • document_reference;
  • assertion_reference;
  • anonymous_subject;
  • compound_subject.

7.2. Entity Subject​

subject:
  kind: entity_reference
  entity_id: PP-KE-000101

7.3. Class Subject​

subject:
  kind: class_reference
  class_id: pp.class.organisation.ai-provider

7.4. Compound Subject​

A compound subject SHALL explicitly define conjunction or disjunction.

subject:
  kind: compound_subject
  operator: all_of
  members:
    - PP-KE-000101
    - PP-KE-000102

7.5. Unresolved Subject​

An unresolved subject SHALL use an explicit provisional identity and SHALL NOT be silently mapped to an existing entity.

8. Predicate Model​

The predicate defines the governed semantic relationship between subject and object.

8.1. Predicate Registry​

Every predicate SHALL be governed by a Predicate Registry.

The Registry SHALL preserve:

  • Predicate Identifier;
  • canonical name;
  • definition;
  • allowed subject classes;
  • allowed object classes;
  • direction;
  • inverse predicate;
  • transitivity;
  • symmetry;
  • value constraints;
  • unit constraints;
  • authority constraints;
  • lifecycle;
  • provenance.

8.2. Predicate Identifier​

Example:

predicate:
  predicate_id: pp.predicate.supports_protocol

8.3. Free-Text Predicate Prohibition​

Machine-actionable assertions SHALL NOT rely solely on free-text predicates.

8.4. Predicate Versioning​

A material predicate-definition change SHALL create a new Predicate Registry version and trigger assertion impact analysis.

9. Object Model​

The assertion object identifies the value, entity, class, statement or structured payload related to the subject.

9.1. Object Kinds​

Permitted kinds MAY include:

  • entity_reference;
  • object_reference;
  • class_reference;
  • assertion_reference;
  • controlled_value;
  • text_literal;
  • boolean_literal;
  • numeric_literal;
  • date_literal;
  • duration_literal;
  • range;
  • quantity;
  • formula;
  • list;
  • set;
  • structured_object;
  • null_semantic.

9.2. Entity Reference​

object:
  kind: entity_reference
  entity_id: PP-KE-000202

9.3. Controlled Value​

object:
  kind: controlled_value
  registry: pp.protocol-registry
  value_id: protocol.wmbus

9.4. Quantity​

object:
  kind: quantity
  value: 100
  unit_id: unit.litre-per-hour

9.5. Range​

object:
  kind: range
  minimum: 0
  maximum: 100
  minimum_inclusive: true
  maximum_inclusive: true
  unit_id: unit.degree-celsius

9.6. Null Semantic​

A null semantic SHALL distinguish:

  • unknown;
  • not stated;
  • not applicable;
  • prohibited;
  • not evaluated;
  • unavailable;
  • redacted;
  • logically absent.

10. Assertion Type Registry​

Assertion types SHALL be Registry-governed.

Core assertion types MAY include:

  • identity;
  • definition;
  • classification;
  • requirement;
  • prohibition;
  • permission;
  • recommendation;
  • capability;
  • compatibility;
  • incompatibility;
  • value;
  • threshold;
  • range;
  • formula;
  • unit;
  • evidence;
  • applicability;
  • lifecycle;
  • temporal;
  • relationship;
  • equivalence;
  • supersession;
  • withdrawal;
  • certification;
  • assurance;
  • methodology;
  • data-quality;
  • uncertainty.

Every assertion type SHALL define:

  • allowed predicates;
  • allowed subject kinds;
  • allowed object kinds;
  • required evidence;
  • required review;
  • normative-force rules;
  • authority constraints;
  • applicable Profiles.

11. Normative Force​

Normative force SHALL be explicit where relevant.

Permitted classes MAY include:

  • legally required;
  • regulator required;
  • contractually required;
  • standards SHALL;
  • standards SHOULD;
  • standards MAY;
  • prohibited;
  • permitted;
  • recommended;
  • informative;
  • descriptive;
  • evidentiary;
  • inferred;
  • unresolved.

Example:

normative_force:
  class: standards_shall
  original_term: shall
  interpretation_status: reviewed

A source's normative term SHALL NOT automatically create ZAYAZ authority.

12. Source Evidence​

Every material assertion SHALL link to exact source evidence.

12.1. Evidence Structure​

source_evidence:
  source_objects:
    - PP-SRC-000001
  source_captures:
    - PP-CAP-000001
  knowledge_documents:
    - PP-KD-000001
  source_fragments:
    - PP-SF-000031

12.2. Exact Locator​

Evidence SHOULD identify:

  • page;
  • clause;
  • article;
  • paragraph;
  • table;
  • row;
  • cell;
  • figure;
  • dataset record;
  • API field;
  • timestamped segment.

12.3. Evidence Sufficiency​

Evidence sufficiency SHALL be assessed separately from extraction confidence.

12.4. Multi-Source Assertions​

An assertion supported by multiple sources SHALL preserve each source independently.

12.5. Unsupported Assertion​

An assertion without supporting evidence SHALL be classified as:

  • hypothesis;
  • derived intelligence;
  • proposed interpretation;
  • unsupported;
  • quarantined.

It SHALL NOT be approved as source-supported knowledge.

12.6. Evidence Withdrawal​

Withdrawal or invalidation of supporting evidence SHALL trigger impact analysis for dependent assertions.

13. Authority​

Every assertion SHALL preserve authority dimensions separately.

authority:
  source_authority:
    class: manufacturer
    scope:
      - device_specification

  legal_authority:
    class: non_binding

  evidentiary_authority:
    class: authoritative_for_source_content
    permitted_claims:
      - supported_protocol

  zayaz_governance_authority:
    class: governed_reference

  runtime_authority:
    class: none

13.1. Authority Non-Transitivity​

An assertion SHALL NOT inherit greater authority merely because:

  • the source is official;
  • the source is current;
  • the assertion is approved;
  • HECATE validates it;
  • a crosswalk exists;
  • a projection can be generated.

13.2. Evidentiary Scope​

Evidentiary authority SHALL identify which claims the source is competent to support.

Legal authority SHALL identify:

  • jurisdiction;
  • legal role;
  • subject;
  • effective period;
  • binding status;
  • interpretation status.

13.4. Runtime Authority​

Runtime authority SHALL remain none unless separate governed activation has occurred.

13.5. Authority Receipt​

A material assertion SHOULD expose an Authority Receipt linking:

  • source authority;
  • legal authority;
  • evidentiary authority;
  • ZAYAZ governance authority;
  • Runtime authority;
  • applicability;
  • Decision;
  • provenance.

14. Rights​

Every assertion SHALL reference the Rights Records governing its source fragments and permitted downstream use.

rights:
  rights_record_ids:
    - PP-RGT-000001

  structured_extraction:
    state: permitted

  semantic_indexing:
    state: permitted

  public_generation:
    state: prohibited

14.1. Rights Inheritance​

Assertions SHALL inherit applicable restrictions from all material sources.

14.2. Most-Restrictive Rule​

For multi-source assertions, the most restrictive applicable right SHALL prevail unless an authorised Rights Decision states otherwise.

14.3. Publication Rights​

Approval as a Knowledge Assertion SHALL NOT imply public publication permission.

14.4. Rights Revocation​

Rights revocation SHALL trigger impact analysis over:

  • the assertion;
  • derived relationships;
  • mappings;
  • embeddings;
  • Change Candidates;
  • projections;
  • Publications;
  • historical access.

15. Applicability​

Every assertion SHALL define where, to whom, to what and when it applies.

applicability:
  state: applicable

  jurisdictions:
    - eu

  sectors:
    - manufacturing

  organisation_roles:
    - ai-provider

  products:
    - zayaz

  device_models:
    - PP-KE-000101

  modules:
    - pergamum-pulse

  components:
    - knowledge-assertion-registry

  tenant_scope:
    mode: global

  white_label_scope:
    mode: global

  runtime_profiles: []

  valid_from: 2026-01-01
  valid_to: null

15.1. Applicability States​

States MAY include:

  • applicable;
  • conditionally applicable;
  • not applicable;
  • unresolved;
  • superseded;
  • historical only.

15.2. Conditional Applicability​

Conditions SHALL be machine-readable where possible.

15.3. Applicability Dimensions​

Dimensions MAY include:

  • jurisdiction;
  • sector;
  • organisation type;
  • legal role;
  • product;
  • service;
  • framework;
  • device class;
  • manufacturer;
  • product family;
  • model;
  • firmware;
  • Module;
  • Component;
  • Extension;
  • tenant;
  • white-label operator;
  • Runtime profile;
  • Publication class;
  • effective time.

15.4. Applicability Non-Generalisation​

An assertion applicable to one jurisdiction, product, model or firmware SHALL NOT be generalised without governed review.

15.5. Applicability Conflict​

Conflicting applicability determinations SHALL remain explicit.

16. Temporal Validity​

Assertions SHALL preserve bitemporal validity.

temporal:
  valid_from: 2026-01-01T00:00:00Z
  valid_to: null
  recorded_at: 2026-01-03T09:00:00Z
  superseded_at: null

16.1. Valid Time​

Valid time describes when the represented statement is true or applicable.

16.2. Transaction Time​

Transaction time describes when Pergamum Pulse recorded or changed the assertion.

16.3. Temporal Precision​

Temporal precision MAY be:

  • instant;
  • day;
  • month;
  • year;
  • interval;
  • unknown.

16.4. Retroactive Assertion​

A retroactively recorded assertion SHALL preserve both historical valid time and later transaction time.

16.5. Temporal Conflict​

Overlapping incompatible assertion versions SHALL create a conflict or Finding.

17. Confidence​

Confidence SHALL be multidimensional.

confidence:
  source: high
  extraction: high
  semantic: medium
  applicability: high
  rights: verified
  review: high
  overall: medium

17.1. Required Dimensions​

Dimensions SHOULD include:

  • source confidence;
  • extraction confidence;
  • semantic confidence;
  • applicability confidence;
  • rights confidence;
  • review confidence.

17.2. Confidence Scale​

A Profile MAY use:

  • high;
  • medium;
  • low;
  • unknown;

or a calibrated numeric scale.

17.3. Numeric Confidence​

Numeric confidence SHALL identify:

  • scale;
  • method;
  • calibration;
  • model or reviewer;
  • interpretation.

17.4. Confidence Non-Authority​

Confidence SHALL NOT:

  • create evidence;
  • create authority;
  • resolve conflict;
  • replace review;
  • permit activation.

17.5. Confidence Aggregation​

An overall confidence value SHALL not conceal weaker dimensions.

17.6. Confidence Drift​

A material confidence change SHALL trigger assertion review where downstream objects depend on it.

18. Uncertainty​

Assertions involving uncertainty SHALL represent it explicitly.

Uncertainty MAY include:

  • measurement uncertainty;
  • statistical uncertainty;
  • model uncertainty;
  • interpretation uncertainty;
  • applicability uncertainty;
  • source uncertainty;
  • rights uncertainty;
  • temporal uncertainty.
uncertainty:
  type: measurement
  value: 0.5
  unit_id: unit.degree-celsius
  coverage_factor: 2

Unknown uncertainty SHALL NOT be represented as zero.

19. Extraction and Transformation Provenance​

Every extracted assertion SHALL identify how it was created.

extraction:
  method: ai_assisted
  transformation_id: PP-TRN-000001
  parser:
    name: example-parser
    version: 2.1.0
  model:
    name: example-model
    version: 2026-07
  prompt_profile:
    id: PP-PROMPT-000001
    version: 1.2.0
  extracted_at: 2026-08-04T10:00:00Z

19.1. Extraction Methods​

Methods MAY include:

  • human authored;
  • human transcribed;
  • parser extracted;
  • OCR extracted;
  • rule extracted;
  • AI assisted;
  • AI generated candidate;
  • imported structured data;
  • calculated;
  • inferred.

19.2. Source Versus Derived Text​

Source text, machine extraction, human interpretation, translation and derived synthesis SHALL remain distinguishable.

19.3. Reproducibility​

A transformation SHOULD be reproducible from:

  • exact Source Capture;
  • parser version;
  • model version;
  • prompt profile;
  • configuration;
  • rights context.

19.4. Hallucination Risk​

AI-generated assertions without exact source support SHALL be blocked from approved source-supported status.

20. Review and Approval​

Every material assertion SHALL possess a Review Record appropriate to risk.

review:
  review_id: PP-RVW-000001
  status: approved
  reviewer:
    actor_id: actor.example
    role: domain_reviewer
  competence:
    domain: ai-governance
  reviewed_at: 2026-08-04T11:00:00Z
  findings: []

20.1. Review Classes​

Review classes MAY include:

  • source review;
  • extraction review;
  • semantic review;
  • legal review;
  • rights review;
  • technical review;
  • methodology review;
  • device review;
  • data-quality review;
  • Publication review;
  • Runtime review.

20.2. Review Outcomes​

Outcomes MAY include:

  • approved;
  • approved with conditions;
  • partially approved;
  • correction required;
  • additional evidence required;
  • disputed;
  • rejected;
  • quarantined;
  • unable to determine.

Review outcomes are Decision results and SHALL NOT be interpreted as universal object lifecycle states.

A review outcome MAY cause a governed lifecycle transition, but that transition SHALL be evaluated separately according to the assertion lifecycle profile defined by this specification and the universal lifecycle model defined by PP-KORS.

20.3. Reviewer Competence​

The reviewer SHALL possess competence appropriate to the assertion.

20.4. Separation of Duties​

High-impact assertions SHOULD separate:

  • extraction;
  • semantic review;
  • legal or rights review;
  • adoption Decision;
  • projection approval;
  • activation authority.

20.5. Review Expiration​

A review MAY expire due to:

  • source update;
  • licence change;
  • framework update;
  • model change;
  • applicability change;
  • new conflicting evidence;
  • required periodic review.

21. Assertion Status Model​

Assertion status SHALL separate distinct state dimensions.

status:
  extraction_status: human_reviewed
  review_status: approved
  conflict_status: none
  adoption_status: governed_reference
  projection_status: not_projected
  activation_status: not_applicable

21.1. Extraction Status​

Possible states:

  • proposed;
  • extracted;
  • human reviewed;
  • corrected;
  • rejected.

21.2. Review Status​

Possible states:

  • pending;
  • approved;
  • approved with conditions;
  • disputed;
  • rejected;
  • expired.

21.3. Conflict Status​

Possible states:

  • none;
  • potential conflict;
  • confirmed conflict;
  • under resolution;
  • resolved;
  • accepted divergence.

21.4. Adoption Status​

Possible states:

  • non-authoritative source;
  • proposed knowledge;
  • governed reference;
  • approved operational knowledge;
  • Core authoritative;
  • Extension authoritative;
  • rejected;
  • quarantined.

21.5. Projection Status​

Possible states:

  • not eligible;
  • candidate eligible;
  • Candidate created;
  • approved for projection;
  • projected;
  • projection superseded.

21.6. Activation Status​

Possible states:

  • not applicable;
  • not requested;
  • pending;
  • active;
  • suspended;
  • rolled back;
  • retired.

These state dimensions SHALL NOT be collapsed into one generic status.

21.7. Universal Lifecycle Profile​

Knowledge Assertions are first-class Pergamum Pulse objects and SHALL therefore possess a lifecycle_status conforming to PP-KORS.

The assertion lifecycle profile MAY use the following PP-KORS states:

  • proposed;
  • draft;
  • admitted;
  • active;
  • active with conditions;
  • review required;
  • disputed;
  • superseded;
  • withdrawn;
  • historical only;
  • rejected;
  • quarantined.

Other PP-KORS states MAY be used where their semantics apply to a Knowledge Assertion.

The following SHALL remain separate from lifecycle_status:

  • extraction status;
  • review status;
  • conflict status;
  • adoption status;
  • projection status;
  • activation status.

For avoidance of ambiguity:

  • extracted belongs to extraction_status;
  • approved and approved with conditions belong to review status or review outcomes;
  • projected belongs to projection_status;
  • Runtime active belongs to activation_status;
  • none of those values creates an additional universal lifecycle state.

A change in one state dimension SHALL NOT silently mutate another state dimension.

22. Composite Assertions and Decomposition​

A compound source statement SHOULD be decomposed into atomic assertions where independent governance, applicability or reuse is required.

Example source statement:

The device supports W-MBus and LoRaWAN when firmware 3.0 or later is installed.

Recommended decomposition:

Assertion A:
Device supports W-MBus under firmware >= 3.0.

Assertion B:
Device supports LoRaWAN under firmware >= 3.0.

22.1. Atomicity​

An assertion SHOULD express one independently testable semantic proposition.

22.2. Compound Assertion​

Where decomposition would distort meaning, a compound assertion MAY be used with explicit logical structure.

logic:
  operator: all_of
  operands:
    - PP-KA-000101
    - PP-KA-000102

22.3. Dependency​

Derived compound assertions SHALL preserve dependency on constituent assertions.

23. Negation, Absence and Unknown Semantics​

Negative assertions SHALL distinguish:

  • explicit prohibition;
  • explicit non-support;
  • observed absence;
  • source silence;
  • unknown;
  • not evaluated;
  • not applicable;
  • redacted;
  • unavailable.

Example:

object:
  kind: null_semantic
  state: not_stated

Source silence SHALL NOT be interpreted as prohibition or non-support.

An absent value SHALL NOT be interpreted as false.

24. Conditions, Exceptions and Qualifiers​

Every condition, exception or qualifier affecting meaning SHALL be machine-readable where feasible.

conditions:
  - type: firmware_minimum
    value: "3.0"

exceptions:
  - type: jurisdiction
    value: jurisdiction.example

qualifiers:
  - type: operational_mode
    value: low_power

A qualifier SHALL remain part of assertion identity and equivalence analysis.

25. Quantitative Assertions​

Quantitative assertions SHALL preserve:

  • numeric value;
  • datatype;
  • unit;
  • scale;
  • precision;
  • uncertainty;
  • source representation;
  • normalised representation;
  • valid range;
  • context.
object:
  kind: quantity
  value: 25.0
  datatype: decimal
  unit_id: unit.degree-celsius
  precision: 0.1

25.1. Units​

Units SHALL use governed Unit Registry identifiers.

25.2. Conversion​

A converted value SHALL preserve:

  • source value;
  • source unit;
  • target value;
  • target unit;
  • conversion rule;
  • conversion version;
  • rounding;
  • provenance.

25.3. Threshold​

A threshold assertion SHALL identify:

  • operator;
  • threshold value;
  • unit;
  • inclusivity;
  • conditions;
  • applicability.
threshold:
  operator: less_than_or_equal
  value: 50
  unit_id: unit.mg-per-litre

25.4. Range​

Range endpoints SHALL identify inclusivity and unknown boundaries.

25.5. Significant Figures​

Significant figures and rounding SHALL not imply greater precision than the source supports.

26. Formula and Methodology Assertions​

Formula assertions SHALL preserve:

  • formula identity;
  • source formula;
  • normalised formula;
  • variables;
  • units;
  • constants;
  • assumptions;
  • boundary conditions;
  • applicability;
  • method version;
  • validation;
  • provenance.
formula:
  formula_id: PP-FRM-000001
  expression: "activity_data * emission_factor"
  variables:
    activity_data:
      unit_dimension: activity
    emission_factor:
      unit_dimension: emissions_per_activity

26.1. Formula Non-Activation​

A formula assertion SHALL NOT become active Computation Hub logic without governed projection and activation.

26.2. Methodology Version​

A methodology update SHALL trigger impact analysis for dependent formulas and calculations.

26.3. Assumptions​

Material assumptions SHALL be represented as assertions or structured qualifiers.

27. Requirement, Control and Evidence Assertions​

Requirement assertions SHALL identify:

  • source requirement;
  • normative force;
  • obligated subject;
  • required action or state;
  • conditions;
  • exceptions;
  • jurisdiction;
  • effective time;
  • evidence expectations;
  • authority;
  • provenance.
assertion_type: requirement

subject:
  kind: role_reference
  role_id: role.ai-provider

predicate:
  predicate_id: pp.predicate.shall_maintain

object:
  kind: controlled_value
  registry: pp.control-objective-registry
  value_id: control.ai-risk-management

27.1. Requirement Non-Adoption​

An extracted external requirement SHALL NOT automatically become a ZAYAZ Requirement Registry object.

27.2. Control Assertion​

A control assertion MAY describe:

  • control objective;
  • control activity;
  • responsible Role;
  • evidence;
  • frequency;
  • effectiveness criterion;
  • applicability.

27.3. Evidence Assertion​

An evidence assertion SHALL identify:

  • claim supported;
  • evidence object;
  • evidence type;
  • provenance;
  • validity;
  • evidentiary authority;
  • limitations.

27.4. Certification Assertion​

Certification assertions SHALL distinguish:

  • certified object;
  • certification scheme;
  • certificate identity;
  • Certification Body;
  • accreditation;
  • scope;
  • validity;
  • status;
  • evidence.

A certification assertion SHALL NOT imply certification beyond recorded scope.

28. Device and Origin Assertions​

Device and Origin assertions MAY describe:

  • manufacturer;
  • product family;
  • model;
  • model variant;
  • firmware;
  • capability;
  • protocol;
  • signal type;
  • unit;
  • operating range;
  • accuracy;
  • calibration;
  • connector compatibility;
  • evidence requirements.

Example:

assertion_type: capability

subject:
  kind: entity_reference
  entity_id: PP-KE-device-model-001

predicate:
  predicate_id: pp.predicate.produces_signal_type

object:
  kind: controlled_value
  registry: pp.uso-type-registry
  value_id: uso_type.water.iot.measurement.volume.cumulative@v1

28.1. Model Versus Instance​

A device-model assertion SHALL NOT be interpreted as evidence that a particular tenant device instance:

  • is installed;
  • is configured;
  • is calibrated;
  • is functioning;
  • produces valid observations.

28.2. Firmware Applicability​

Firmware-specific capabilities SHALL include firmware applicability.

28.3. Manufacturer Authority​

Manufacturer evidence MAY support product specifications but SHALL NOT automatically establish field performance or legal compliance.

29. Dataset and Code-List Assertions​

Dataset assertions MAY describe:

  • dataset identity;
  • publisher;
  • version;
  • schema;
  • fields;
  • records;
  • code lists;
  • units;
  • quality;
  • licence;
  • update frequency;
  • applicability.

29.1. Record-Level Assertion​

A record-level assertion SHALL identify:

  • dataset version;
  • record identity;
  • field identity;
  • extracted value;
  • query or selection;
  • rights;
  • provenance.

29.2. Code-List Assertion​

A code-list assertion SHALL identify:

  • code;
  • label;
  • definition;
  • parent;
  • status;
  • validity;
  • source;
  • version.

29.3. Dataset Change​

Dataset version changes SHALL trigger affected-assertion analysis.

30. Relationship Generation​

A Knowledge Assertion MAY generate a candidate semantic relationship.

Knowledge Assertion
       ↓
Relationship Candidate
       ↓
Semantic Review
       ↓
Approved Mapping Object

The generated relationship SHALL preserve:

  • source assertion;
  • source fragments;
  • predicate;
  • subject;
  • object;
  • authority;
  • confidence;
  • applicability;
  • review;
  • provenance.

The relationship SHALL NOT be approved merely because the assertion is approved.

31. Entity Resolution Dependencies​

An assertion referencing unresolved entities SHALL identify provisional entities.

Entity resolution SHALL preserve:

  • candidate entities;
  • identifiers;
  • source evidence;
  • resolution method;
  • confidence;
  • reviewer;
  • decision;
  • provenance.

An entity merge or split SHALL trigger affected-assertion analysis.

32. Assertion Conflict Model​

Conflicting assertions SHALL remain first-class governed objects.

conflict:
  conflict_set_id: PP-CFS-000001
  assertion_ids:
    - PP-KA-000101
    - PP-KA-000102
  conflict_type: contradictory_value
  status: under_review

32.1. Conflict Types​

Conflict types MAY include:

  • contradictory value;
  • contradictory requirement;
  • contradictory applicability;
  • contradictory authority;
  • contradictory lifecycle;
  • version conflict;
  • jurisdictional divergence;
  • terminology conflict;
  • source conflict;
  • interpretation conflict.

32.2. Conflict Non-Destruction​

The system SHALL NOT delete or overwrite a competing assertion merely to produce one graph value.

32.3. Resolution Outcomes​

Outcomes MAY include:

  • one assertion confirmed;
  • both valid in different scopes;
  • both valid in different times;
  • source error;
  • interpretation error;
  • unresolved;
  • accepted divergence;
  • escalated.

32.4. Conflict Propagation​

A conflict SHALL propagate a caution or blocking state to dependent mappings, Change Candidates, projections and Publications according to risk.

33. Supersession, Correction and Withdrawal​

33.1. Supersession​

Supersession SHALL identify:

  • predecessor assertion;
  • successor assertion;
  • reason;
  • effective time;
  • compatibility;
  • affected objects;
  • provenance.

33.2. Correction​

Correction SHALL preserve the erroneous version and the corrected successor.

33.3. Withdrawal​

Withdrawal SHALL identify whether the assertion was:

  • valid until withdrawal;
  • invalid from inception;
  • superseded;
  • rights-restricted;
  • source-withdrawn;
  • historically retained;
  • deletion-required.

33.4. Retraction​

A retracted scientific or source claim SHALL trigger review of all dependent assertions.

34. Assertion Sets​

An Assertion Set groups assertions for a defined source, section, profile, entity or purpose.

assertion_set:
  assertion_set_id: PP-KAS-SET-000001
  purpose: source_clause_extraction
  members:
    - PP-KA-000001
    - PP-KA-000002
  set_version: 1.0.0

34.1. Set Non-Aggregation​

An Assertion Set SHALL NOT merge the identity, authority, rights or validity of its members.

34.2. Set Completeness​

A set MAY declare:

  • complete for source;
  • complete for section;
  • complete for extraction target;
  • partial;
  • materially incomplete;
  • unknown.

34.3. Set Versioning​

A changed member list or changed set purpose SHALL create a new set version.

35. Semantic Graph Integration​

Approved assertions MAY participate in the Pergamum Pulse semantic graph.

Graph integration SHALL preserve:

  • assertion identity;
  • source evidence;
  • authority;
  • rights;
  • applicability;
  • confidence;
  • temporal validity;
  • review;
  • conflict state;
  • provenance.

35.1. Graph Node and Edge Use​

An assertion MAY be represented as:

  • a statement node;
  • an edge with attached assertion identity;
  • a reified relationship;
  • a property assertion.

The chosen representation SHALL preserve all governed metadata.

35.2. Graph Traversal​

Traversal SHALL enforce:

  • tenant scope;
  • white-label scope;
  • rights;
  • temporal validity;
  • authority filters;
  • conflict handling;
  • result provenance.

35.3. Inference​

Inferred assertions SHALL be marked as inferred and SHALL identify:

  • inference rule;
  • rule version;
  • input assertions;
  • confidence;
  • reviewer requirement;
  • provenance.

35.4. Inference Non-Authority​

Inference SHALL NOT create authority beyond an approved rule and Decision.

36. Crosswalk and Mapping Use​

Assertions MAY support mappings between:

  • external requirements and ZAYAZ Controls;
  • regulations and Evidence Requirements;
  • device properties and Origin Registry properties;
  • dataset fields and schemas;
  • methodologies and computation models;
  • certification criteria and assessment tests.

A mapping SHALL remain a separate PP-MAP- object.

An assertion SHALL not be used as a silent substitute for a mapping Decision.

37. Change Candidate Generation​

A material assertion MAY generate a PP-CC- Change Candidate.

candidate_generation:
  assertion_id: PP-KA-000001
  candidate_target:
    object_type: requirement_registry
    object_id: REQ-000042
  proposed_operation: modify

37.1. Candidate Preconditions​

Candidate generation SHOULD require:

  • approved or conditionally approved assertion;
  • complete evidence;
  • resolved rights;
  • applicable scope;
  • sufficient confidence;
  • no blocking conflict;
  • impact analysis.

37.2. Candidate Non-Approval​

Generation of a Candidate SHALL NOT approve the Candidate.

37.3. Candidate Traceability​

Every Candidate SHALL preserve complete assertion lineage.

38. Projection and Activation Boundary​

An assertion MAY contribute to a Projection Manifest only after required Decisions.

Assertion
   ↓
Change Candidate
   ↓
Change Decision
   ↓
Projection Manifest
   ↓
HECATE Validation
   ↓
Separate Activation

An approved assertion alone SHALL NOT:

  • alter a Registry;
  • modify a schema;
  • update Runtime;
  • change a policy;
  • publish a claim;
  • change certification criteria.

39. Tenant and White-Label Isolation​

Every assertion SHALL preserve knowledge scope.

39.1. Tenant Assertion​

A tenant assertion SHALL identify:

  • tenant;
  • source;
  • rights;
  • confidentiality;
  • permitted Components;
  • promotion eligibility;
  • retention;
  • deletion.

39.2. White-Label Assertion​

A white-label assertion SHALL preserve operator scope and SHALL not leak into other white-label deployments.

39.3. Global Promotion​

Promotion to global canonical knowledge SHALL require:

  • rights approval;
  • confidentiality review;
  • semantic review;
  • conflict review;
  • applicability review;
  • approval;
  • provenance.

39.4. Retrieval Isolation​

Assertion retrieval SHALL enforce scope across:

  • full-text indexes;
  • semantic indexes;
  • vector stores;
  • graph traversal;
  • caches;
  • prompts;
  • exports;
  • logs.

40. Security, Privacy and Confidentiality​

Assertions MAY contain:

  • personal data;
  • confidential business data;
  • trade secrets;
  • legally privileged information;
  • security-sensitive information;
  • copyright-restricted content.

Security classification SHALL control:

  • access;
  • display;
  • retrieval;
  • embedding;
  • export;
  • AI processing;
  • Publication;
  • retention;
  • deletion.

40.1. Sensitive Literal​

Sensitive literal values SHOULD be tokenised, encrypted, redacted or referenced rather than broadly duplicated.

40.2. Relationship Sensitivity​

The existence of a relationship between entities MAY itself be confidential.

40.3. Least Privilege​

Reviewers, Agents and Components SHALL receive only the assertion access required for their purpose.

41. Assertion Quality​

Assertion quality MAY be measured across:

  • evidence completeness;
  • source authority;
  • extraction quality;
  • semantic clarity;
  • applicability completeness;
  • rights completeness;
  • temporal completeness;
  • review quality;
  • conflict state;
  • freshness;
  • provenance completeness.

Quality metrics SHALL NOT create authority.

41.1. Staleness​

An assertion MAY become stale where:

  • source version changes;
  • source is withdrawn;
  • review expires;
  • licence changes;
  • applicability changes;
  • predicate definition changes;
  • referenced entity changes;
  • new conflicting evidence appears.

41.2. Quality Finding​

A Finding SHALL identify:

  • assertion;
  • criterion;
  • expected state;
  • observed state;
  • severity;
  • downstream impact;
  • remediation;
  • provenance.

42. AI Agent Boundaries​

AI Agents MAY:

  • identify candidate assertions;
  • classify assertion types;
  • propose subject, predicate and object;
  • locate supporting fragments;
  • estimate confidence;
  • identify conflicts;
  • propose mappings;
  • draft Change Candidates;
  • assist review.

AI Agents SHALL NOT independently:

  • grant authority;
  • grant rights;
  • approve legal interpretation;
  • approve disputed semantics;
  • approve a Change Candidate;
  • activate a projection;
  • publish a restricted claim;
  • conceal uncertainty;
  • invent source evidence.

42.1. Agent Provenance​

Every Agent-generated assertion SHALL identify:

  • Agent identity;
  • Agent Profile;
  • model;
  • model version;
  • prompt profile;
  • tools;
  • retrieved fragments;
  • time;
  • output;
  • human review state;
  • provenance.

43. HECATE Validation​

HECATE SHALL validate objective assertion structure including:

  • assertion identifier;
  • prefix;
  • version;
  • assertion type;
  • subject kind;
  • predicate registration;
  • object kind;
  • subject and object class constraints;
  • source-fragment linkage;
  • normative-force structure;
  • authority dimensions;
  • rights references;
  • applicability;
  • confidence fields;
  • temporal validity;
  • review status;
  • conflict status;
  • tenant scope;
  • Module lineage;
  • Component lineage;
  • provenance.

HECATE SHALL NOT:

  • invent assertion meaning;
  • invent evidence;
  • grant authority;
  • grant rights;
  • decide disputed legal interpretation;
  • resolve expert conflict autonomously;
  • infer equivalence solely from text similarity;
  • approve Runtime activation.

44. Module and Component Lineage​

Every material assertion SHALL identify:

  • accountable Module;
  • Assertion Registry Component;
  • source-capture Component;
  • transformation Component;
  • semantic-review Component or workflow;
  • graph Component;
  • mapping Component;
  • affected Modules;
  • affected Components;
  • Runtime-consuming Components;
  • Publication-consuming Components.

No orphan Component lineage is permitted.

45. Provenance​

Assertion provenance SHALL connect:

  • Source Object;
  • Source Capture;
  • Rights Record;
  • Knowledge Document;
  • Knowledge Section;
  • Source Fragment;
  • extraction transformation;
  • parser;
  • OCR process;
  • translation process;
  • AI model;
  • prompt profile;
  • human reviewer;
  • authority review;
  • rights review;
  • applicability review;
  • conflict review;
  • assertion version;
  • relationship conversion;
  • mapping;
  • Change Candidate;
  • Change Decision;
  • Projection Manifest;
  • Publication;
  • Module lineage;
  • Component lineage;
  • tenant lineage;
  • white-label lineage;
  • valid time;
  • transaction time.
provenance:
  provenance_graph_id: PP-PROV-000001
  source_objects:
    - PP-SRC-000001
  source_captures:
    - PP-CAP-000001
  source_fragments:
    - PP-SF-000031
  transformation_id: PP-TRN-000001
  review_ids:
    - PP-RVW-000001
  created_at: 2026-08-04T10:00:00Z

45.1. Provenance Completeness​

Completeness states MAY include:

  • complete;
  • complete with controlled redaction;
  • materially complete;
  • partial;
  • reconstructed;
  • materially incomplete;
  • disputed;
  • unavailable.

45.2. Incomplete Provenance​

Materially incomplete provenance SHALL block:

  • automation eligibility;
  • authoritative projection;
  • unqualified Publication;
  • definitive historical claim;
  • certification reliance.

46. Historical Reconstruction​

Historical reconstruction SHALL answer:

  • which assertion version existed;
  • which source version supported it;
  • which Source Capture was used;
  • which Source Fragments were cited;
  • which rights applied;
  • which authority was assigned;
  • which applicability applied;
  • which confidence was recorded;
  • which reviewer approved it;
  • whether conflict existed;
  • which mappings depended on it;
  • which Change Candidates were generated;
  • which projections used it;
  • which Publications cited it;
  • which Runtime state, if any, was separately activated.

46.1. Exact Replay​

Exact Replay SHALL reconstruct the assertion using the historical object, predicate, entity, rights and schema versions.

46.2. Semantic Replay​

Semantic Replay MAY evaluate the historical assertion under a later approved interpretation profile.

Exact Replay and Semantic Replay SHALL remain distinct.

46.3. Non-Retroactivity​

Current authority, rights, predicate definitions, mappings or entity resolution SHALL NOT be silently applied to historical assertions.

47. Conformance Levels​

47.1. Level 1 — Identifiable​

The assertion has:

  • stable identifier;
  • assertion type;
  • subject;
  • predicate;
  • object;
  • lifecycle;
  • basic provenance.

47.2. Level 2 — Evidence-Governed​

It additionally has:

  • exact source evidence;
  • authority;
  • rights;
  • applicability;
  • temporal validity;
  • confidence;
  • review.

47.3. Level 3 — Graph-Integrated​

It additionally has:

  • resolved or explicitly provisional entities;
  • Registry-governed predicate;
  • graph-valid structure;
  • conflict treatment;
  • Module lineage;
  • Component lineage;
  • tenant isolation.

47.4. Level 4 — Automation-Eligible​

It additionally has:

  • complete provenance;
  • approved evidence;
  • resolved rights;
  • approved applicability;
  • sufficient confidence;
  • no blocking conflict;
  • HECATE validation;
  • approved Change Decision where projection is intended;
  • explicit activation boundary.

Automation eligibility SHALL NOT mean automatic activation.

48. Conformance Fixtures​

Implementations SHOULD provide fixtures for:

  • valid identity assertion;
  • valid definition assertion;
  • valid requirement assertion;
  • valid prohibition assertion;
  • valid permission assertion;
  • valid capability assertion;
  • valid compatibility assertion;
  • valid quantitative assertion;
  • valid threshold assertion;
  • valid range assertion;
  • valid formula assertion;
  • valid evidence assertion;
  • valid applicability assertion;
  • assertion with entity subject;
  • assertion with class subject;
  • assertion with compound subject;
  • assertion with entity object;
  • assertion with controlled value;
  • assertion with quantity;
  • assertion with explicit unknown;
  • assertion without identifier;
  • assertion with invalid prefix;
  • assertion without source fragment;
  • assertion with unsupported predicate;
  • assertion with invalid subject class;
  • assertion with invalid object kind;
  • assertion with unresolved subject;
  • assertion with multiple sources;
  • assertion with fragment-level rights restriction;
  • assertion approved for knowledge but prohibited from Publication;
  • assertion with separate legal and ZAYAZ authority;
  • assertion with Runtime authority incorrectly inferred;
  • assertion with conditional applicability;
  • assertion with jurisdiction-specific applicability;
  • assertion with firmware applicability;
  • bitemporal assertion;
  • retroactively recorded assertion;
  • temporally conflicting assertions;
  • assertion with multidimensional confidence;
  • assertion with unknown uncertainty;
  • parser-extracted assertion;
  • AI-assisted assertion;
  • AI assertion without source support;
  • approved human-reviewed assertion;
  • disputed assertion;
  • rejected assertion;
  • superseded assertion;
  • withdrawn assertion;
  • compound assertion requiring decomposition;
  • negative assertion;
  • source-silence case;
  • quantity conversion;
  • formula with incompatible units;
  • certification assertion with bounded scope;
  • device-model assertion incorrectly applied to instance;
  • dataset record assertion;
  • relationship candidate generated from assertion;
  • conflicting assertion set;
  • tenant-scoped assertion;
  • prohibited cross-tenant retrieval;
  • stale assertion;
  • complete provenance;
  • materially incomplete provenance;
  • historical Exact Replay;
  • Semantic Replay;
  • Change Candidate generated without approval;
  • projected assertion without activation authority.

49. Migration and Compatibility​

Specification revisions SHALL identify:

  • source specification version;
  • target specification version;
  • changed assertion fields;
  • changed assertion types;
  • changed predicate definitions;
  • changed object kinds;
  • changed normative-force classes;
  • changed authority fields;
  • changed applicability fields;
  • changed confidence model;
  • migration rules;
  • compatibility;
  • affected assertions;
  • affected mappings;
  • affected projections;
  • validation;
  • provenance.

Migration SHALL NOT:

  • reuse assertion identifiers;
  • overwrite historical versions;
  • infer missing evidence;
  • infer authority;
  • infer rights;
  • infer applicability;
  • convert unknown to false;
  • merge conflicting assertions silently;
  • approve rejected assertions;
  • activate projected output.

49.1. Predicate Migration​

A changed predicate SHALL trigger:

  • affected-assertion enumeration;
  • semantic compatibility assessment;
  • mapping impact analysis;
  • projection impact analysis;
  • migration receipt.

49.2. Entity Migration​

An entity merge, split or reclassification SHALL preserve original assertion references and historical graph state.

50. Security Requirements​

Assertion stores and graph representations SHALL enforce:

  • authentication;
  • authorisation;
  • least privilege;
  • tenant isolation;
  • white-label isolation;
  • rights-aware retrieval;
  • encryption;
  • access logging;
  • tamper evidence;
  • backup;
  • recovery;
  • incident response.

Sensitive assertion metadata SHALL not be exposed merely because the canonical statement is non-sensitive.

51. Conformance Requirements​

An implementation conforms to this specification where it:

  1. assigns every first-class assertion a stable PP-KA- identifier;
  2. prevents assertion identifier reuse;
  3. distinguishes semantic identity from textual similarity;
  4. preserves independent assertion versions;
  5. preserves immutable approved assertion versions;
  6. represents assertions using typed subject, predicate and object structures;
  7. governs predicates through a Predicate Registry;
  8. prevents machine-actionable use of ungoverned free-text predicates;
  9. supports entity, class, assertion, literal, quantity, range, formula and null-semantic objects;
  10. distinguishes unknown, absent, not applicable, not evaluated, prohibited and redacted states;
  11. governs assertion types through a Registry;
  12. represents normative force explicitly;
  13. prevents source normative force from automatically creating ZAYAZ authority;
  14. links every material assertion to exact Source Fragments;
  15. preserves multi-source evidence independently;
  16. prevents unsupported assertions from being approved as source-supported knowledge;
  17. propagates source withdrawal to dependent assertions;
  18. represents source, legal, evidentiary, ZAYAZ governance and Runtime authority separately;
  19. prevents authority transfer between dimensions;
  20. preserves evidentiary scope;
  21. preserves Rights Record relationships;
  22. prevents assertion approval from implying Publication permission;
  23. propagates rights revocation to dependent objects;
  24. represents applicability explicitly;
  25. prevents unauthorised applicability generalisation;
  26. preserves jurisdiction, sector, role, product, device, firmware, Module, Component, tenant, white-label and temporal applicability where relevant;
  27. preserves bitemporal validity;
  28. represents temporal uncertainty explicitly;
  29. preserves multidimensional confidence;
  30. prevents confidence from replacing evidence, review or authority;
  31. represents uncertainty explicitly;
  32. preserves extraction and transformation provenance;
  33. distinguishes source text, machine extraction, human interpretation, translation and synthesis;
  34. records parser, model and prompt-profile versions;
  35. blocks unsupported AI-generated assertions from approved source-supported status;
  36. requires risk-appropriate review;
  37. preserves reviewer competence;
  38. separates extraction, review, adoption, projection and activation states;
  39. decomposes compound assertions where independent governance is required;
  40. preserves logical structure where compound assertions remain necessary;
  41. distinguishes negation from source silence;
  42. represents conditions, exceptions and qualifiers;
  43. preserves quantitative value, unit, precision and uncertainty;
  44. preserves conversion lineage;
  45. prevents false precision;
  46. preserves formulas, variables, units, assumptions and methodology versions;
  47. prevents formula assertions from becoming active Computation Hub logic without projection and activation;
  48. governs requirement, control, evidence and certification assertions;
  49. prevents certification assertions from exceeding certificate scope;
  50. distinguishes device-model assertions from tenant device-instance evidence;
  51. preserves firmware applicability;
  52. governs dataset and code-list assertions;
  53. generates semantic relationships only through governed conversion;
  54. preserves entity-resolution decisions;
  55. preserves conflicts as first-class states;
  56. prevents silent conflict deletion;
  57. propagates blocking conflicts to dependent outputs;
  58. preserves supersession, correction and withdrawal history;
  59. supports Assertion Sets without merging member authority or rights;
  60. preserves assertion metadata in semantic graph representations;
  61. marks inferred assertions explicitly;
  62. prevents inference from creating authority;
  63. keeps mappings separate from assertions;
  64. generates Change Candidates only through traceable processes;
  65. prevents Candidate generation from approving a change;
  66. separates assertion approval, projection and activation;
  67. enforces tenant and white-label isolation;
  68. governs promotion to global knowledge;
  69. enforces rights and scope across indexes, vectors, graphs, prompts, exports and logs;
  70. protects sensitive assertions and relationships;
  71. measures quality without creating authority;
  72. detects stale assertions;
  73. prevents AI Agents from granting authority, rights or activation;
  74. validates objective structure through HECATE;
  75. prevents HECATE from inventing meaning or evidence;
  76. preserves Module lineage;
  77. preserves Component lineage;
  78. preserves complete assertion provenance;
  79. blocks automation where provenance is materially incomplete;
  80. supports Exact Replay and Semantic Replay;
  81. prevents retroactive reinterpretation of historical assertions;
  82. defines four conformance levels;
  83. supports conformance fixtures;
  84. governs migration and compatibility;
  85. enforces security, auditability and historical trust.

52. Foundational Principle​

A Knowledge Assertion is the governed bridge between source evidence and machine-actionable meaning.

It SHALL preserve what was stated, what it means, what it applies to, who or what supports it, how certain it is, what rights govern it, when it was valid, who reviewed it and what downstream objects depend on it.

Text similarity is not semantic identity. Confidence is not evidence. Evidence is not authority. Approval is not adoption. Adoption is not projection. Projection is not activation.

An assertion without exact evidence is an unsupported proposition. An assertion without applicability is unsafe to reuse. An assertion without rights is unsafe to process or publish. An assertion without provenance is unsafe to trust. A conflicting assertion that has been hidden is more dangerous than a conflict that remains visible.

By governing assertions as stable, typed, evidence-linked, rights-aware, bitemporal and historically reconstructable objects, Pergamum Pulse can support regulatory intelligence, framework crosswalks, device knowledge, scientific methodologies, certification evidence and controlled ZAYAZ evolution without surrendering constitutional authority or operational safety.



GitHub RepoRequest for Change (RFC)
Last updated on by ZAYAZ