Pergamum Pulse Knowledge Document and Metadata Framework
Part IV — Change Intelligence, Projection and Activation
4.1 Purpose
Part IV defines how Pergamum Pulse converts governed semantic knowledge into controlled proposals for change across ZAYAZ.
It governs:
- source and semantic change detection;
- impact analysis;
- Change Candidates;
- Change Decisions;
- projection generation;
- compiler interaction;
- generated artefacts;
- validation;
- activation boundaries;
- rollback;
- historical preservation.
The foundational rule is:
Pergamum Pulse SHALL discover, analyse and propose change. It SHALL NOT silently modify authoritative ZAYAZ state.
The lifecycle is:
Knowledge Change
│
▼
Change Detection
│
▼
Impact Analysis
│
▼
Change Candidate
│
▼
Validation and Review
│
▼
Change Decision
│
▼
Projection Generation
│
▼
HECATE Validation
│
▼
Activation Decision
│
▼
Runtime / Registry / Schema Update
4.2 Change Intelligence Architecture
Change Intelligence SHALL analyse changes across:
- sources;
- documents;
- assertions;
- entities;
- relationships;
- mappings;
- rights;
- applicability;
- generated artefacts.
It SHALL distinguish:
- informational change;
- semantic change;
- operational change;
- constitutional-impacting change.
4.3 Change Detection
Change Detection MAY operate on:
- new Source Captures;
- new document versions;
- modified assertions;
- changed entities;
- changed relationships;
- changed rights;
- changed mappings;
- changed profiles.
Change Detection SHALL preserve:
- previous version;
- new version;
- detected difference;
- detection method;
- confidence;
- provenance.
4.4 Change Classes
Change classes MAY include:
Editorial Change
A change affecting presentation without changing meaning.
Metadata Change
A change affecting classification, identity or documentation.
Semantic Change
A change affecting meaning, assertions, relationships or applicability.
Rights Change
A change affecting permitted use, publication or processing.
Schema Change
A change affecting generated structures.
Registry Change
A change affecting governed Registry objects.
Runtime Change
A change affecting execution behaviour.
Constitutional Change
A change affecting ZAYAZ Core meaning or protected architecture.
Constitutional-impacting changes SHALL follow Constitutional Evolution processes.
4.5 Semantic Difference Analysis
A semantic diff SHALL compare:
- assertions;
- entities;
- relationships;
- mappings;
- applicability;
- confidence;
- authority;
- temporal state.
Example:
Previous Knowledge State
│
▼
Semantic Difference Engine
│
▼
Changed Meaning
│
▼
Affected ZAYAZ Objects
Semantic similarity SHALL NOT automatically mean equivalence.
4.6 Impact Analysis
Every material change SHALL support impact analysis.
Impact dimensions MAY include:
- Requirements;
- Controls;
- Evidence Requirements;
- Tests;
- Schemas;
- Registries;
- Computation models;
- Workflows;
- Agents;
- Modules;
- Components;
- Extensions;
- Tenants;
- White-label deployments;
- Runtime;
- Publications;
- Certifications.
Example:
Changed Regulation
│
├── Requirement Registry
├── Control Registry
├── Evidence Requirements
├── Assessments
├── Reports
└── Customer Obligations
4.7 Change Candidate Model
A Change Candidate (PP-CC-) represents a proposed governed change.
It SHALL include:
- Candidate identity;
- source knowledge;
- affected assertions;
- target objects;
- proposed operation;
- proposed values;
- impact analysis;
- rights status;
- authority requirements;
- validation state;
- review state;
- provenance.
Example:
candidate_id: PP-CC-000001
source_assertions:
- PP-KA-000101
target:
object_type: requirement_registry
object_id: REQ-00042
operation:
type: modify
status:
review: pending
4.8 Change Candidate Types
Candidates MAY propose:
- create;
- update;
- deprecate;
- supersede;
- restrict;
- remove;
- reclassify;
- remap;
- split;
- merge.
4.9 Change Decision Model
A Change Decision (PP-CD-) records authorised treatment.
It SHALL identify:
- Candidate;
- decision authority;
- decision;
- conditions;
- effective date;
- scope;
- signatures;
- rationale;
- provenance.
Decisions MAY be:
- approved;
- approved with conditions;
- rejected;
- deferred;
- returned for revision;
- escalated;
- expired;
- superseded.
A Change Candidate without a Change Decision SHALL NOT produce activated output.
4.10 Projection Architecture
Projection converts approved knowledge changes into machine-readable artefacts.
Projection outputs MAY include:
- JSON;
- JSON Schema;
- Registry entries;
- validation rules;
- test fixtures;
- workflow definitions;
- connector manifests;
- profile definitions.
Projection SHALL preserve:
- source knowledge;
- assertions;
- Change Decisions;
- compiler version;
- generated outputs;
- digests;
- provenance.
4.11 Projection Manifest
A Projection Manifest (PP-PRJ-) SHALL identify:
- projection identity;
- source documents;
- source assertions;
- approved Changes;
- compiler version;
- generated artefacts;
- output digests;
- validation results;
- activation state.
Example:
projection_id: PP-PRJ-000001
sources:
- PP-KD-000001
approved_changes:
- PP-CD-000001
outputs:
- requirements.json
activation:
status: not_activated
4.12 Constitutional Compiler Integration
The Constitutional Compiler MAY:
- generate governed artefacts;
- validate structure;
- create reproducible outputs;
- preserve lineage.
The Compiler SHALL NOT:
- create authority;
- approve meaning;
- grant rights;
- bypass Change Decisions;
- activate Runtime state.
4.13 HECATE Projection Validation
HECATE MAY validate:
- source lineage;
- Change Decision;
- projection completeness;
- schema validity;
- generated artefact integrity;
- digests;
- provenance;
- Module lineage;
- Component lineage.
HECATE SHALL NOT:
- decide policy;
- decide legal interpretation;
- approve semantic disputes;
- replace human authority.
4.14 Activation Governance
Activation is separate from projection.
Generated output states MAY include:
- generated;
- validated;
- approved;
- activation pending;
- active;
- suspended;
- rolled back;
- retired.
Activation SHALL identify:
- activating authority;
- target environment;
- affected tenants;
- affected Modules;
- affected Components;
- effective time;
- rollback path;
- provenance.
4.15 Runtime and Registry Protection
Pergamum Pulse SHALL NOT directly overwrite:
- Runtime configuration;
- active Registries;
- schemas;
- policies;
- workflows;
- computation logic.
Updates SHALL pass through:
- governed projection;
- validation;
- activation;
- Runtime controls.
4.16 Rollback and Recovery
Every activated projection SHOULD support rollback.
Rollback SHALL preserve:
- previous active version;
- reason;
- authority;
- affected objects;
- time;
- recovery state;
- provenance.
Rollback SHALL NOT delete history.
4.17 Change Conflicts
Conflicting Change Candidates SHALL preserve:
- competing proposals;
- sources;
- reviewers;
- rationale;
- authority;
- resolution.
The system SHALL NOT silently select one.
4.18 Tenant and White-Label Impact
Change Intelligence SHALL evaluate:
- tenant applicability;
- white-label applicability;
- contractual impact;
- customer communication;
- migration needs;
- publication impact.
Tenant-specific changes SHALL NOT automatically become global changes.
4.19 Historical Change Reconstruction
Historical reconstruction SHALL identify:
- source knowledge version;
- assertions used;
- Change Candidate;
- Change Decision;
- projection;
- compiler version;
- activation event;
- affected Runtime state.
4.20 Pergamum Pulse Intelligence
Pergamum Pulse MAY analyse:
- change velocity;
- regulatory volatility;
- knowledge drift;
- mapping drift;
- stale projections;
- unresolved Candidates;
- impact concentration;
- dependency risk.
These insights SHALL remain non-authoritative.
4.21 Part IV Provenance
Part IV provenance SHALL connect:
- Source Object;
- Source Capture;
- Knowledge Document;
- Knowledge Assertion;
- Knowledge Entity;
- Relationship;
- Mapping;
- Change Candidate;
- Change Decision;
- Projection Manifest;
- Compiler execution;
- Generated artefact;
- Activation;
- Rollback;
- Module lineage;
- Component lineage;
- Tenant lineage;
- White-label lineage;
- Temporal lineage.
4.22 Part IV Conformance
An implementation conforms to Part IV where it:
- detects source and semantic changes;
- preserves differences between versions;
- performs impact analysis;
- creates governed Change Candidates;
- separates Candidates from Decisions;
- preserves approval authority;
- generates Projection Manifests;
- separates projection from activation;
- prevents automatic Runtime modification;
- preserves compiler lineage;
- validates projections;
- supports rollback;
- preserves tenant and white-label impact;
- preserves historical change state;
- maintains Module and Component lineage;
- prevents intelligence outputs from becoming authority.
Part IV Foundational Principle
Knowledge creates value when it can safely evolve systems without silently changing them.
Pergamum Pulse SHALL transform discovered change into governed proposals, not uncontrolled updates.
A changed source is not automatically a changed requirement. A changed assertion is not automatically a changed policy. A generated file is not automatically an active system state.
By separating detection, interpretation, decision, projection and activation, Pergamum Pulse enables ZAYAZ to continuously evolve while preserving authority, explainability, legal integrity and historical trust.