Pergamum Pulse Knowledge Document Metadata Specification

Version 0.2 — Framework-Aligned Metadata Contract

This specification defines the minimum and extended metadata required for governed knowledge documents inside Pergamum Pulse.

It applies to canonical MDX representations of:

• laws;
• regulations;
• delegated acts;
• regulatory guidance;
• standards;
• certification schemes;
• assurance criteria;
• methodologies;
• reporting frameworks;
• IoT manuals;
• technical data sheets;
• firmware notes;
• communication-protocol specifications;
• API specifications;
• device profiles;
• product declarations;
• certificates;
• datasets;
• code lists;
• registries;
• scientific papers;
• industry guidance;
• supplier documentation;
• contractual documents;
• internal Viroway standards;
• ZAYAZ architecture documents;
• EcoWorld Academy material;
• implementation guidance;
• derived knowledge documents;
• composite knowledge syntheses.

The specification establishes the metadata contract for the broader Pergamum Pulse Knowledge Document and Metadata Framework.

The governing rule is:

Pergamum Pulse SHALL preserve external and internal knowledge as governed, versioned and provenance-complete knowledge artefacts. A Knowledge Document SHALL NOT become authoritative Core, Runtime, Extension, Registry, schema, policy, workflow, computation, Publication or certification state merely because it has been ingested, transformed or rendered as MDX.

Version 0.2 aligns the operational metadata contract with PP-KDMF Part I.

It introduces:

• first-class SourceSeries, SourceFragment, KnowledgeEntity, KnowledgeBundle, MappingObject and ChangeDecision objects;
• PP-prefixed object identity conventions;
• independent source, legal, evidentiary, ZAYAZ governance and Runtime authority dimensions;
• typed object relationships;
• profile and extension rules;
• property-specific inheritance;
• fragment-level rights;
• separate processing rights for parsing, OCR, embeddings, retrieval and model training;
• independent version lines;
• explicit unknown and unresolved semantics;
• projection and activation separation;
• migration from PP-KDMS@0.1.0.

---

1. Architectural Purpose

Pergamum Pulse SHALL operate as ZAYAZ's governed knowledge plane.

It SHALL:

• preserve source identity;
• preserve source authority;
• preserve source versions;
• preserve original source references;
• preserve copyright and licensing conditions;
• preserve publication permissions;
• preserve acquisition history;
• preserve transformation history;
• preserve human and AI review history;
• preserve semantic assertions;
• preserve applicability;
• preserve Module and Component lineage;
• generate governed Change Candidates;
• support generated projections into runtime Registries and schemas;
• support historical reconstruction.

Pergamum Pulse SHALL NOT be the hot-path operational store for:

• live IoT observations;
• tenant credentials;
• API secrets;
• serial-number-specific device installations;
• customer-specific calibration records;
• facility-specific configuration;
• high-frequency Runtime state;
• uncontrolled operational telemetry.

The architectural distinction is:

Pergamum Pulse:
"What is this device, framework, requirement or source?"

Runtime Registry:
"Which governed profile is active for this tenant and Runtime?"

Observation Store:
"What happened at this installation at this time?"

---

2. Knowledge Object Model

Pergamum Pulse SHALL distinguish the following first-class object classes.

Object	Identifier prefix	Purpose
SourceSeries	PP-SRS-	Groups successive editions, releases or versions of a source
SourceObject	PP-SRC-	Identifies the original source and issuing authority
SourceCapture	PP-CAP-	Records a specific acquisition event and chain of custody
RightsRecord	PP-RGT-	Records copyright, licence, agreement and processing permissions
KnowledgeDocument	PP-KD-	Canonical MDX representation of one or more source captures
KnowledgeSection	PP-KS-	Stable, addressable section within a Knowledge Document
SourceFragment	PP-SF-	Exact page, clause, table, row, figure, field or record supporting knowledge
KnowledgeAssertion	PP-KA-	Structured statement derived from one or more source fragments
KnowledgeEntity	PP-KE-	Real, legal, technical, conceptual or organisational entity described by sources
KnowledgeBundle	PP-KB-	Purpose-bound grouping that preserves member authority and rights separately
CitationObject	PP-CIT-	Rights-aware citation and source-locator record
MappingObject	PP-MAP-	Typed semantic, structural, applicability or equivalence relationship
ExtractionTarget	PP-XT-	Candidate Registry, schema, JSON, rule, test or profile target
ChangeCandidate	PP-CC-	Proposed change to a governed ZAYAZ artefact
ChangeDecision	PP-CD-	Approval, rejection, deferment, condition or escalation decision
ProjectionManifest	PP-PRJ-	Records generated outputs, digests and source lineage
HistoricalRecord	PP-HR-	Preserves immutable prior state, supersession and reconstruction metadata

These objects SHALL remain distinct even where a single MDX file embeds metadata for several of them.

2.1. Source–Document–Entity Separation

A source, document and described entity SHALL NOT share identity merely for convenience.

Source Object
    └── captured as Source Capture
            └── represented by Knowledge Document
                    ├── contains Knowledge Sections
                    ├── cites Source Fragments
                    ├── expresses Knowledge Assertions
                    └── describes Knowledge Entities

A technical manual is not the device model it describes.

A regulation publication is not the legal requirement extracted from it.

An ISO publication is not a Certification Scheme operated by a Certification Body.

2.2. Knowledge Bundle Non-Aggregation Rule

A Knowledge Bundle MAY group manuals, data sheets, certificates, firmware notes, regulatory sources and assertions.

It SHALL NOT merge:

• copyright;
• licence;
• authority;
• version;
• validity;
• confidentiality;
• tenant scope;
• evidentiary weight.

2.3. Object Identity Rules

Every first-class object SHALL:

• possess a stable PP-prefixed identifier;
• possess a semantic identifier where materially reusable;
• preserve lifecycle;
• preserve valid time and transaction time where applicable;
• preserve provenance;
• avoid identifier reuse for incompatible identity.

---

3. Metadata Conformance Levels

The specification defines four metadata conformance levels.

3.1. Level 1 — Identifiable

A document is identifiable where it has:

• stable identity;
• canonical name;
• type;
• version;
• status;
• owner;
• language;
• source identity;
• copyright owner;
• source URL or source-location reference.

3.2. Level 2 — Governed

A document is governed where it additionally has:

• source authority;
• capture metadata;
• rights and licence metadata;
• lifecycle;
• temporal validity;
• review state;
• provenance;
• access classification;
• tenant or white-label scope.

3.3. Level 3 — Machine-Actionable

A document is machine-actionable where it additionally has:

• structured applicability;
• knowledge classes;
• assertion inventory;
• inheritance rules;
• extraction targets;
• validation status;
• impact targets;
• projection rules.

