Pergamum Pulse Metadata Profile Specification
Version 0.1 — Governed Metadata Profile Contract
1. Purpose
This specification defines the dedicated metadata profile for Pergamum Pulse.
The profile exists to make Pergamum Pulse knowledge objects, processing artefacts and governed documentation self-describing without duplicating the normative semantics owned by subordinate specifications and registries.
The profile SHALL allow a consumer to determine:
- what the represented object or document is;
- which metadata contract governs it;
- which object class and prefix apply;
- which source and capture support it;
- which Rights Record governs its permitted use;
- which authority dimensions apply;
- which lifecycle state applies;
- which transformations produced it;
- when it is valid and when it was recorded;
- where it applies;
- what knowledge it contains or represents;
- which assertions, fragments and entities participate;
- what changes were detected;
- what retrieval and AI-processing eligibility applies;
- what reviews and Decisions exist;
- how complete provenance is preserved;
- which HECATE conformance results apply.
The governing principle is:
Pergamum Pulse metadata SHALL reference normative authorities and registries. It SHALL NOT create parallel vocabularies merely for serialization convenience.
2. Normative Authority Map
The following ownership rules are normative.
| Concern | Normative authority | Profile responsibility |
|---|---|---|
| Knowledge-document metadata envelope | PP-KDMS | Serialize and reference |
| Universal object semantics | PP-KORS | Resolve object contract |
| Universal lifecycle | PP-KORS | Reference lifecycle state/profile |
| Object prefix ownership | Pergamum Pulse Object & Prefix Register under PP-SRAG | Resolve prefix and owner |
| Rights and licensing | PP-RLCPS | Reference/project canonical Rights Record |
| Knowledge Assertions | PP-KAS | Reference assertion objects/state dimensions |
| Semantic mappings/crosswalks | PP-SMCS | Reference mapping objects |
| Change Candidates and projections | PP-CCPS | Reference change/projection objects |
| Retrieval, embeddings and AI processing | PP-REAPP | Reference eligibility and processing records |
| HECATE conformance | PP-HKCP | Reference validation profiles/findings/receipts |
| Schema and registry architecture | PP-SRAG | Resolve schema/registry artefacts |
| Corpus membership | PP-DREG | Resolve canonical document membership |
Where this profile conflicts with a normative authority listed above, the authority-owning specification SHALL prevail.
3. Relationship to the Constitutional Metadata Standard
The Constitutional Metadata Standard defines the universal Constitutional Header.
Pergamum Pulse metadata is a specialised profile layered on that universal header.
The profile SHALL NOT redefine universal CMS identity, classification, governance, publication or relationship semantics.
For a general ZAYAZ documentation asset, Pergamum Pulse-specific metadata SHOULD be represented through the namespaced extension:
pergamum_pulse:
...
For a Knowledge Document governed directly by PP-KDMS, the existing KDMS top-level knowledge metadata contract MAY remain in its governed serialization during migration.
VW-DL SHALL distinguish:
- universal CMS Constitutional Header validation;
- Pergamum Pulse profile validation;
- Pergamum Pulse corpus-integrity validation.
4. Metadata Contract Resolver
Every Pergamum Pulse Knowledge Document SHOULD declare:
metadata_contract:
specification:
id: PP-KDMS
version: 0.2.0
profiles:
- PP-MPS@0.1.0
conformance_target: governed
metadata_contract is the deterministic entry point for metadata validation.
A validator SHALL:
- resolve
specification.id; - resolve the exact specification version;
- resolve each declared profile;
- resolve profile schemas and registries through
PP-SRAG; - execute applicable deterministic validation;
- produce structured findings;
- preserve the validation context and versions used.
A profile SHALL NOT silently alter the base specification.
5. Pergamum Pulse Extension Model
For CMS-governed architecture documents, the canonical extension shape is:
pergamum_pulse:
object: {}
source: {}
capture: {}
rights: {}
authority: {}
transformation: {}
temporal: {}
applicability: {}
knowledge: {}
assertions: {}
fragments: {}
entities: {}
change_intelligence: {}
projection: {}
retrieval: {}
review: {}
provenance: {}
conformance: {}
Not every section is required for every asset.
Requirements SHALL be selected by:
metadata_contract;- document type;
- object type;
- declared PP profile;
- lifecycle state;
- intended processing operation;
- authority and rights conditions.
6. Object Identity
6.1. Canonical Shape
pergamum_pulse:
object:
id: PP-KD-000001
object_type: knowledge_document
prefix: PP-KD-
semantic_id: pp.knowledge.example
version: 1.0.0
lifecycle_status: draft
lifecycle_profile: pp-kors.universal
6.2. Prefix Resolution
prefix and the prefix portion of object.id SHALL resolve through the canonical Pergamum Pulse Object & Prefix Register.
The profile SHALL NOT contain a hard-coded list of PP prefixes.
The validator SHALL resolve at minimum:
- prefix;
- canonical object name;
- normative owner;
- identifier policy;
- lifecycle authority;
- deprecation status.
6.3. Prefix Rules
PP-OBJ-001 Every PP object identifier resolves through the Object & Prefix Register.
PP-OBJ-002 An unregistered PP object prefix is non-conformant.
PP-OBJ-003 Every prefix has exactly one normative owner.
PP-OBJ-004 Duplicate active normative ownership is prohibited.
PP-OBJ-005 Deprecated prefixes require governed migration treatment.
7. Universal Lifecycle
PP-KORS owns the universal first-class object lifecycle.
This profile SHALL NOT duplicate the PP-KORS lifecycle vocabulary.
Example:
pergamum_pulse:
object:
lifecycle_status: active
lifecycle_profile: pp-kors.universal
Specialised specifications MAY define permitted subsets and transitions.
Workflow, review, extraction, conflict, adoption, projection and Runtime activation states SHALL remain separate dimensions.
A value such as approved in a review record SHALL NOT automatically become a universal lifecycle_status.
8. Source Identity
Source metadata SHALL preserve identity independently from document representation.
Example:
pergamum_pulse:
source:
source_id: PP-SRC-000001
source_series_id: PP-SRS-000001
source_type: licensed_publication
title: Example Standard
publisher: Example Publisher
issuing_authority: Example Authority
source_version: "2026"
official_url: https://example.invalid/source
authority_class: standards_body
source_digest: sha256:...
source_id and source_series_id SHALL resolve through the Object & Prefix Register and their normative object contracts.
9. Source Capture
Example:
pergamum_pulse:
capture:
capture_id: PP-CAP-000001
source_id: PP-SRC-000001
captured_at: 2026-08-10T10:00:00Z
acquisition_method: official_download
media_type: application/pdf
original_filename: example.pdf
source_digest: sha256:...
storage_reference: restricted://source-captures/PP-CAP-000001
Source Capture SHALL remain distinct from Source Object.
The immutable capture SHALL be sufficient to reproduce or audit downstream transformations where rights permit.
10. Rights Metadata
10.1. Authority
PP-RLCPS is the exclusive normative authority for:
- Rights Records;
- permission basis;
- rights scope;
- processing rights;
- publication rights;
- attribution;
- rights evidence;
- validity;
- rights status.
10.2. Reference and Projection
The Pergamum Pulse profile SHALL reference a canonical PP-RGT- Rights Record.
Example:
pergamum_pulse:
rights:
rights_record_id: PP-RGT-000001
rights_record_version: 1.0.0
projection:
status: verified
processing_rights:
parsing:
state: permitted
structured_extraction:
state: permitted
embeddings:
state: permitted_with_conditions
retrieval_augmented_generation:
state: restricted
foundation_model_training:
state: prohibited
publication_rights:
internal_publication:
state: permitted
public_web_publication:
state: prohibited
attribution:
required: true
The projection SHALL NOT create independent rights authority.
Where projected metadata conflicts with the referenced Rights Record, the canonical Rights Record SHALL prevail and the projection SHALL fail conformance.
10.3. Vocabulary Resolution
Processing-right operation keys and permission states SHALL be resolved from the RLCPS-governed machine-readable vocabulary when available.
They SHALL NOT be independently hard-coded by the metadata profile or VW-DL.
11. Authority Metadata
Pergamum Pulse SHALL preserve authority dimensions separately.
Example:
pergamum_pulse:
authority:
source_authority:
class: standards_body
legal_authority:
class: non_binding_guidance
evidentiary_authority:
permitted_for:
- requirement_evidence
zayaz_governance_authority:
class: governed_reference
runtime_authority:
class: none
Authority dimensions SHALL NOT be collapsed into one confidence or trust score.
Source authority SHALL NOT imply ZAYAZ governance authority or Runtime authority.
12. Transformation Provenance
Example:
pergamum_pulse:
transformation:
transformation_id: PP-TRN-000001
input_capture_id: PP-CAP-000001
method: ocr_extracted
tool:
name: example-ocr
version: 1.0.0
output_digest: sha256:...
rights_record_id: PP-RGT-000001
transformed_at: 2026-08-10T10:15:00Z
Every material transformation SHOULD preserve:
- exact input identity/version;
- input digest;
- transformation method;
- tool/model identity and version;
- configuration/profile;
- output identity/digest;
- rights context;
- actor;
- time;
- provenance.
Transformation identity SHALL resolve through the Object & Prefix Register once its prefix is registered.
13. Temporal Metadata
Pergamum Pulse SHOULD preserve bitemporal semantics where material.
pergamum_pulse:
temporal:
valid_from: 2026-01-01T00:00:00Z
valid_to: null
recorded_at: 2026-08-10T10:15:00Z
superseded_at: null
Valid time and transaction time SHALL remain distinguishable.
14. Applicability
Example:
pergamum_pulse:
applicability:
state: applicable
jurisdictions:
- eu
sectors: []
organisation_types: []
legal_roles: []
products: []
services: []
frameworks: []
modules:
- pergamum-pulse
components: []
tenants: []
white_label_operators: []
valid_from: null
valid_to: null
Applicability vocabularies SHALL be governed by their owning specification or registry.
The metadata profile SHALL not generalise applicability beyond explicit evidence.
15. Knowledge Classification
Example:
pergamum_pulse:
knowledge:
knowledge_classes:
- requirement
- definition
- evidence_requirement
extraction_status: human_reviewed
assertion_count: 12
unresolved_assertion_count: 1
Knowledge classification SHALL distinguish source representation from governed semantic assertions.
A classification SHALL NOT create authority.
16. Knowledge Assertions
PP-KAS owns Knowledge Assertion semantics.
The profile SHALL reference assertions rather than redefine the assertion contract.
pergamum_pulse:
assertions:
assertion_ids:
- PP-KA-000101
- PP-KA-000102
assertion_set_version: 1.2.0
Where state dimensions are projected, they SHALL remain separate:
pergamum_pulse:
assertions:
state_projection:
extraction_status: human_reviewed
review_status: approved
conflict_status: none
adoption_status: governed_reference
projection_status: not_projected
activation_status: not_applicable
These states SHALL NOT redefine PP-KORS universal lifecycle.
17. Source Fragments
Example:
pergamum_pulse:
fragments:
source_fragment_ids:
- PP-SF-000101
- PP-SF-000102
Source Fragments are stable semantic evidence units.
Retrieval Chunks are derived retrieval-purpose projections and SHALL NOT replace Source Fragment identity.
Fragment lineage SHOULD resolve to Source Capture and exact locators.
18. Knowledge Entities
Example:
pergamum_pulse:
entities:
describes:
- PP-KE-000201
primary_entity: PP-KE-000201
Entity identity SHALL remain independent from document identity.
19. Semantic Mapping and Crosswalks
PP-SMCS owns semantic mapping and crosswalk semantics.
Example:
pergamum_pulse:
mappings:
mapping_ids:
- PP-MAP-000301
crosswalk_sets:
- PP-CWS-000040
The profile SHALL NOT invent mapping equivalence semantics.
20. Change Intelligence
PP-CCPS owns Change Candidate, Change Decision and projection semantics.
Example:
pergamum_pulse:
change_intelligence:
detected_change_ids:
- PP-CDE-000401
change_candidates:
- PP-CC-000402
change_decisions:
- PP-CD-000403
change_status: candidate_created
Observed change SHALL remain separate from approved change.
No Change Candidate SHALL activate Runtime state merely by existing or being structurally valid.
21. Projection
Example:
pergamum_pulse:
projection:
projection_manifest_id: PP-PRJ-000501
change_decision_id: PP-CD-000403
generated_artefacts:
- PP-GA-000502
release_id: null
activation_record_id: null
Projection, release and activation SHALL remain distinct lifecycle/authority events.
22. Retrieval, Embedding and AI Processing
PP-REAPP owns retrieval and AI-processing eligibility.
Example:
pergamum_pulse:
retrieval:
eligibility_record_id: PP-RER-000601
chunking_profile_id: PP-CHP-000602
embedding_profile_id: PP-EMP-000603
chunks:
- PP-CHK-000604
A Retrieval Eligibility Record is an operational eligibility decision derived from applicable rights, scope, security, purpose and lifecycle.
It SHALL NOT replace the canonical Rights Record.
The profile SHALL preserve the distinction among:
- Source Fragment;
- Knowledge Chunk;
- embedding;
- index entry;
- Retrieval Result;
- Context Package;
- AI Inference Record.
23. Review and Approval
Example:
pergamum_pulse:
review:
review_records:
- PP-RVW-000701
status_projection:
semantic_review: approved
rights_review: approved
Review outcomes SHALL remain separate from universal lifecycle state.
Human authority-bearing Decisions SHALL remain distinguishable from automated validation.
24. Provenance and Lineage
Example:
pergamum_pulse:
provenance:
created_by: actor.architecture-owner
created_at: 2026-08-10T10:00:00Z
source_objects:
- PP-SRC-000001
source_captures:
- PP-CAP-000001
transformations:
- PP-TRN-000001
assertions:
- PP-KA-000101
change_decisions:
- PP-CD-000403
projection_manifests:
- PP-PRJ-000501
Lineage SHALL be sufficient to explain a material derived artefact back to its source evidence and governed Decisions.
25. HECATE Conformance
PP-HKCP owns HECATE knowledge conformance semantics.
Example:
pergamum_pulse:
conformance:
profile_id: PP-HCP-000801
receipts:
- PP-RCPT-000802
unresolved_findings:
- PP-FND-000803
HECATE validates conformance.
HECATE SHALL NOT become the source of legal rights, semantic meaning, Publication authority or Runtime activation authority.
26. Required Profile Resolution Matrix
The following minimum resolution rules apply.
| Metadata area | Required resolver |
|---|---|
| PP object identifier | Object & Prefix Register |
| Corpus document ID | PP-DREG / constitutional document registry |
| Universal lifecycle | PP-KORS lifecycle authority |
| Rights Record | PP-RLCPS |
| Knowledge Assertion | PP-KAS |
| Mapping/Crosswalk | PP-SMCS |
| Change/Projection | PP-CCPS |
| Retrieval/AI eligibility | PP-REAPP |
| HECATE conformance | PP-HKCP |
| Schemas/registry artefacts | PP-SRAG |
27. Unknown and Missing Semantics
A missing value SHALL NOT be silently interpreted as:
- false;
- permitted;
- prohibited;
- approved;
- applicable;
- authoritative;
- inactive.
Where the governing authority provides explicit unknown/unresolved states, those states SHALL be used.
Where no state is available, the validator SHALL emit a finding rather than invent semantics.
28. Profile Composition
A document MAY declare additional domain profiles.
metadata_contract:
specification:
id: PP-KDMS
version: 0.2.0
profiles:
- PP-MPS@0.1.0
- PP-PROFILE-IOT-ORIGIN@0.1.0
conformance_target: automation-eligible
Profiles SHALL:
- add constraints;
- add fields within governed namespaces;
- add registry references;
- add validation requirements.
Profiles SHALL NOT:
- weaken base rights;
- weaken lifecycle governance;
- change object identity;
- broaden authority;
- bypass review;
- broaden Publication eligibility;
- activate Runtime state.
29. VW-DL Validation Families
29.1. Constitutional Header Validation
VW-DL SHALL validate:
- CMS universal header;
- metadata contract declaration;
- profile resolution;
- object identifier/prefix resolution;
- rights reference shape;
- prohibited legacy aliases where migration policy applies;
- resolvable relationships;
- schema/profile references.
29.2. Corpus Integrity
VW-DL SHALL separately validate:
- Object & Prefix Register completeness;
- exactly one normative owner per prefix;
- Document Register completeness;
- document version agreement;
- document status agreement;
- source-file agreement;
- unregistered PP prefixes;
- heading hierarchy;
- duplicated semantic/document IDs;
- stale or phantom profiles.
These two families SHALL remain distinguishable in reports and CI policy.
30. Migration Compatibility
Existing PP-KDMS@0.2.0 documents MAY contain legacy metadata fields during a governed migration period.
Migration SHALL prefer warnings over blocking errors for deprecated-but-understood fields until the applicable migration baseline declares them prohibited.
Examples include metadata whose semantics have moved to an authoritative subordinate specification.
Migration tooling SHALL:
- identify legacy fields;
- identify canonical target path;
- preserve the old value;
- propose the new representation;
- record uncertainty;
- require review where semantics cannot be mapped deterministically;
- produce a migration receipt.
31. Conformance Findings
Findings SHALL be structured.
Example:
{
"rule_id": "PP-OBJ-001",
"severity": "ERROR",
"profile": "PP-MPS@0.1.0",
"field": "pergamum_pulse.object.id",
"value": "PP-XYZ-000001",
"message": "Object prefix PP-XYZ- is not registered.",
"registry": "PP-OBJECT-PREFIX-REGISTER",
"autofix": false
}
32. Foundational Principle
Pergamum Pulse metadata is an addressable governance envelope, not a second source of truth.
The profile SHALL make a knowledge asset explainable while preserving the authority of the object, rights, assertion, mapping, change, retrieval, validation and registry specifications that govern its meaning.
A conformant profile lets humans, ZARA, HECATE, VW-DL and downstream architecture tooling answer:
What is this?
Where did it come from?
Can we use it?
Who says so?
When is it valid?
Where does it apply?
What knowledge does it assert?
What changed?
What may be retrieved or processed?
Who reviewed it?
What was projected?
What was activated?
Can the complete path be reproduced?