3.4. Level 4 — Automation-Eligible

A document is automation-eligible where it additionally has:

• approved transformation profile;
• verified source coverage;
• rights permission for the intended use;
• HECATE validation;
• approved Change Candidate rules;
• human review where required;
• complete source-to-assertion lineage;
• explicit activation prohibition or permission;
• Projection Manifest requirements.

Automation eligibility SHALL NOT equal constitutional authority.

---

4. Core Frontmatter Contract

Every Pergamum Pulse Knowledge Document SHALL use YAML frontmatter.

The minimum top-level contract is:

---
id: PP-KD-00000001
semantic_id: pp.knowledge.example
canonical_name: Example Knowledge Document
title: Example Knowledge Document
document_type: external_knowledge
status: draft
version: 0.1.0
language: en
owner:
  - knowledge-governance@viroway.com

source: {}
capture: {}
authority: {}
rights: {}
transformation: {}
temporal: {}
applicability: {}
knowledge: {}
change_intelligence: {}
provenance: {}
---

Unknown values SHALL be explicit.

Missing SHALL NOT be represented as false.

4.1. Explicit State Semantics

For material permission, applicability, authority and validation fields, permitted states SHALL distinguish:

• permitted;
• permitted_with_conditions;
• prohibited;
• restricted;
• unknown;
• unresolved;
• not_applicable;
• not_evaluated;
• expired;
• revoked.

An omitted field SHALL NOT be interpreted as permission, applicability, validity or approval.

4.2. Base Specification and Profile Declaration

Every conforming document SHOULD declare:

metadata_contract:
  specification:
    id: PP-KDMS
    version: 0.2.0
  profiles: []
  conformance_target: governed

---

5. Identity Metadata

5.1. Required Fields

Every Knowledge Document SHALL include:

• id;
• semantic_id;
• canonical_name;
• title;
• document_type;
• status;
• version;
• language;
• owner.

5.2. Stable Identifier

id SHALL be immutable and unique.

Example:

id: PP-KD-00001234

5.3. Semantic Identifier

semantic_id SHALL identify the conceptual identity independently of file path.

Example:

semantic_id: pp.knowledge.framework.iso-iec-42001.2023

5.4. Canonical Name

canonical_name SHALL be the governed human-readable name.

5.5. Aliases

Aliases MAY include:

aliases:
  - ISO 42001
  - AIMS Standard

Aliases SHALL NOT create equivalent identity.

5.6. Document Types

Permitted classes SHOULD include:

• law;
• regulation;
• regulatory_guidance;
• standard;
• certification_scheme;
• assurance_standard;
• methodology;
• framework;
• technical_manual;
• datasheet;
• protocol_specification;
• api_specification;
• device_profile;
• product_profile;
• certificate;
• dataset_description;
• code_list;
• registry_description;
• scientific_paper;
• industry_guidance;
• contractual_source;
• viroway_standard;
• zayaz_architecture;
• ecoworld_publication;
• implementation_guidance;
• derived_knowledge;
• composite_knowledge.

5.7. Lifecycle Status

Status MAY include:

• draft;
• ingested;
• parsed;
• extracted;
• review_pending;
• reviewed;
• approved;
• active;
• active_with_conditions;
• deprecated;
• superseded;
• withdrawn;
• retired;
• historical_only;
• rejected;
• quarantined.

---

5A. Typed Relationship Metadata

Typed relationships SHALL replace ambiguous free-form references.

relationships:
  governed_by:
    - PP-KDMF
  represents:
    - PP-SRC-000001
  based_on:
    - PP-CAP-000001
  rights_governed_by:
    - PP-RGT-000001
  describes:
    - PP-KE-000001
  member_of:
    - PP-KB-000001
  supports_assertions:
    - PP-KA-000001
  generates_candidates:
    - PP-CC-000001
  supersedes:
    - PP-KD-000001@0.1.0

Relationship types SHALL eventually be Registry-governed.

A relationship SHALL preserve:

• relationship identity where material;
• source object;
• target object;
• relationship type;
• scope;
• validity;
• authority;
• confidence where derived;
• provenance.

---

6. Source Metadata

Every Knowledge Document SHALL identify the original source.

source:
  source_id: PP-SRC-00004567
  source_type: external_standard
  publisher: ISO
  issuing_authority: International Organization for Standardization
  title: ISO/IEC 42001:2023
  edition: 1
  publication_date: 2023-12
  official_url: https://example.invalid/official-source
  jurisdiction:
    - international
  authority_class: standards_body
  source_digest: sha256:...

6.1. Required Source Fields

Required fields SHALL include:

• source_id;
• source_type;
• publisher or issuing organisation;
• title;
• source_version, edition or equivalent;
• official_url or controlled source-location reference;
• authority_class;
• source_digest where source bytes are held.

6.2. Source Type

Source types MAY include:

• official publication;
• licensed publication;
• official website;
• official API;
• official Registry;
• manufacturer publication;
• supplier publication;
• regulator communication;
• contractual document;
• internal Viroway source;
• third-party secondary source;
• scientific source;
• public dataset;
• archived source;
• user-supplied source.

6.3. Source Authority Classes

Authority classes MAY include:

• legislature;
• regulator;
• court;
• standards body;
• accreditation body;
• certification body;
• assurance body;
• manufacturer;
• product owner;
• methodology owner;
• dataset authority;
• contractual counterparty;
• Viroway constitutional authority;
• Viroway operational authority;
• recognised scientific authority;
• industry association;
• informational publisher;
• unknown.

6.4. Source Locator

The source locator SHALL support:

• public URL;
• authenticated URL;
• repository path;
• document-management reference;
• licensed-library reference;
• archive reference;
• physical-record reference.

Example:

source:
  official_url: https://publisher.example/document
  controlled_copy_location: restricted://standards/document-001

The controlled location SHALL NOT be exposed publicly unless authorised.

---

7. Source Capture Metadata

Every acquired source SHALL have a SourceCapture.

capture:
  capture_id: PP-CAP-00007891
  captured_at: 2026-08-04T08:00:00Z
  captured_by:
    actor_type: component
    actor_id: regulatory-ingestion-service
  acquisition_method: official_download
  original_filename: source.pdf
  media_type: application/pdf
  source_size_bytes: 1234567
  source_digest: sha256:...

7.1. Required Capture Fields

Required fields SHALL include:

• capture identity;
• capture time;
• acquiring actor;
• acquisition method;
• original media type;
• original filename where applicable;
• digest;
• capture success state.

7.2. Acquisition Methods

Methods MAY include:

• official download;
• API retrieval;
• authenticated portal download;
• email attachment;
• manual upload;
• repository checkout;
• web archive capture;
• regulator feed;
• supplier portal;
• direct contractual delivery;
• physical scan.

7.3. Chain of Custody

Capture SHALL preserve:

• origin;
• collector;
• transfer;
• storage;
• transformation;
• review;
• export;
• archive;
• destruction.

---

8. Rights Record Reference and Metadata Projection

Rights governance for Pergamum Pulse SHALL be defined by PP-RLCPS — Rights, Licensing, Citation and Publication Specification.

Every Pergamum Pulse Knowledge Document SHALL possess or reference a canonical PP-RGT- Rights Record governed by PP-RLCPS.

The rights: block defined by this specification is a metadata projection and reference layer. It SHALL NOT constitute an independent Rights Record and SHALL NOT redefine rights semantics, permission states, processing operations or publication rights.

The canonical Rights Record SHALL remain the authority for:

• copyright;
• permission basis;
• licence and agreement references;
• rights scope;
• processing rights;
• publication rights;
• attribution;
• validity;
• evidence;
• rights status;
• provenance.

Where projected metadata differs from the referenced Rights Record, the canonical Rights Record SHALL prevail and the Knowledge Document SHALL fail rights-projection conformance.

rights:
  rights_record_id: PP-RGT-00000918
  rights_record_version: 1.0.0

  projection:
    status: verified

    processing_rights:
      parsing:
        state: permitted
      ocr:
        state: permitted
      structured_extraction:
        state: permitted
      semantic_indexing:
        state: permitted
      embeddings:
        state: permitted_with_conditions
      vector_storage:
        state: permitted_with_conditions
      retrieval_augmented_generation:
        state: restricted
      model_evaluation:
        state: prohibited
      fine_tuning:
        state: prohibited
      foundation_model_training:
        state: prohibited

    publication_rights:
      internal_publication:
        state: permitted
      public_web_publication:
        state: prohibited

    attribution:
      required: true
      text: "© 2026 Viroway Ltd"

8.1. Required Rights Reference Fields

8.1. Required Rights Reference Fields

Every governed Knowledge Document SHALL include:

• rights_record_id;
• Rights Record version or immutable version reference where applicable;
• sufficient projection metadata to evaluate the operations required by the document's active metadata and processing profiles.

The rights_record_id SHALL resolve to a PP-RGT- object governed by PP-RLCPS.

A missing projected property SHALL mean not projected. It SHALL NOT mean permitted, prohibited, unresolved or not applicable.

Automation eligibility SHALL require the canonical Rights Record to be resolved and the applicable permissions required by the intended operation to be determinable.

8.2. Rights Vocabulary Authority

Permission bases, permission states, processing-right keys, publication-right keys and attribution semantics SHALL be resolved from PP-RLCPS.

This specification SHALL NOT maintain an independent enumeration of those values.

8.3. Rights Evidence

Rights evidence SHALL be governed by the canonical Rights Record and associated Rights Evidence objects defined by PP-RLCPS.

KDMS metadata MAY expose references required for review or automation but SHALL NOT duplicate or replace the canonical evidence record.

Every non-trivial right SHALL link to evidence.

rights:
  rights_evidence:
    - evidence_id: PP-RGT-EV-0001
      evidence_type: licence_agreement
      evidence_url: restricted://legal/licences/agreement-001
      effective_from: 2026-01-01
      effective_to: 2027-12-31
      verified_by: legal-reviewer
      verified_at: 2026-01-05T10:00:00Z

8.4. Cited Source Rights

Where a Knowledge Document cites, quotes, reproduces, transforms or derives data from another document, the citation SHALL include:

• exact source;
• source URL;
• source locator;
• copyright holder;
• licence or agreement;
• permitted use;
• required attribution;
• quotation or reproduction limits;
• publication eligibility;
• evidence of permission where required.

8.5. Viroway-Authored Documents

Viroway-authored documents SHALL include:

rights:
  copyright_notice: "© 2026 Viroway Ltd. All rights reserved."
  copyright_holder:
    organisation_id: org.viroway
    name: Viroway Ltd
  permission_basis: copyright_owner
  source_rights_url: https://ecoworld.ai/legal/copyright

The exact legal URL SHALL be replaced by the approved Viroway legal page.

8.6. Joint and Third-Party Authorship

Joint works SHALL identify:

• each copyright holder;
• contribution scope;
• agreement;
• publication rights;
• modification rights;
• derivative-work rights;
• termination;
• attribution.

8.7. Open Licences

Open-licence metadata SHALL identify:

• SPDX-compatible licence identifier where available;
• licence version;
• licence URL;
• attribution;
• share-alike;
• non-commercial restriction;
• no-derivatives restriction;
• database rights;
• patent terms where relevant.

8.8. Standards and Restricted Publications

Restricted standards SHALL identify:

• purchased or licensed copy;
• licence holder;
• permitted users;
• reproduction restrictions;
• paraphrase permissions;
• quotation limits;
• public-rendering prohibition;
• machine-processing rights;
• retention and deletion terms.

8.9. Rights Status

Rights status MAY include:

• verified;
• verified with conditions;
• pending legal review;
• restricted internal use;
• public publication prohibited;
• transformation prohibited;
• expired;
• revoked;
• disputed;
• unknown;
• quarantined.

8.10. Processing Rights

Machine-processing permission SHALL be decomposed rather than represented as one broad boolean.

rights:
  processing_rights:
    parsing:
      state: permitted
    ocr:
      state: permitted
    internal_summary:
      state: permitted
    structured_extraction:
      state: permitted
    semantic_indexing:
      state: permitted
    embeddings:
      state: permitted_with_conditions
    vector_storage:
      state: permitted_with_conditions
    retrieval_augmented_generation:
      state: restricted
      scope: internal_only
    model_evaluation:
      state: prohibited
    fine_tuning:
      state: prohibited
    foundation_model_training:
      state: prohibited
    public_generation:
      state: restricted
    derivative_dataset_creation:
      state: prohibited

8.11. Fragment-Level Rights

Rights MAY be overridden at:

• Knowledge Document;
• Knowledge Section;
• Source Fragment;
• Citation Object;
• media object;
• Knowledge Assertion.

rights_overrides:
  - target_id: PP-SF-000114
    content_type: diagram
    publication_permission:
      state: prohibited
    structured_extraction:
      state: permitted
    attribution_required: true

A narrower fragment-level restriction SHALL prevail over a broader document-level permission.

8.12. Rights Inheritance

Rights SHALL default to the most restrictive applicable rule where:

• a source-level rule;
• document-level rule;
• section-level rule;
• fragment-level rule;
• agreement-level rule

conflict or overlap.

8.13. Rights Gate

A Rights Gate SHALL prevent:

• public rendering where not permitted;
• redistribution where prohibited;
• model training where prohibited;
• automated extraction where prohibited;
• publication of copied text beyond permission;
• generation of public datasets from restricted sources;
• continued use after licence expiration.

---

9. Authority Metadata

Authority SHALL be represented as separate dimensions.

authority:
  source_authority:
    class: manufacturer_authoritative
    scope:
      - device_specification

  legal_authority:
    class: non_binding
    jurisdictions: []

  evidentiary_authority:
    class: authoritative_for_source_content
    permitted_claims:
      - supported_protocol
      - measurement_range

  zayaz_governance_authority:
    class: non_authoritative_source

  runtime_authority:
    class: none

9.1. Source Authority

Source Authority identifies the authority of a source within its own domain.

Classes MAY include:

• legislature;
• regulator;
• court;
• standards body;
• accreditation body;
• certification body;
• manufacturer;
• product owner;
• methodology owner;
• dataset authority;
• Viroway constitutional authority;
• Viroway operational authority;
• scientific authority;
• industry association;
• informational publisher;
• unknown.

9.2. Legal Authority

Legal Authority identifies binding effect by jurisdiction, subject, role and time.

States MAY include:

• legally binding;
• regulator binding;
• judicially binding;
• contractual;
• conditionally binding;
• non-binding guidance;
• informative;
• unresolved.

9.3. Evidentiary Authority

Evidentiary Authority identifies which claims a source can support and under which limitations.

9.4. ZAYAZ Governance Authority

Classes MAY include:

• constitutional authority;
• Core authoritative;
• approved Extension authority;
• approved operational authority;
• approved Publication authority;
• governed reference;
• proposed knowledge;
• derived intelligence;
• non-authoritative source;
• rejected;
• quarantined.

9.5. Runtime Authority

Runtime Authority SHALL be absent unless the knowledge has passed all required applicability, rights, semantic, impact, Change Decision, compilation, Runtime Admission and activation Gates.

9.6. Authority Non-Transitivity

An external authoritative source SHALL NOT automatically become:

• Core;
• tenant policy;
• Runtime rule;
• certification criterion;
• Publication claim;
• Registry entry.

9.7. Authority Receipt

A material object SHOULD expose a receipt containing all authority dimensions, scope, validity, Decision and provenance.

---

10. Transformation Metadata

Transformation metadata SHALL record how the MDX representation was produced.

transformation:
  transformation_id: PP-TRN-00000421
  representation_type: structured_extraction
  generated_by:
    actor_type: agent
    actor_id: document-normalisation-agent
    model_id: model.example
    model_version: 1.0
  extraction_profile: pp-extraction-profile-v1
  parser_version: 1.3.0
  ocr_used: false
  translation:
    performed: false
  source_coverage:
    status: complete
    pages: "1-84"
    tables: complete
    figures: partial
  known_omissions:
    - decorative imagery
  confidence: high

10.1. Representation Types

Types MAY include:

• verbatim transcription;
• structured transcription;
• structured extraction;
• normalised representation;
• paraphrase;
• summary;
• translation;
• interpreted guidance;
• composite synthesis;
• machine-generated draft;
• human-authored source;
• human-reviewed extraction.

10.2. AI Provenance

AI-generated or AI-assisted documents SHALL identify:

• model;
• model version;
• provider;
• Agent Profile;
• prompt or instruction profile;
• retrieval sources;
• tool calls where material;
• generation time;
• confidence;
• reviewer;
• unresolved uncertainty.

10.3. OCR Provenance

Where OCR is used, metadata SHALL identify:

• OCR engine;
• version;
• language;
• pages;
• confidence;
• manual corrections;
• unresolved regions.

10.4. Translation Provenance

Translation SHALL identify:

• source language;
• target language;
• translator or model;
• version;
• review;
• legal status;
• ambiguity;
• whether the source text remains controlling.

---

11. Temporal Metadata

Every Knowledge Document SHALL preserve bitemporal metadata.

temporal:
  source_published_at: 2023-12-18
  source_effective_from: 2023-12-18
  source_effective_to: null
  captured_at: 2026-08-04T08:00:00Z
  transformed_at: 2026-08-04T09:00:00Z
  reviewed_at: 2026-08-07T10:00:00Z
  valid_from: 2026-08-10T00:00:00Z
  valid_to: null
  transaction_time: 2026-08-10T12:05:00Z
  next_review_at: 2026-11-10

Temporal fields SHOULD include:

• source publication time;
• source effective time;
• source withdrawal time;
• capture time;
• transformation time;
• review time;
• approval time;
• internal valid time;
• transaction time;
• next review time;
• supersession time;
• archive time.

---

11A. Independent Version Lines

Version fields SHALL identify which object or projection they govern.

versions:
  source_version: "2023"
  source_capture_version: 1
  knowledge_document_version: 0.2.0
  assertion_set_version: 0.1.0
  entity_profile_version: 0.3.0
  mapping_version: 0.1.0
  projection_version: null
  activation_version: null

Independent version lines SHALL NOT be collapsed into one generic version field.

A change in one version line SHALL trigger impact analysis only for dependent objects.

---

12. Applicability Metadata

Applicability SHALL be explicit and machine-readable.

applicability:
  domains:
    - ai-governance
    - certification
  jurisdictions:
    - international
  organisation_roles:
    - ai-provider
    - ai-deployer
  products:
    - zayaz
  modules:
    - constitutional-governance
    - artificial-intelligence-governance
  components:
    - requirement-registry
    - evidence-registry
    - certification-engine
  tenant_scope: global
  white_label_scope: global

12.1. 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.

12.2. Applicability States

States MAY include:

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

---

13. Knowledge Classification Metadata

knowledge:
  knowledge_classes:
    - requirement
    - control
    - definition
    - evidence_expectation
    - lifecycle_rule
  extraction_status: reviewed
  assertion_count: 428
  unresolved_assertion_count: 17

Knowledge classes MAY include:

• definition;
• requirement;
• prohibition;
• recommendation;
• permission;
• control;
• criterion;
• method;
• formula;
• unit;
• datatype;
• code;
• enumeration;
• threshold;
• relationship;
• inheritance rule;
• lifecycle rule;
• compatibility rule;
• evidence requirement;
• reporting requirement;
• maintenance requirement;
• safety requirement;
• calibration rule;
• device specification;
• protocol definition;
• API contract;
• certification state;
• legal interpretation;
• implementation guidance.

---

14. Origin and IoT Metadata Profile

The uploaded origin-model example demonstrates a high-value use case and SHALL be supported through a dedicated profile.

origin_profile:
  artifact_type: origin_model_profile
  origin_class_id: origin.water_meter.smart.ultrasonic
  manufacturer_id: manufacturer.kamstrup
  product_family_id: family.kamstrup.flowiq
  model_id: model.kamstrup.flowiq2200

  inherits_from:
    - origin.physical_device
    - origin.meter
    - origin.water_meter
    - origin.water_meter.smart
    - origin.water_meter.ultrasonic

  advertises_capabilities:
    - capability.measure.water.cumulative_volume
    - capability.measure.water.flow_rate
    - capability.detect.water.leakage
    - capability.measure.water.temperature
    - capability.telemetry.remote_reading

  produces_signal_types:
    - uso_type:water.iot.measurement.volume.cumulative@v1
    - uso_type:water.iot.measurement.flow.instantaneous@v1
    - uso_type:water.iot.event.leakage.detected@v1

  protocols:
    - wmbus
    - lorawan

  supported_units:
    - m3
    - l
    - m3_per_h

14.1. Origin Profile Requirements

An origin profile SHOULD include:

• origin class;
• manufacturer;
• product family;
• model;
• version;
• firmware applicability;
• inheritance;
• capabilities;
• signal types;
• protocols;
• units;
• measurement range;
• accuracy;
• calibration;
• certifications;
• installation constraints;
• environmental limits;
• parser or connector references;
• source artefacts;
• evidence status;
• confidence.

14.2. Runtime Separation

Origin knowledge SHALL NOT contain:

• tenant credentials;
• device serial numbers;
• facility assignments;
• network secrets;
• live telemetry;
• customer-specific maintenance history.

14.3. Inheritance Modes

Every inheritable property SHALL define one of:

• inherit;
• append;
• replace;
• restrict;
• prohibit_override;
• conditional;
• derived;
• tenant_configurable.

14.4. Lineage

Every effective inherited property SHALL preserve:

• source ancestor;
• declared value;
• inheritance rule;
• override;
• effective value;
• validation;
• provenance.

---

15. Framework, Standard and Regulation Metadata Profile

Framework and regulatory documents SHALL support:

• issuing authority;
• legal or normative status;
• version;
• jurisdiction;
• effective dates;
• amendment history;
• clause or article identifiers;
• definitions;
• requirements;
• applicability;
• controls;
• evidence expectations;
• reporting obligations;
• certification relevance;
• surveillance relevance;
• lifecycle;
• official source;
• copyright and licence.

Example:

framework_profile:
  framework_id: framework.iso.iec.42001
  framework_type: management_system_standard
  version: "2023"
  issuing_authority: ISO/IEC
  jurisdiction:
    - international
  certification_eligible: true
  crosswalk_targets:
    - zayaz.cccf
    - zayaz.ai-governance

---

15A. Metadata Profiles and Extension Model

Domain Profiles extend the base PP-KDMS contract.

metadata_profile:
  base_specification:
    id: PP-KDMS
    version: 0.2.0

  profiles:
    - profile_id: PP-PROFILE-IOT-ORIGIN
      version: 0.1.0
    - profile_id: PP-PROFILE-RIGHTS-RESTRICTED
      version: 0.1.0

15A.1. Permitted Profile Behaviour

A Profile MAY:

• add fields;
• tighten required fields;
• restrict enumerations;
• add validation rules;
• add domain relationships;
• add conformance Gates;
• add inheritance rules.

15A.2. Prohibited Profile Behaviour

A Profile SHALL NOT:

• weaken mandatory base fields;
• remove rights requirements;
• remove provenance;
• remove stable identity;
• broaden authority automatically;
• bypass tenant isolation;
• permit silent activation.

15A.3. Property-Specific Inheritance

Profiles SHALL support:

• inherit;
• append;
• replace;
• restrict;
• prohibit_override;
• conditional;
• derived;
• tenant_configurable.

inheritance:
  default_mode: inherit
  field_rules:
    capabilities: append
    prohibited_capabilities: restrict
    manufacturer_id: prohibit_override
    supported_units: append
    firmware_range: replace
    tenant_configuration: tenant_configurable

Every effective inherited value SHALL preserve:

• source ancestor;
• declared value;
• inheritance mode;
• override;
• effective value;
• validator;
• provenance.

---

16. Section-Level Metadata

Document frontmatter alone is insufficient.

Every materially addressable section SHOULD use a governed component.

<KnowledgeSection
  sectionId="PP-KS-000431"
  sourceLocator="clause-6.1"
  knowledgeClass="requirement-group"
  normativeStatus="normative"
  confidence="high"
  reviewStatus="approved"
  rightsRecordId="PP-RGT-00000918"
>

Section metadata SHOULD include:

• section identity;
• source locator;
• source page;
• source clause;
• knowledge class;
• normative status;
• applicability;
• confidence;
• review status;
• rights reference;
• assertion count;
• extraction status.

---

16A. Source Fragment Metadata

Every exact evidence locator SHOULD be represented as a SourceFragment.

source_fragment:
  fragment_id: PP-SF-000001
  source_id: PP-SRC-000001
  capture_id: PP-CAP-000001
  locator:
    type: clause
    value: "6.1.2"
  content_class: normative_text
  digest: sha256:...
  rights_record_id: PP-RGT-000001
  valid_from: 2026-08-04

Fragment locator types MAY include:

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

---

17. Assertion-Level Metadata

Every machine-actionable statement SHALL be represented as a KnowledgeAssertion.

<KnowledgeAssertion
  assertionId="PP-KA-004812"
  sourceLocator="clause-6.1.2"
  assertionType="requirement"
  normativeForce="shall"
  subjectType="organisation"
  sourceAuthority="external_normative"
  zayazAuthority="non_authoritative_source"
  extractionStatus="human_reviewed"
  rightsRecordId="PP-RGT-00000918"
  candidateTargets={[
    "requirement-registry",
    "control-objective-registry"
  ]}
>
The organisation is required to ...
</KnowledgeAssertion>

17.1. Required Assertion Fields

A machine-actionable assertion SHALL possess:

• assertion identity;
• source locator;
• assertion type;
• subject;
• predicate;
• object or statement;
• authority;
• normative force where relevant;
• applicability;
• confidence;
• extraction status;
• rights reference;
• reviewer;
• provenance.

17.2. Assertion Status

Status MAY include:

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

---

18. Evidence References and Citation Metadata

Every material citation SHALL be machine-addressable.

citations:
  - citation_id: PP-CIT-000019
    source_id: PP-SRC-00004567
    source_url: https://example.invalid/official-source
    source_locator: clause-6.1.2
    quoted: false
    transformed: true
    transformation_type: paraphrase
    rights_record_id: PP-RGT-00000918
    publication_permission: permitted_with_attribution
    attribution_text: "Source: ISO/IEC 42001:2023"

18.1. Citation Requirements

A citation SHALL identify:

• source;
• URL or controlled source reference;
• exact locator;
• quoted or paraphrased state;
• transformation;
• copyright holder;
• licence;
• publication permission;
• attribution;
• access date where relevant;
• evidence of right where required.

18.2. Data Citations

Data-derived citations SHALL additionally identify:

• dataset;
• version;
• record range;
• extraction query;
• licence;
• transformation;
• aggregation;
• publication right.

---

18A. Knowledge Entity Metadata

A KnowledgeEntity SHALL possess identity independent of every document describing it.

knowledge_entity:
  entity_id: PP-KE-000001
  semantic_id: pp.entity.device.water-meter.model.example
  entity_type: device_model
  canonical_name: Example Water Meter
  described_by:
    - PP-KD-000001
    - PP-KD-000002
  lifecycle: active
  provenance_graph_id: PP-PROV-000001

18B. Knowledge Bundle Metadata

A KnowledgeBundle groups related objects for a defined purpose.

knowledge_bundle:
  bundle_id: PP-KB-000001
  bundle_type: device_model_bundle
  purpose: governed_device_profile
  members:
    - PP-SRC-000001
    - PP-KD-000001
    - PP-KE-000001
  preserve_member_rights: true
  preserve_member_authority: true

---

19. Extraction Targets

A Knowledge Document MAY declare candidate machine-readable projections.

extraction_targets:
  - target_type: requirement_registry
    candidate_count: 71
  - target_type: control_registry
    candidate_count: 38
  - target_type: evidence_requirement_registry
    candidate_count: 44
  - target_type: origin_registry
    candidate_count: 1

Target types MAY include:

• Requirement Registry;
• Control Registry;
• Evidence Requirement Registry;
• Origin Registry;
• Manufacturer Registry;
• Product Family Registry;
• Device Model Registry;
• Capability Registry;
• Signal Type Registry;
• Unit Registry;
• Datatype Registry;
• Value Provider;
• Relationship Type Registry;
• JSON Schema;
• validation rule;
• policy rule;
• workflow trigger;
• Test Specification;
• Test Fixture;
• connector manifest;
• parser manifest;
• framework crosswalk;
• certification crosswalk;
• Publication profile.

---

20. Change Intelligence Metadata

change_intelligence:
  prior_source_version: PP-SRC-00004102
  prior_document_version: PP-KD-00001234@0.9.0
  change_detected: true
  change_class:
    - normative_change
    - evidence_requirement_change
  affected_objects:
    - AIMS-REQ-0042
    - AIMS-CTRL-0018
  generated_change_candidates:
    - PP-CC-00001091
  activation_status: pending_review

20.1. Change Classes

Classes MAY include:

• editorial;
• metadata;
• identity;
• normative;
• legal;
• technical;
• schema;
• Registry;
• capability;
• datatype;
• unit;
• protocol;
• compatibility;
• evidence;
• certification;
• lifecycle;
• rights;
• security;
• tenant-impacting;
• Publication-impacting.

20.2. Impact Dimensions

Impact SHALL identify as applicable:

• Core;
• Extension;
• Runtime;
• Registry;
• schema;
• JSON;
• policy;
• computation;
• workflow;
• test;
• tenant;
• white-label operator;
• Module;
• Component;
• Publication;
• certification;
• historical records.

---

21. Change Candidate Metadata

A ChangeCandidate SHALL be separate from the source Knowledge Document.

change_candidate:
  candidate_id: PP-CC-00001091
  source_document: PP-KD-00001234
  source_assertions:
    - PP-KA-004812
  target_type: requirement_registry
  target_id: AIMS-REQ-0042
  change_type: modify
  proposed_value: {}
  authority_required:
    - framework-owner
    - constitutional-review
  hecate_status: pending
  decision_status: proposed

21.1. Candidate Lifecycle

Lifecycle MAY include:

• proposed;
• validation pending;
• validated;
• impact review;
• legal review;
• rights review;
• approved;
• approved with conditions;
• rejected;
• deferred;
• compiled;
• activated;
• rolled back;
• superseded.

21.2. Prohibition

Pergamum Pulse SHALL NOT silently activate a Change Candidate.

---

21A. Change Decision Metadata

A ChangeDecision SHALL remain separate from the Change Candidate.

change_decision:
  decision_id: PP-CD-000001
  candidate_id: PP-CC-000001
  decision: approved_with_conditions
  authority:
    - registry-owner
  conditions:
    - activate_after_runtime_validation
  effective_from: 2026-08-10
  signatures: []
  provenance_graph_id: PP-PROV-000002

Decision states MAY include:

• approved;
• approved with conditions;
• rejected;
• deferred;
• returned for revision;
• escalated;
• expired;
• superseded.

---

22. Projection Manifest

Generated runtime artefacts SHALL use a Projection Manifest.

projection_manifest:
  projection_id: PP-PRJ-00000123
  source_documents:
    - PP-KD-00001234
  source_assertions:
    - PP-KA-004812
  approved_change_candidates:
    - PP-CC-00001091
  generated_outputs:
    - path: registries/requirements.json
      digest: sha256:...
    - path: schemas/requirements.schema.json
      digest: sha256:...
  compiler_version: 1.0.0
  generated_at: 2026-08-10T12:00:00Z
  activation_status: not_activated

Projection and activation SHALL be represented separately.

projection:
  eligible: true
  generated: true
  projection_manifest_id: PP-PRJ-000001
  validation_status: passed

activation:
  eligible: false
  status: not_requested
  authority_required:
    - registry-owner
    - runtime-admission-authority

A generated output SHALL NOT be interpreted as active.

Every projection SHALL preserve:

• source documents;
• source assertions;
• Change Decisions;
• compiler version;
• output paths;
• output digests;
• validation;
• activation state;
• tenant and white-label scope;
• Module and Component lineage.

---

23. Security and Access Metadata

security:
  classification: restricted
  tenant_scope: global
  white_label_scope: global
  access_roles:
    - knowledge-reviewer
    - legal-reviewer
  public_rendering: prohibited
  export_control: none
  personal_data: false
  trade_secret: false

Classification MAY include:

• public;
• internal;
• confidential;
• restricted;
• tenant confidential;
• white-label confidential;
• security sensitive;
• legal privilege;
• regulator restricted;
• personal data;
• trade secret;
• copyright restricted.

---

24. Tenant and White-Label Metadata

Shared knowledge SHALL preserve separation among:

• global canonical knowledge;
• regional or community enrichment;
• white-label knowledge;
• tenant knowledge;
• organisation knowledge;
• installation-specific knowledge.

scope:
  knowledge_layer: global_canonical
  tenant_scope: none
  white_label_scope: none
  promotion_eligible: true

Tenant-derived knowledge SHALL NOT be promoted automatically.

Promotion SHALL require:

• anonymisation;
• rights confirmation;
• evidence attachment;
• conflict analysis;
• review;
• approval;
• provenance.

---

25. Review and Approval Metadata

review:
  technical_review:
    status: approved
    reviewer: actor.technical-reviewer
    reviewed_at: 2026-08-07T10:00:00Z
  legal_review:
    status: approved_with_conditions
    reviewer: actor.legal-reviewer
    conditions:
      - public rendering prohibited
  rights_review:
    status: approved

Review classes MAY include:

• source authenticity;
• technical;
• semantic;
• legal;
• rights;
• security;
• privacy;
• tenant isolation;
• framework;
• methodology;
• certification;
• Publication.

---

26. Provenance Metadata

Every Knowledge Document SHALL preserve provenance.

provenance:
  provenance_graph_id: PP-PROV-00009124
  created_by: actor.document-normalisation-agent
  created_at: 2026-08-04T09:00:00Z
  reviewed_by:
    - actor.technical-reviewer
    - actor.legal-reviewer
  source_objects:
    - PP-SRC-00004567
  source_captures:
    - PP-CAP-00007891
  rights_records:
    - PP-RGT-00000918
  predecessor_documents: []
  successor_documents: []

Provenance SHALL connect:

• SourceObject;
• SourceCapture;
• RightsRecord;
• KnowledgeDocument;
• section;
• assertion;
• citation;
• reviewer;
• Change Candidate;
• Change Decision;
• Projection Manifest;
• generated output;
• activation;
• Publication;
• archive.

---

27. Validation Requirements

HECATE SHALL validate at least:

• stable identity;
• semantic identity;
• version;
• lifecycle;
• source identity;
• source authority;
• capture integrity;
• digest;
• copyright holder;
• licence;
• rights evidence;
• publication permission;
• machine-processing permission;
• transformation profile;
• temporal validity;
• applicability;
• assertion identity;
• source locator;
• extraction target;
• Change Candidate;
• Projection Manifest;
• tenant scope;
• Module lineage;
• Component lineage;
• provenance completeness.

HECATE SHALL NOT:

• infer publication rights from source availability;
• infer machine-processing rights from public access;
• infer copyright ownership from authorship alone;
• convert external authority into Core authority;
• approve legal interpretations;
• waive rights restrictions;
• activate Change Candidates automatically.

---

28. Required Frontmatter Example — Viroway-Authored Document

---
id: PP-KD-00002001
semantic_id: pp.knowledge.viroway.zayaz.example
canonical_name: Example Viroway Knowledge Document
title: Example Viroway Knowledge Document
document_type: viroway_standard
status: draft
version: 0.2.0
language: en

metadata_contract:
  specification:
    id: PP-KDMS
    version: 0.2.0
  profiles: []
  conformance_target: governed

owner:
  - architecture@viroway.com

source:
  source_id: PP-SRC-00002001
  source_type: internal_viroway_source
  publisher: Viroway Ltd
  issuing_authority: Viroway Architecture
  title: Example Viroway Knowledge Document
  source_version: 0.1.0
  official_url: https://github.com/viroway-ltd/zayaz-docs
  authority_class: viroway_operational_authority

capture:
  capture_id: PP-CAP-00002001
  captured_at: 2026-08-04T09:00:00Z
  captured_by:
    actor_type: human
    actor_id: architecture-owner
  acquisition_method: repository_authored
  media_type: text/mdx
  source_digest: sha256:...

rights:
  rights_record_id: PP-RGT-00002001
  copyright_notice: "© 2026 Viroway Ltd. All rights reserved."
  copyright_holder:
    organisation_id: org.viroway
    name: Viroway Ltd
  copyright_year:
    - 2026
  licence_id: all-rights-reserved
  licence_name: All Rights Reserved
  source_rights_url: https://ecoworld.ai/legal/copyright
  legal_terms_url: https://ecoworld.ai/legal/terms
  permission_basis: copyright_owner
  publication_permission: permitted
  modification_permission: permitted
  redistribution_permission: restricted
  commercial_use_permission: permitted
  machine_processing_permission: permitted
  training_use_permission: restricted
  attribution_required: true
  attribution_text: "© 2026 Viroway Ltd"

authority:
  source_authority: viroway_operational_authority
  zayaz_authority: proposed_knowledge
  constitutional_status: unratified
  permitted_uses:
    - analysis
    - review
  prohibited_uses:
    - direct_runtime_activation

transformation:
  representation_type: human_authored_source
  source_coverage:
    status: complete
  confidence: high

temporal:
  source_published_at: null
  source_effective_from: null
  captured_at: 2026-08-04T09:00:00Z
  valid_from: null
  next_review_at: 2026-11-04

applicability:
  domains:
    - knowledge-governance
  modules:
    - pergamum-pulse
  components:
    - knowledge-document-registry
  tenant_scope: global
  white_label_scope: global

knowledge:
  knowledge_classes:
    - implementation_guidance
  extraction_status: authored
  assertion_count: 0
  unresolved_assertion_count: 0

change_intelligence:
  change_status: initial_authorship
  generated_change_candidates: []

provenance:
  provenance_graph_id: PP-PROV-00002001
  created_by: actor.architecture-owner
  created_at: 2026-08-04T09:00:00Z
---

---

29. Required Frontmatter Example — External Restricted Standard

---
id: PP-KD-00003001
semantic_id: pp.knowledge.framework.iso-iec-42001.2023
canonical_name: ISO IEC 42001 2023 Knowledge Representation
title: ISO IEC 42001 2023 Knowledge Representation
document_type: standard
status: review_pending
version: 0.1.0
language: en

source:
  source_id: PP-SRC-00003001
  source_type: licensed_publication
  publisher: ISO/IEC
  issuing_authority: ISO/IEC
  title: ISO/IEC 42001:2023
  edition: 1
  publication_date: 2023-12
  official_url: https://www.iso.org/
  controlled_copy_location: restricted://standards/iso-iec-42001-2023
  authority_class: standards_body
  source_digest: sha256:...

rights:
  rights_record_id: PP-RGT-00003001
  copyright_notice: "Copyright ISO/IEC"
  copyright_holder:
    name: ISO/IEC
  licence_id: licensed-restricted-standard
  source_rights_url: https://www.iso.org/copyright.html
  permission_basis: standards_licence
  publication_permission: metadata_and_permitted_paraphrase_only
  modification_permission: prohibited_for_source_text
  redistribution_permission: prohibited
  machine_processing_permission: subject_to_licence
  training_use_permission: prohibited_unless_agreed
  attribution_required: true
  rights_evidence:
    - evidence_id: PP-RGT-EV-00003001
      evidence_type: purchase_or_licence_record
      evidence_url: restricted://legal/licences/iso-42001

authority:
  source_authority: external_normative
  zayaz_authority: non_authoritative_source
  normative_status: normative
  constitutional_status: unratified
  permitted_uses:
    - internal_mapping
    - evidence_planning
    - change_detection
  prohibited_uses:
    - reproduce_full_source_publicly
    - silent_core_update
    - direct_runtime_activation

transformation:
  representation_type: structured_paraphrase
  generated_by:
    actor_type: agent
    actor_id: standards-normalisation-agent
  reviewed_by: []
  source_coverage:
    status: pending_review
  confidence: medium

applicability:
  domains:
    - ai-governance
    - certification
  modules:
    - constitutional-governance
    - pergamum-pulse
  components:
    - requirement-registry
    - certification-engine

knowledge:
  knowledge_classes:
    - requirement
    - control
    - evidence_requirement
    - lifecycle_rule
  extraction_status: pending_review

change_intelligence:
  change_status: initial_ingestion
  generated_change_candidates: []

provenance:
  provenance_graph_id: PP-PROV-00003001
---

---

29A. Conformance Receipt

A document MAY receive a machine-verifiable conformance receipt.

conformance:
  specification:
    id: PP-KDMS
    version: 0.2.0
  level: governed
  hecate_validation:
    receipt_id: HECATE-RCPT-000001
    status: passed
    validated_at: 2026-08-04T10:00:00Z
  unresolved_findings: []

29B. Migration from PP-KDMS v0.1

Version 0.2 SHALL remain historically immutable.

Migration to v0.2 SHALL produce a migration receipt containing:

• source document identity;
• source specification version;
• target specification version;
• migration-rule version;
• migrated fields;
• newly created object identities;
• unresolved fields;
• rights changes;
• authority changes;
• validation;
• reviewer;
• provenance.

29B.1. Field Migration Map

v0.1 field	v0.2 treatment
source	Becomes or references a SourceObject
capture	Becomes or references a SourceCapture
rights	Becomes or references a RightsRecord
authority	Splits into five authority dimensions
knowledge	Separates Document, Assertion and Entity metadata
change_intelligence	Separates detected change, Candidate and Decision
provenance	Expands into object-level provenance graph
origin_profile	Moves to a domain Profile extension
extraction_targets	Links to Change Candidates and Projection Manifests
generic version	Expands into independent version lines

29B.2. Migration Non-Destruction

Migration SHALL NOT:

• overwrite v0.1 historical state;
• invent unknown rights;
• infer authority;
• infer publication permission;
• activate generated outputs;
• discard unresolved fields.

---

30. Conformance Requirements

A Pergamum Pulse Knowledge Document conforms to this specification where it:

1. possesses stable identity and semantic identity;
2. identifies its source and issuing authority;
3. preserves source version or edition;
4. preserves source URL or controlled source location;
5. preserves source digest where source bytes are held;
6. records capture time and acquisition method;
7. records copyright holder for every document;
8. records copyright information for Viroway-authored documents;
9. records licence or permission basis;
10. links to online legal terms or controlled agreement evidence;
11. records publication, redistribution, modification and machine-processing permissions;
12. records attribution requirements;
13. prevents publication where rights are unresolved or prohibited;
14. records whether content is quoted, paraphrased, transformed or synthesised;
15. records AI, parser, OCR and translation provenance where used;
16. distinguishes source authority from ZAYAZ authority;
17. prevents external source authority from becoming Core authority automatically;
18. preserves temporal validity and transaction time;
19. preserves applicability by jurisdiction, domain, tenant, Module, Component and Extension where relevant;
20. classifies knowledge into machine-readable classes;
21. supports section-level metadata;
22. supports assertion-level metadata;
23. connects every material assertion to exact source evidence;
24. connects every citation to source and rights evidence;
25. supports origin, device, manufacturer, family, model, capability, protocol and signal metadata;
26. keeps global canonical knowledge separate from tenant installation state;
27. defines property inheritance semantics;
28. preserves effective-property lineage;
29. declares candidate extraction targets;
30. creates Change Candidates rather than silently updating governed outputs;
31. validates Change Candidates through HECATE;
32. records approval and activation separately;
33. records Projection Manifests for generated JSON, schemas, Registries and other outputs;
34. preserves tenant and white-label isolation;
35. preserves Module and Component lineage;
36. preserves complete provenance;
37. supports historical reconstruction;
38. prevents public claims from exceeding source rights, evidence or authority;
39. distinguishes Source Series, Source Objects and Source Captures;
40. distinguishes Knowledge Documents from Knowledge Entities;
41. preserves Source Fragments as exact evidence locators;
42. preserves Knowledge Bundles without merging member authority or rights;
43. represents mappings as typed, scoped and versioned objects;
44. separates Change Candidates from Change Decisions;
45. separates generated projections from activation;
46. uses independent source, capture, document, assertion, entity, mapping, projection and activation version lines;
47. represents source, legal, evidentiary, ZAYAZ governance and Runtime authority separately;
48. supports Profile extensions without permitting them to weaken the base contract;
49. supports property-specific inheritance and effective-value lineage;
50. supports fragment-level rights and most-restrictive rights precedence;
51. distinguishes parsing, OCR, extraction, embedding, retrieval, evaluation, fine-tuning and training permissions;
52. preserves explicit unknown, unresolved, prohibited and not-evaluated semantics;
53. provides v0.1-to-v0.2 migration receipts;
54. supports machine-verifiable conformance receipts.

---

31. Foundational Principle

Pergamum Pulse knowledge is valuable only where its identity, authority, rights, meaning, scope, transformation and lineage remain explicit.

Every Knowledge Document SHALL identify what the source is, who owns it, who issued it, which version applies, how it was acquired, what rights Viroway has to process and publish it, how it was transformed, what assertions were extracted, which ZAYAZ objects may be affected, and which authority must approve any resulting change.

Public availability SHALL not be interpreted as unrestricted copyright permission. Authorship SHALL not be interpreted as ownership without evidence. Machine readability SHALL not be interpreted as authority. Extraction SHALL not be interpreted as adoption. A generated JSON file SHALL not be interpreted as activated constitutional or Runtime state.

By making copyright, licence, source links, rights evidence, provenance, applicability, inheritance, assertions, Change Candidates and generated projections first-class objects, Pergamum Pulse can become a compounding global knowledge asset without sacrificing legal integrity, constitutional authority, tenant isolation or historical trust.

---