Skip to main content

Pergamum Pulse Change Candidate and Projection Specification

Version 0.1 — Normative Proposal, Decision and Projection Contract​

This specification defines how Pergamum Pulse converts governed knowledge change into reviewable proposals and reproducible machine-generated artefacts without silently changing authoritative ZAYAZ state.

It governs:

  • change triggers;
  • structural and semantic differences;
  • change classification;
  • Change Candidate identity;
  • target identity;
  • proposed operations;
  • proposed payloads;
  • impact analysis;
  • dependency analysis;
  • risk and materiality;
  • authority;
  • rights;
  • applicability;
  • confidence;
  • conflict;
  • review;
  • Change Decisions;
  • approval conditions;
  • candidate packaging;
  • projection eligibility;
  • Projection Manifests;
  • compiler execution;
  • generated artefacts;
  • deterministic builds;
  • validation;
  • signatures and digests;
  • release and activation boundaries;
  • rollback;
  • withdrawal;
  • tenant and white-label isolation;
  • security;
  • incident response;
  • historical reconstruction;
  • HECATE validation;
  • conformance.

The governing principles are:

Pergamum Pulse SHALL discover, analyse and propose change. It SHALL NOT silently redefine or activate authoritative ZAYAZ state.

A changed source is not automatically a changed Requirement, Control, Registry value, schema, computation, policy, workflow or Runtime instruction.

A Change Candidate is a governed proposal. It is not an approval, projection or activation.

A Change Decision is an authority-bearing treatment of a Candidate. It is not generated output or active state.

A Projection Manifest records reproducible generated artefacts. It is not evidence that those artefacts are active.

Every proposed change SHALL preserve its source knowledge, reasoning, affected targets, rights, applicability, impact, review, Decision and provenance.

Every generated artefact SHALL be reproducible from pinned inputs, compiler versions, configuration and approved Decisions.

Projection and activation SHALL remain separate lifecycle domains with separate authorities, controls, timestamps and rollback paths.

A successful build, schema validation or HECATE receipt SHALL NOT create semantic, legal, constitutional or Runtime authority.

Conflicting, incomplete, rights-restricted or high-impact Candidates SHALL remain visible and reviewable rather than being silently discarded or automatically applied.

Historical reconstruction SHALL show exactly which knowledge, Decisions, compiler inputs and generated artefacts produced a given system state.

1. Scope​

This specification applies to every:

  • Change Candidate identified by PP-CC-;
  • Change Decision identified by PP-CD-;
  • Projection Manifest identified by PP-PRJ-;
  • Candidate Package;
  • impact assessment;
  • dependency record;
  • generated artefact;
  • compiler execution;
  • validation receipt;
  • projection release;
  • activation request;
  • rollback record;
  • withdrawal record;
  • historical projection record.

It applies to proposed changes affecting:

  • Constitutional knowledge;
  • Core;
  • Extensions;
  • Registries;
  • schemas;
  • JSON and YAML artefacts;
  • Requirement objects;
  • Control objects;
  • Evidence Requirements;
  • validators;
  • HECATE rules;
  • workflows;
  • Agents;
  • prompts and Profiles;
  • Computation Hub models;
  • formulas;
  • factors;
  • datasets;
  • code lists;
  • Origin profiles;
  • connectors;
  • parsers;
  • device profiles;
  • reports;
  • Publications;
  • certification criteria;
  • assurance criteria;
  • Runtime configurations;
  • tenant overlays;
  • white-label overlays.

This specification does not itself authorise:

  • constitutional evolution;
  • public Publication;
  • certification;
  • Runtime activation;
  • tenant migration;
  • destructive data transformation;
  • legal interpretation;
  • rights expansion.

Those actions require their own governing frameworks and 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 a target framework, constitutional rule, approved ADR or domain Profile imposes stricter change controls, the stricter requirement prevails.

No Profile SHALL weaken:

  • source lineage;
  • target identity;
  • rights;
  • authority separation;
  • impact analysis;
  • Decision traceability;
  • deterministic projection;
  • validation;
  • tenant isolation;
  • rollback;
  • historical reconstruction;
  • activation separation.

3. Controlled Change Architecture​

The canonical path is:

Source or Knowledge Change
          │
          ▼
Difference Detection
          │
          ▼
Semantic and Structural Analysis
          │
          ▼
Impact and Dependency Analysis
          │
          ▼
Change Candidate
          │
          ▼
Review, Conflict and Risk Treatment
          │
          ▼
Change Decision
          │
          ▼
Projection Eligibility Gate
          │
          ▼
Projection Manifest
          │
          ▼
Constitutional Compiler or Approved Generator
          │
          ▼
Generated Artefacts and Validation Receipts
          │
          ▼
Release / Activation Request
          │
          ▼
Separate Activation Authority
          │
          ▼
Active State with Rollback and Historical Lineage

The following SHALL remain separate:

  • detected difference;
  • interpreted change;
  • Change Candidate;
  • Change Decision;
  • Projection Manifest;
  • generated artefact;
  • released artefact;
  • activation request;
  • active state;
  • rollback state;
  • historical state.

4. Canonical Change and Projection Objects​

ObjectPrefixPurpose
Change Detection EventPP-CDE-Records detected structural, semantic or rights change
Difference RecordPP-DIF-Preserves old/new values and classified difference
Impact AssessmentPP-IA-Records affected objects, systems and stakeholders
Dependency AssessmentPP-DA-Records upstream and downstream dependencies
Change CandidatePP-CC-Represents one governed proposed change
Candidate PackagePP-CCP-Groups Candidates for coordinated review or release
Candidate ConflictPP-CCF-Records incompatible or competing Candidates
Candidate ReviewPP-CRV-Records review of a Candidate or Package
Change DecisionPP-CD-Records approval, rejection or conditional treatment
Decision ConditionPP-DCO-Records an enforceable approval condition
Projection ManifestPP-PRJ-Records projection inputs, outputs and lineage
Compiler ExecutionPP-CEX-Records one compiler or generator execution
Generated ArtefactPP-GA-Identifies one generated output
Validation ReceiptPP-VR-Records deterministic validation results
Projection ReleasePP-REL-Records release of validated artefacts
Activation RequestPP-AR-Requests separate activation
Activation RecordPP-ACT-Records authorised activation
Rollback RecordPP-RBK-Records reversal to a prior active state
Projection WithdrawalPP-PWD-Records withdrawal of a projection or release
Change IncidentPP-CIN-Records a change or projection incident
Historical Change RecordPP-HCR-Preserves prior candidate, Decision and projection state

5. Change Detection Event​

A Change Detection Event records that a potential change has been observed.

change_detection_event:
  event_id: PP-CDE-000001
  detection_type: source_version_change

  source_objects:
    - PP-SRC-000001

  previous_state:
    capture_id: PP-CAP-000101

  current_state:
    capture_id: PP-CAP-000102

  detected_by:
    component_id: component.pergamum.change-detector
    method: semantic_and_structural_diff
    version: 1.4.0

  detected_at: 2026-08-04T19:30:00Z
  provenance: {}

5.1. Detection Sources​

Detection MAY originate from:

  • new Source Captures;
  • new document versions;
  • source withdrawal;
  • rights changes;
  • assertion changes;
  • entity changes;
  • mapping changes;
  • Crosswalk changes;
  • Registry changes;
  • schema changes;
  • model or prompt changes;
  • manual review;
  • tenant request;
  • incident response;
  • constitutional evolution.

5.2. Detection Non-Authority​

A Detection Event SHALL NOT establish:

  • materiality;
  • correctness;
  • applicability;
  • authority;
  • approval;
  • projection eligibility;
  • activation eligibility.

5.3. Detection Reproducibility​

Automated detection SHOULD preserve:

  • detector;
  • detector version;
  • configuration;
  • input versions;
  • excluded fields;
  • normalisation rules;
  • output digest;
  • provenance.

6. Difference Record​

A Difference Record SHALL preserve the exact old and new states relevant to the Candidate.

difference_record:
  difference_id: PP-DIF-000001
  difference_class: semantic_change

  target_path:
    object_id: PP-KA-000001
    property: applicability.jurisdictions

  previous_value:
    - eu

  current_value:
    - eu
    - eea

  interpretation_status: pending_review
  provenance: {}

6.1. Difference Classes​

Classes MAY include:

  • editorial;
  • formatting;
  • metadata;
  • identity;
  • semantic;
  • applicability;
  • authority;
  • rights;
  • temporal;
  • value;
  • threshold;
  • formula;
  • relationship;
  • mapping;
  • schema;
  • Registry;
  • workflow;
  • Runtime;
  • Publication;
  • certification;
  • constitutional.

6.2. Structural Difference​

A structural difference changes representation or structure.

6.3. Semantic Difference​

A semantic difference changes meaning, scope, conditions, exceptions, authority or applicability.

6.4. Rights Difference​

A rights difference changes permitted storage, processing, retrieval, training, Publication or redistribution.

6.5. Difference Non-Equivalence​

Textual change SHALL NOT automatically be treated as semantic change.

Absence of textual change SHALL NOT prove semantic stability where external interpretation or applicability changed.

7. Change Classification​

Every proposed change SHALL receive one or more governed classes.

Core classes MAY include:

  • editorial change;
  • metadata change;
  • corrective change;
  • additive change;
  • restrictive change;
  • deprecating change;
  • superseding change;
  • semantic change;
  • rights change;
  • applicability change;
  • schema change;
  • Registry change;
  • computation change;
  • workflow change;
  • Agent change;
  • Publication change;
  • Runtime change;
  • constitutional change;
  • emergency change;
  • security change.

7.1. Constitutional Classification​

A change affecting protected Core meaning, constitutional authority, protected invariants or framework boundaries SHALL be routed to the Constitutional Evolution Framework.

7.2. Emergency Classification​

Emergency classification SHALL identify:

  • immediate risk;
  • temporary authority;
  • reduced review permitted;
  • compensating controls;
  • expiry;
  • mandatory retrospective review;
  • rollback;
  • provenance.

Emergency treatment SHALL NOT permanently bypass constitutional controls.

7.3. Classification Review​

Material classification SHALL be reviewed where it controls the approval path.

8. Canonical Change Candidate​

change_candidate:
  candidate_id: PP-CC-000001
  semantic_id: pp.change.requirement-registry.update.req-000042
  candidate_version: 1.0.0
  candidate_type: modify

  source_basis:
    detection_events:
      - PP-CDE-000001
    differences:
      - PP-DIF-000001
    assertions:
      - PP-KA-000101
    mappings:
      - PP-MAP-000201

  target:
    target_type: requirement_registry_entry
    target_id: REQ-000042
    target_version: 3.1.0
    target_path: applicability.jurisdictions

  proposed_operation:
    type: replace
    expected_current_value:
      - eu
    proposed_value:
      - eu
      - eea

  impact_assessment_id: PP-IA-000001
  dependency_assessment_id: PP-DA-000001

  authority: {}
  rights: {}
  applicability: {}
  risk: {}
  review: {}
  status: {}
  provenance: {}

8.1. Required Candidate Fields​

Every machine-actionable Candidate SHALL include:

  • candidate_id;
  • candidate_version;
  • candidate_type;
  • source basis;
  • target;
  • proposed operation;
  • expected current state;
  • proposed state;
  • rationale;
  • impact assessment;
  • dependency assessment;
  • authority requirements;
  • rights;
  • applicability;
  • risk;
  • review;
  • status;
  • temporal validity;
  • provenance.

8.2. Optional Candidate Fields​

Optional fields MAY include:

  • semantic_id;
  • urgency;
  • priority;
  • requested effective date;
  • release train;
  • migration plan;
  • rollback plan;
  • test plan;
  • communication plan;
  • training plan;
  • candidate dependencies;
  • conflicts;
  • package membership;
  • affected Publications;
  • affected certifications;
  • affected tenants;
  • affected white-label operators.

9. Candidate Identity and Versioning​

Every Candidate SHALL possess an immutable PP-CC- identifier.

A Candidate Identifier SHALL NOT be reused for an unrelated proposal.

A materially changed proposal SHALL create a new Candidate version or successor Candidate.

Candidate version changes SHALL preserve:

  • predecessor;
  • successor;
  • changed fields;
  • reason;
  • reviewer;
  • time;
  • provenance.

Approved, rejected, expired and withdrawn Candidate versions SHALL remain historically immutable.

10. Candidate Types and Operations​

Candidate types MAY include:

  • create;
  • add;
  • replace;
  • modify;
  • restrict;
  • relax;
  • deprecate;
  • supersede;
  • suspend;
  • retire;
  • remove;
  • split;
  • merge;
  • reclassify;
  • remap;
  • migrate;
  • regenerate;
  • correct;
  • rollback;
  • restore.

10.1. Target Operation​

Every operation SHALL identify:

  • target object;
  • target version;
  • target property or path;
  • expected current value;
  • proposed value;
  • preconditions;
  • postconditions;
  • idempotency behaviour;
  • failure behaviour.

10.2. Compare-and-Set Protection​

A Candidate affecting mutable state SHOULD include an expected current value or digest.

Projection SHALL fail or require review if the current target state differs from the expected state.

10.3. Destructive Operation​

Remove, merge, split, destructive migration and irreversible transformation SHALL require enhanced impact analysis and rollback or compensating treatment.

10.4. No-Op Candidate​

A Candidate whose proposed state equals current state SHALL be classified as no-op and SHALL NOT be projected unless preserving a Decision or migration receipt is required.

11. Source Basis and Traceability​

Every Candidate SHALL preserve the knowledge basis that motivated it.

The source basis MAY include:

  • Source Objects;
  • Source Captures;
  • Rights Records;
  • Knowledge Documents;
  • Source Fragments;
  • Knowledge Assertions;
  • Knowledge Entities;
  • Mapping Objects;
  • Crosswalk Sets;
  • Findings;
  • incidents;
  • audit results;
  • tenant requests;
  • approved ADRs;
  • constitutional Decisions.

11.1. Minimum Source Basis​

A Candidate SHALL identify at least one governed source object or governed initiating Decision.

11.2. Derived Intelligence​

A Candidate based partly on AI or analytical intelligence SHALL identify:

  • input objects;
  • algorithm or model;
  • model version;
  • prompt or Rule version;
  • confidence;
  • limitations;
  • human review requirement;
  • provenance.

11.3. Unsupported Candidate​

A Candidate without sufficient source basis SHALL be classified as:

  • hypothesis;
  • design proposal;
  • emergency proposal;
  • unsupported;
  • quarantined.

It SHALL NOT be represented as source-mandated change.

11.4. Source Withdrawal​

Withdrawal or invalidation of source basis SHALL trigger Candidate and projection impact analysis.

12. Target Contract​

Every Candidate target SHALL be pinned to an identified object and version.

target:
  target_type: json_schema
  target_id: schema.zayaz.requirement
  target_version: 4.2.0
  target_path: properties.applicability
  target_digest: sha256:...
  target_environment: canonical_source

12.1. Target Classes​

Targets MAY include:

  • MDX source;
  • JSON;
  • YAML;
  • JSON Schema;
  • Registry entry;
  • Registry type;
  • requirement;
  • Control;
  • Evidence Requirement;
  • validator;
  • validation Rule;
  • test fixture;
  • workflow;
  • Agent Profile;
  • prompt Profile;
  • calculation model;
  • formula;
  • factor;
  • code list;
  • dataset schema;
  • connector manifest;
  • parser Profile;
  • Origin profile;
  • Runtime profile;
  • report template;
  • Publication template;
  • certification criterion;
  • assurance test.

12.2. Canonical Target Requirement​

The Candidate SHALL identify whether the target is:

  • canonical source;
  • governed projection;
  • tenant overlay;
  • white-label overlay;
  • Runtime copy;
  • Publication copy;
  • historical copy.

A Candidate SHALL not target a derived copy where canonical source must be changed.

12.3. Target Ownership​

Every target SHALL identify:

  • owning Module;
  • owning Component;
  • approving authority;
  • Runtime consumer where applicable;
  • Publication consumer where applicable.

12.4. Missing Target​

A create Candidate SHALL identify the intended namespace and owning authority.

A non-create Candidate referencing a missing target SHALL fail validation.

13. Proposed Payload​

A Candidate SHALL preserve the complete proposed payload or a reproducible patch.

13.1. Payload Forms​

Permitted forms MAY include:

  • complete replacement object;
  • JSON Patch;
  • JSON Merge Patch;
  • typed property update;
  • Registry transaction;
  • schema migration;
  • MDX frontmatter update;
  • controlled text replacement;
  • graph mutation;
  • code-list delta;
  • generated-template input;
  • compiler intermediate representation.

13.2. Patch Determinism​

A patch SHALL identify:

  • patch format;
  • patch version;
  • base object version;
  • target path;
  • expected value;
  • new value;
  • operation order;
  • conflict behaviour.

13.3. Human-Readable Explanation​

Every material machine payload SHOULD be accompanied by a human-readable explanation.

13.4. Hidden Change Prohibition​

A payload SHALL NOT contain unrelated or undisclosed changes.

13.5. Secret Prohibition​

Secrets, credentials, private keys and access tokens SHALL NOT be embedded in Candidate payloads.

14. Rationale​

Every Candidate SHALL preserve a rationale explaining:

  • why the change is proposed;
  • which knowledge supports it;
  • why the target is appropriate;
  • expected benefits;
  • risks;
  • alternatives considered;
  • rejected alternatives;
  • known limitations;
  • urgency;
  • consequences of no action.

A rationale SHALL distinguish:

  • source-derived requirement;
  • expert interpretation;
  • architectural judgement;
  • operational preference;
  • AI-generated recommendation;
  • legal or regulatory advice.

15. Impact Assessment​

Every material Candidate SHALL possess an Impact Assessment.

impact_assessment:
  assessment_id: PP-IA-000001
  candidate_id: PP-CC-000001

  impacted_domains:
    modules:
      - compliance
      - reports-hub
    components:
      - requirement-registry
      - report-validator

  impacts:
    schema: high
    runtime: moderate
    tenant: high
    publication: moderate
    certification: high

  severity: high
  provenance: {}

15.1. Impact Dimensions​

Impact analysis SHALL consider, where relevant:

  • constitutional meaning;
  • Core;
  • Extensions;
  • Registries;
  • schemas;
  • data migration;
  • Requirements;
  • Controls;
  • Evidence Requirements;
  • validators;
  • tests;
  • workflows;
  • Agents;
  • computations;
  • formulas;
  • factors;
  • datasets;
  • Origin profiles;
  • connectors;
  • parsers;
  • reports;
  • Publications;
  • certification;
  • assurance;
  • Runtime;
  • tenants;
  • white-label deployments;
  • partners;
  • regulators;
  • users;
  • contracts;
  • security;
  • privacy;
  • rights;
  • performance;
  • availability;
  • cost;
  • historical reconstruction.

15.2. Impact States​

Impact MAY be:

  • none;
  • informational;
  • low;
  • moderate;
  • high;
  • critical;
  • constitutional;
  • unresolved.

15.3. Negative and Positive Impact​

Impact analysis SHOULD preserve both expected benefits and adverse consequences.

15.4. Unknown Impact​

Unknown impact SHALL remain explicit and MAY block approval according to risk.

15.5. Impact Evidence​

Material impact claims SHALL link to evidence, analysis or competent review.

16. Dependency Assessment​

Every Candidate SHALL identify upstream and downstream dependencies.

dependency_assessment:
  assessment_id: PP-DA-000001

  upstream:
    - object_id: PP-KA-000101
      dependency_type: source_semantics

  downstream:
    - object_id: schema.zayaz.requirement
      dependency_type: generated_schema
    - object_id: report-template.esrs
      dependency_type: publication_dependency

16.1. Dependency Types​

Types MAY include:

  • semantic dependency;
  • schema dependency;
  • Registry dependency;
  • computation dependency;
  • workflow dependency;
  • Runtime dependency;
  • Publication dependency;
  • rights dependency;
  • tenant dependency;
  • white-label dependency;
  • certification dependency;
  • test dependency;
  • migration dependency.

16.2. Dependency Graph​

Candidate dependencies SHALL form a directed graph.

Cycles SHALL be detected and reviewed.

16.3. Dependency Ordering​

Projection order SHALL respect dependency order.

16.4. Blocking Dependency​

An unresolved blocking dependency SHALL prevent projection eligibility.

16.5. Optional Dependency​

Optional dependencies SHALL identify fallback behaviour.

17. Risk and Materiality​

Every material Candidate SHALL possess a risk classification.

Risk dimensions MAY include:

  • legal;
  • regulatory;
  • constitutional;
  • semantic;
  • rights;
  • security;
  • privacy;
  • safety;
  • financial;
  • operational;
  • reputational;
  • certification;
  • tenant;
  • white-label;
  • data integrity;
  • model risk;
  • rollback complexity.

17.1. Risk State​

Risk MAY be:

  • negligible;
  • low;
  • moderate;
  • high;
  • critical;
  • unresolved.

17.2. Materiality​

Materiality SHALL consider:

  • number of affected objects;
  • number of affected tenants;
  • severity of affected obligations;
  • effect on public claims;
  • effect on certification;
  • effect on financial calculations;
  • effect on historical comparability;
  • reversibility;
  • urgency.

17.3. Risk Acceptance​

Residual risk acceptance SHALL identify:

  • accepting authority;
  • accepted risks;
  • conditions;
  • expiry;
  • monitoring;
  • provenance.

18. Authority​

Every Candidate SHALL identify required authority independently from source authority.

authority:
  source_authority:
    class: regulator

  candidate_authority:
    class: proposal_only

  approval_required:
    - requirement-registry-owner
    - legal-reviewer

  constitutional_review_required: false
  runtime_authority:
    class: none

18.1. Authority Non-Transitivity​

An authoritative source SHALL NOT automatically approve a Candidate.

18.2. Target Authority​

Approval authority SHALL be derived from the target object's governance.

18.3. Constitutional Authority​

Constitutional-impacting Candidates SHALL require constitutional treatment.

18.4. Runtime Authority​

Runtime authority SHALL remain absent until separate activation.

19. Rights​

Every Candidate and projection SHALL preserve applicable Rights Records.

Rights analysis SHALL consider:

  • source content;
  • source fragments;
  • extracted assertions;
  • generated payload;
  • generated artefacts;
  • public diffs;
  • review materials;
  • external compiler or model use;
  • Publication;
  • redistribution;
  • tenant use;
  • white-label use.

19.1. Rights Gate​

Projection eligibility SHALL require a Rights Gate outcome appropriate to the intended artefacts and audience.

19.2. Restricted Inputs​

Restricted input content SHALL not be reproduced in generated artefacts beyond permission.

19.3. External Processing​

External generator, compiler, model or validation services SHALL be permitted by rights and security policy.

19.4. Rights Change​

Rights expiration or revocation SHALL trigger Candidate, projection, release and Publication impact analysis.

20. Applicability and Scope​

Every Candidate SHALL define its applicable scope.

applicability:
  knowledge_scope: global_canonical

  jurisdictions:
    - eu

  modules:
    - compliance

  components:
    - requirement-registry

  tenant_scope:
    mode: selected
    tenant_ids:
      - tenant.example

  white_label_scope:
    mode: none

  requested_effective_from: 2026-10-01

20.1. Scope Dimensions​

Dimensions MAY include:

  • jurisdiction;
  • legal role;
  • sector;
  • product;
  • service;
  • framework;
  • Module;
  • Component;
  • Extension;
  • Registry;
  • tenant;
  • white-label operator;
  • Runtime environment;
  • Publication channel;
  • time.

20.2. Global and Tenant Scope​

A tenant-specific Candidate SHALL NOT silently become global.

A global Candidate SHALL evaluate tenant and white-label override conflicts.

20.3. Scope Promotion​

Promotion to broader scope SHALL require new impact, rights, conflict and approval analysis.

21. Candidate Status Model​

Status dimensions SHALL remain separate.

status:
  detection_status: confirmed
  analysis_status: complete
  review_status: approved
  decision_status: approved_with_conditions
  projection_eligibility: eligible
  projection_status: not_started
  release_status: not_released
  activation_status: not_requested

21.1. Detection Status​

States MAY include:

  • detected;
  • confirmed;
  • false positive;
  • duplicate;
  • dismissed.

21.2. Analysis Status​

States MAY include:

  • not started;
  • in progress;
  • complete;
  • incomplete;
  • blocked;
  • expired.

21.3. Review Status​

States MAY include:

  • pending;
  • under review;
  • approved;
  • approved with conditions;
  • disputed;
  • rejected;
  • returned for revision.

21.4. Projection Eligibility​

States MAY include:

  • not evaluated;
  • ineligible;
  • conditionally eligible;
  • eligible;
  • expired;
  • revoked.

21.5. Projection Status​

States MAY include:

  • not started;
  • queued;
  • building;
  • generated;
  • validation failed;
  • validated;
  • released;
  • superseded;
  • withdrawn.

21.6. Activation Status​

States MAY include:

  • not applicable;
  • not requested;
  • requested;
  • approved;
  • active;
  • partially active;
  • suspended;
  • rolled back;
  • retired.

These states SHALL NOT be collapsed into one generic status.

22. Candidate Review​

Every Candidate SHALL receive risk-appropriate review.

Review classes MAY include:

  • source review;
  • semantic review;
  • legal review;
  • rights review;
  • architectural review;
  • schema review;
  • data review;
  • computation review;
  • security review;
  • privacy review;
  • tenant review;
  • white-label review;
  • certification review;
  • Publication review;
  • Runtime review.

22.1. Review Record​

A Candidate Review SHALL identify:

  • Candidate;
  • Candidate version;
  • reviewer;
  • competence;
  • review class;
  • evidence;
  • Findings;
  • recommendation;
  • conditions;
  • time;
  • expiry;
  • provenance.

22.2. Separation of Duties​

High-impact change SHOULD separate:

  • source interpretation;
  • Candidate authorship;
  • target ownership;
  • review;
  • Decision;
  • projection execution;
  • validation;
  • release;
  • activation.

22.3. Reviewer Conflict of Interest​

A material conflict of interest SHALL be disclosed and treated.

23. Candidate Conflict​

Conflicting Candidates SHALL be represented explicitly.

candidate_conflict:
  conflict_id: PP-CCF-000001
  candidate_ids:
    - PP-CC-000101
    - PP-CC-000102
  conflict_type: incompatible_target_value
  status: under_review

23.1. Conflict Types​

Types MAY include:

  • incompatible target value;
  • overlapping patch;
  • competing interpretation;
  • incompatible applicability;
  • dependency conflict;
  • rights conflict;
  • version conflict;
  • release conflict;
  • tenant override conflict;
  • constitutional conflict.

23.2. Conflict Resolution​

Resolution MAY include:

  • select one Candidate;
  • merge through a new Candidate;
  • split scope;
  • split time;
  • preserve accepted divergence;
  • reject all;
  • escalate;
  • defer.

23.3. Silent Winner Prohibition​

The system SHALL NOT silently choose based on priority, timestamp, confidence or automated ranking.

24. Candidate Package​

A Candidate Package groups coordinated Candidates.

candidate_package:
  package_id: PP-CCP-000001
  package_version: 1.0.0
  purpose: regulatory-release-2026-q4
  candidates:
    - PP-CC-000001
    - PP-CC-000002
  atomicity: all_or_nothing
  dependency_order:
    - PP-CC-000001
    - PP-CC-000002

24.1. Package Atomicity​

Atomicity MAY be:

  • all or nothing;
  • dependency groups;
  • independently deployable;
  • best effort;
  • manual sequence.

24.2. Package Non-Aggregation​

A Package SHALL NOT merge Candidate identity, authority, rights, review or Decision.

24.3. Partial Package Approval​

Partial approval SHALL identify approved and rejected members and re-evaluate package consistency.

24.4. Package Versioning​

Changed membership, ordering, atomicity or purpose SHALL create a new Package version.

25. Change Decision​

A Change Decision is the governed authority-bearing treatment of a Candidate.

change_decision:
  decision_id: PP-CD-000001
  decision_version: 1.0.0
  candidate_id: PP-CC-000001
  candidate_version: 1.0.0

  decision: approved_with_conditions

  authority:
    decision_roles:
      - requirement-registry-owner
      - legal-reviewer

  conditions:
    - PP-DCO-000001

  effective_from: 2026-08-10
  expires_at: 2026-11-10

  signatures: []
  rationale: {}
  provenance: {}

25.1. Decision States​

States MAY include:

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

25.2. Decision Scope​

A Decision SHALL specify:

  • Candidate version;
  • approved operation;
  • approved payload or digest;
  • approved scope;
  • approved purpose;
  • effective period;
  • conditions;
  • prohibited uses.

25.3. Decision Immutability​

An issued Decision SHALL be immutable.

Correction SHALL create a successor Decision.

25.4. Decision Expiration​

An expired Decision SHALL no longer permit new projection unless renewed.

25.5. Conditional Approval​

Every condition SHALL be machine-verifiable where feasible.

25.6. Rejection​

Rejection SHALL preserve rationale, evidence, reconsideration criteria and provenance.

26. Decision Conditions​

A Decision Condition SHALL identify:

  • condition identity;
  • condition type;
  • required state;
  • verification method;
  • responsible Role;
  • due time;
  • blocking or non-blocking class;
  • satisfaction receipt;
  • provenance.

Condition types MAY include:

  • additional evidence;
  • rights clearance;
  • schema validation;
  • migration readiness;
  • tenant notification;
  • security approval;
  • legal approval;
  • test coverage;
  • rollback readiness;
  • monitoring readiness;
  • effective-date restriction.

A blocking condition SHALL prevent projection or release according to its declared Gate.

27. Projection Eligibility Gate​

A Candidate SHALL pass a Projection Eligibility Gate before a Projection Manifest is created.

The Gate SHALL evaluate:

  • valid Candidate identity and version;
  • approved Change Decision;
  • unexpired Decision;
  • satisfied blocking conditions;
  • complete source lineage;
  • resolved rights;
  • valid target identity and version;
  • compare-and-set precondition;
  • complete impact assessment;
  • complete dependency assessment;
  • no unresolved blocking conflict;
  • sufficient review;
  • tenant and white-label scope;
  • migration readiness;
  • rollback readiness where required;
  • compiler support;
  • security approval;
  • provenance completeness.

27.1. Gate Outcomes​

Outcomes MAY include:

  • eligible;
  • conditionally eligible;
  • ineligible;
  • additional review required;
  • target drift detected;
  • Decision expired;
  • rights blocked;
  • conflict blocked;
  • migration blocked;
  • unable to determine.

27.2. Eligibility Non-Activation​

Projection eligibility SHALL NOT imply release or activation eligibility.

27.3. Eligibility Receipt​

The Gate SHOULD produce a machine-verifiable receipt containing:

  • Candidate;
  • Candidate version;
  • Decision;
  • conditions;
  • target digest;
  • evaluated rules;
  • result;
  • Findings;
  • time;
  • provenance.

28. Projection Manifest​

A Projection Manifest records the complete reproducible definition of one projection.

projection_manifest:
  projection_id: PP-PRJ-000001
  projection_version: 1.0.0
  projection_type: registry_and_schema

  candidate_package:
    package_id: PP-CCP-000001
    package_version: 1.0.0

  approved_decisions:
    - PP-CD-000001

  inputs:
    canonical_objects:
      - object_id: REQ-000042
        version: 3.1.0
        digest: sha256:...
    knowledge_objects:
      - object_id: PP-KA-000101
        version: 1.0.0

  compiler:
    component_id: constitutional-compiler
    version: 4.2.0
    configuration_digest: sha256:...

  outputs:
    - PP-GA-000001

  validation_receipts:
    - PP-VR-000001

  release_status: not_released
  activation_status: not_requested
  provenance: {}

28.1. Required Manifest Fields​

Every Projection Manifest SHALL include:

  • projection identity;
  • projection version;
  • projection type;
  • Candidates or Candidate Package;
  • approved Decisions;
  • satisfied conditions;
  • pinned input objects;
  • pinned input versions;
  • input digests;
  • compiler or generator;
  • compiler version;
  • configuration digest;
  • build environment;
  • generated artefacts;
  • validation receipts;
  • rights treatment;
  • scope;
  • release status;
  • activation status;
  • temporal metadata;
  • provenance.

28.2. Manifest Immutability​

A completed Projection Manifest SHALL be immutable.

A changed input, Decision, compiler, configuration or output SHALL create a new projection version.

28.3. Projection Types​

Projection types MAY include:

  • Registry projection;
  • JSON projection;
  • YAML projection;
  • JSON Schema projection;
  • validation-rule projection;
  • test-fixture projection;
  • workflow projection;
  • Agent Profile projection;
  • prompt Profile projection;
  • computation-model projection;
  • factor projection;
  • code-list projection;
  • connector projection;
  • parser projection;
  • Origin profile projection;
  • Runtime-profile projection;
  • report-template projection;
  • Publication projection;
  • certification-criteria projection;
  • multi-artefact release projection.

29. Projection Inputs​

Projection inputs SHALL be pinned and digest-verifiable.

Inputs MAY include:

  • approved Candidates;
  • approved Decisions;
  • Decision Conditions;
  • canonical Registry objects;
  • canonical schemas;
  • Knowledge Assertions;
  • Mapping Objects;
  • Crosswalk Sets;
  • Rights Decisions;
  • tenant overlays;
  • white-label overlays;
  • compiler templates;
  • generation Rules;
  • approved ADRs;
  • constitutional constraints.

29.1. Input Snapshot​

A projection SHOULD create or reference an immutable input snapshot.

29.2. Input Drift​

If an input changes after eligibility evaluation, the projection SHALL:

  • fail;
  • re-evaluate eligibility;
  • or create a new projection version.

29.3. Dynamic Input Prohibition​

Production projection SHALL NOT rely on unpinned mutable external content.

29.4. Unknown Input​

An unresolved required input SHALL block projection.

30. Compiler and Generator Contract​

Projection SHALL be executed by the Constitutional Compiler or another approved deterministic generator.

Every compiler or generator SHALL identify:

  • Component identity;
  • Module ownership;
  • version;
  • build digest;
  • source revision;
  • configuration;
  • templates;
  • dependencies;
  • execution environment;
  • security state;
  • provenance.

30.1. Compiler Authority Boundary​

The compiler MAY:

  • transform approved structured input;
  • generate governed artefacts;
  • enforce deterministic formatting;
  • apply approved templates;
  • calculate digests;
  • produce validation fixtures;
  • produce lineage manifests.

The compiler SHALL NOT:

  • approve semantic meaning;
  • create a Change Decision;
  • grant rights;
  • widen scope;
  • create constitutional authority;
  • create Runtime authority;
  • activate output;
  • silently repair an invalid Candidate.

30.2. Generator Determinism​

Given identical pinned inputs, compiler version, configuration and environment, a deterministic generator SHOULD produce identical artefact digests.

30.3. Non-Deterministic Generator​

A non-deterministic generator SHALL disclose:

  • source of non-determinism;
  • random seed where possible;
  • acceptable output variance;
  • validation method;
  • human review requirement;
  • reproducibility limitation.

30.4. External Generator​

Use of an external service SHALL satisfy:

  • rights;
  • confidentiality;
  • tenant restrictions;
  • security;
  • data-residency requirements;
  • retention requirements;
  • model-training restrictions;
  • provenance.

31. Compiler Execution​

Each execution SHALL create a Compiler Execution record.

compiler_execution:
  execution_id: PP-CEX-000001
  projection_id: PP-PRJ-000001

  compiler:
    component_id: constitutional-compiler
    version: 4.2.0
    build_digest: sha256:...

  environment:
    environment_id: build.pergamum.production
    container_digest: sha256:...
    dependency_lock_digest: sha256:...

  started_at: 2026-08-10T10:00:00Z
  completed_at: 2026-08-10T10:00:08Z
  status: succeeded

  input_digest: sha256:...
  output_digest: sha256:...
  provenance: {}

31.1. Execution Status​

States MAY include:

  • queued;
  • running;
  • succeeded;
  • failed;
  • cancelled;
  • timed out;
  • quarantined;
  • non-reproducible.

31.2. Execution Logs​

Logs SHALL preserve sufficient detail for audit without exposing secrets or restricted source content.

31.3. Execution Isolation​

Build environments SHOULD be isolated, ephemeral and least-privileged.

31.4. Dependency Integrity​

Dependencies SHALL be pinned and integrity-verified.

31.5. Software Bill of Materials​

Material compiler executions SHOULD produce or reference an SBOM for build dependencies.

32. Generated Artefact​

Every generated output SHALL be a first-class Generated Artefact.

generated_artefact:
  artefact_id: PP-GA-000001
  projection_id: PP-PRJ-000001
  artefact_type: json_schema
  canonical_path: generated/schemas/requirement.schema.json
  media_type: application/schema+json
  version: 4.3.0
  digest: sha256:...
  size_bytes: 48123
  activation_eligible: false
  provenance: {}

32.1. Artefact Types​

Artefacts MAY include:

  • JSON;
  • YAML;
  • JSON Schema;
  • MDX;
  • Registry transaction;
  • graph mutation set;
  • validation Rule;
  • test fixture;
  • workflow definition;
  • Agent Profile;
  • prompt Profile;
  • formula definition;
  • computation manifest;
  • factor table;
  • code list;
  • connector manifest;
  • parser Profile;
  • Origin profile;
  • Runtime profile;
  • report template;
  • Publication package;
  • migration script;
  • rollback package;
  • documentation index.

32.2. Artefact Identity​

Every artefact SHALL possess:

  • stable artefact identity;
  • version;
  • projection relationship;
  • media type;
  • canonical path or object location;
  • digest;
  • size;
  • classification;
  • rights;
  • scope;
  • provenance.

32.3. Generated Versus Canonical​

An artefact SHALL identify whether it is:

  • generated preview;
  • governed projection;
  • release candidate;
  • released artefact;
  • active artefact;
  • historical artefact.

32.4. Artefact Immutability​

Released artefacts SHALL be immutable.

32.5. Artefact Signing​

High-impact artefacts SHOULD be signed or accompanied by a signature receipt.

33. Multi-Artefact Projection​

A projection MAY generate several coordinated artefacts.

The Manifest SHALL identify:

  • artefact list;
  • dependency order;
  • atomicity;
  • compatibility matrix;
  • shared version;
  • partial-failure treatment;
  • rollback grouping;
  • provenance.

33.1. Atomic Projection​

An atomic projection SHALL not release a partial artefact set.

33.2. Independently Releasable Artefacts​

Independent release SHALL require declared compatibility and no hidden dependency.

33.3. Cross-Artefact Consistency​

Validation SHALL verify consistency across generated:

  • schemas;
  • Registry entries;
  • validators;
  • tests;
  • workflows;
  • documentation;
  • Runtime profiles.

34. Projection Validation​

Every projection SHALL undergo objective validation appropriate to the output.

Validation MAY include:

  • schema validation;
  • syntax validation;
  • referential integrity;
  • Registry integrity;
  • graph integrity;
  • semantic constraints;
  • unit compatibility;
  • formula dimensional analysis;
  • rights validation;
  • tenant-isolation validation;
  • security validation;
  • deterministic-build validation;
  • test-fixture execution;
  • migration validation;
  • rollback validation;
  • compatibility validation;
  • Publication validation.

34.1. Validation Receipt​

validation_receipt:
  receipt_id: PP-VR-000001
  projection_id: PP-PRJ-000001
  validator:
    component_id: hecate
    version: 5.0.0
  validation_profile: pp.projection.registry-schema
  status: passed
  findings: []
  validated_at: 2026-08-10T10:01:00Z
  artefact_digests:
    - sha256:...
  provenance: {}

34.2. Validation States​

States MAY include:

  • passed;
  • passed with warnings;
  • failed;
  • blocked;
  • incomplete;
  • expired;
  • revoked;
  • unable to determine.

34.3. Warning Treatment​

Warnings SHALL identify whether they are:

  • informational;
  • non-blocking;
  • conditionally blocking;
  • blocking.

34.4. Validation Expiration​

A receipt SHALL expire where relevant inputs, artefacts, validator versions, conditions or target environments change.

35. HECATE Validation​

HECATE SHALL validate objective structure including:

  • Candidate identity and version;
  • target identity and version;
  • expected current state;
  • operation type;
  • source lineage;
  • Impact Assessment;
  • Dependency Assessment;
  • rights;
  • applicability;
  • Candidate status;
  • Change Decision;
  • Decision Conditions;
  • projection eligibility;
  • pinned inputs;
  • compiler identity;
  • compiler version;
  • configuration digest;
  • artefact digests;
  • schema validity;
  • referential integrity;
  • tenant isolation;
  • Module lineage;
  • Component lineage;
  • rollback package;
  • provenance.

HECATE MAY execute approved deterministic rules and test fixtures.

HECATE SHALL NOT:

  • approve semantic meaning;
  • create a Change Decision;
  • grant rights;
  • waive blocking conditions;
  • decide disputed legal interpretation;
  • approve constitutional evolution;
  • create certification status;
  • release artefacts;
  • activate Runtime state.

36. Test Plan​

High-impact Candidates and projections SHALL possess a Test Plan.

The Test Plan MAY include:

  • unit tests;
  • schema tests;
  • Registry tests;
  • integration tests;
  • graph tests;
  • computation tests;
  • migration tests;
  • backward-compatibility tests;
  • tenant-isolation tests;
  • white-label tests;
  • security tests;
  • performance tests;
  • report tests;
  • Publication tests;
  • rollback tests;
  • historical-replay tests.

36.1. Test Traceability​

Every material test SHOULD link to:

  • Candidate;
  • requirement or invariant;
  • target object;
  • expected result;
  • actual result;
  • artefact version;
  • provenance.

36.2. Test Failure​

A blocking test failure SHALL prevent release.

36.3. Test Data​

Test data SHALL preserve rights, privacy, tenant isolation and provenance.

37. Migration Plan​

A Candidate requiring data or configuration migration SHALL possess a Migration Plan.

The Plan SHALL identify:

  • source version;
  • target version;
  • affected records;
  • transformation Rules;
  • validation;
  • failure handling;
  • idempotency;
  • restartability;
  • duration;
  • maintenance window;
  • rollback;
  • data retention;
  • historical preservation;
  • tenant sequencing;
  • provenance.

37.1. Dry Run​

High-impact migration SHOULD support a dry run or simulation.

37.2. Data Loss​

Potential data loss SHALL be explicit and separately approved.

37.3. Historical Integrity​

Migration SHALL preserve required historical meaning and bitemporal state.

38. Rollback Plan​

Every reversible high-impact change SHALL possess a Rollback Plan.

rollback_plan:
  previous_active_version: 4.2.0
  rollback_artefact_id: PP-GA-000099
  trigger_conditions:
    - critical_validation_failure
    - tenant_isolation_failure
  maximum_rollback_window: PT2H
  data_reconciliation_required: true

The Rollback Plan SHALL identify:

  • prior active state;
  • rollback artefacts;
  • rollback authority;
  • trigger conditions;
  • maximum decision time;
  • data reconciliation;
  • irreversible effects;
  • communication;
  • validation;
  • provenance.

38.1. Non-Reversible Change​

A non-reversible change SHALL identify compensating controls, recovery strategy and enhanced approval.

38.2. Rollback Validation​

Rollback SHOULD be tested before release where feasible.

39. Projection Release​

A Projection Release records that validated artefacts have been made available for use or activation.

projection_release:
  release_id: PP-REL-000001
  projection_id: PP-PRJ-000001
  release_version: 1.0.0
  artefacts:
    - PP-GA-000001
  release_channel: controlled_registry_release
  released_by: actor.example
  released_at: 2026-08-10T12:00:00Z
  activation_status: not_requested
  provenance: {}

39.1. Release Non-Activation​

Release SHALL NOT be interpreted as activation.

39.2. Release Channels​

Channels MAY include:

  • internal preview;
  • review environment;
  • staging;
  • controlled artefact Registry;
  • tenant preview;
  • white-label preview;
  • production release repository;
  • Publication staging.

39.3. Release Authority​

Release authority SHALL be separate from Candidate approval and activation authority for high-impact changes.

39.4. Release Notes​

Material releases SHOULD include:

  • summary;
  • Candidates;
  • Decisions;
  • changed objects;
  • compatibility;
  • migration;
  • known limitations;
  • rollback;
  • affected tenants;
  • provenance.

40. Activation Request​

An Activation Request asks an authorised system or Role to activate released artefacts.

activation_request:
  request_id: PP-AR-000001
  release_id: PP-REL-000001
  target_environment: runtime.production.eu
  requested_scope:
    tenants:
      - tenant.example
  requested_at: 2026-08-11T08:00:00Z
  requested_by: actor.example
  activation_authority_required:
    - runtime-admission-authority
  provenance: {}

40.1. Request Preconditions​

An Activation Request SHOULD identify:

  • released artefact digests;
  • target environment;
  • target current state;
  • requested scope;
  • effective time;
  • migration readiness;
  • monitoring readiness;
  • rollback readiness;
  • approvals;
  • provenance.

40.2. Request Non-Authority​

An Activation Request SHALL NOT activate anything by itself.

41. Activation Record​

An Activation Record SHALL preserve:

  • Activation Identifier;
  • Activation Request;
  • Release;
  • artefact digests;
  • activating authority;
  • target environment;
  • tenant and white-label scope;
  • previous active state;
  • new active state;
  • effective time;
  • monitoring;
  • rollback window;
  • result;
  • provenance.

Activation outcomes MAY include:

  • active;
  • partially active;
  • failed;
  • suspended;
  • rolled back;
  • retired.

41.1. Runtime Admission​

Runtime Admission SHALL verify that released artefacts match approved digests and target scope.

41.2. Partial Activation​

Partial activation SHALL identify exact successful and failed scopes.

41.3. Activation Drift​

Any difference between released and activated artefacts SHALL create an Incident and block trust.

42. Controlled Rollout​

Activation MAY use:

  • canary deployment;
  • tenant cohort deployment;
  • white-label cohort deployment;
  • jurisdictional rollout;
  • feature flag;
  • shadow mode;
  • read-only mode;
  • staged Registry activation;
  • blue-green deployment;
  • scheduled cutover.

42.1. Cohort Definition​

Every cohort SHALL be explicit and reproducible.

42.2. Promotion Criteria​

Promotion to a broader cohort SHALL require defined success criteria.

42.3. Automatic Promotion​

Automatic promotion MAY occur only where:

  • criteria are objective;
  • authority permits it;
  • rollback is ready;
  • monitoring is active;
  • no blocking Incident exists;
  • provenance is preserved.

42.4. Automatic Rollback​

Automatic rollback MAY occur only through approved triggers and authority.

43. Post-Activation Monitoring​

Material activations SHALL define monitoring.

Monitoring MAY include:

  • validation errors;
  • schema failures;
  • Registry integrity;
  • Runtime exceptions;
  • data-quality changes;
  • computation variance;
  • tenant failures;
  • white-label failures;
  • Publication differences;
  • performance;
  • security;
  • rights exposure;
  • user-reported issues;
  • certification impact.

43.1. Baseline​

Monitoring SHOULD compare against an identified baseline.

43.2. Thresholds​

Alert and rollback thresholds SHALL be explicit.

43.3. Observation Period​

The observation period SHALL be appropriate to impact and usage frequency.

43.4. Monitoring Non-Authority​

Successful monitoring SHALL not retroactively approve an unauthorised activation.

44. Rollback Record​

A Rollback Record SHALL identify:

  • Rollback Identifier;
  • triggering Incident or Decision;
  • active state before rollback;
  • target restored state;
  • artefacts used;
  • authority;
  • affected tenants;
  • affected white-label operators;
  • data reconciliation;
  • time;
  • validation;
  • outcome;
  • provenance.

Rollback SHALL not erase the activation or Incident history.

44.1. Roll-Forward​

Where rollback is unsafe, a governed roll-forward Candidate MAY be required.

44.2. Partial Rollback​

Partial rollback SHALL identify exact scope and compatibility impact.

45. Projection Withdrawal​

A projection or release MAY be withdrawn because of:

  • invalid source knowledge;
  • revoked rights;
  • Decision revocation;
  • validation defect;
  • security vulnerability;
  • tenant leakage;
  • incorrect artefact;
  • compiler defect;
  • source or target supersession;
  • constitutional conflict;
  • Publication correction;
  • certification impact.

A Projection Withdrawal SHALL identify:

  • projection or release;
  • reason;
  • authority;
  • affected artefacts;
  • affected activations;
  • affected tenants;
  • affected Publications;
  • required rollback or retirement;
  • effective time;
  • provenance.

46. Change Incident​

Change Incidents MAY include:

  • unauthorised Candidate projection;
  • projection without Decision;
  • expired Decision use;
  • target drift;
  • non-deterministic output;
  • digest mismatch;
  • validation bypass;
  • rights violation;
  • cross-tenant leakage;
  • wrong artefact activation;
  • partial migration failure;
  • rollback failure;
  • historical-lineage loss;
  • compiler compromise;
  • supply-chain compromise;
  • unauthorised Publication;
  • certification misstatement.

Every Incident SHALL identify:

  • Incident Identifier;
  • severity;
  • affected Candidates;
  • affected Decisions;
  • affected projections;
  • affected artefacts;
  • affected activations;
  • affected tenants;
  • affected white-label operators;
  • detection;
  • containment;
  • correction;
  • rollback;
  • notification;
  • root cause;
  • remediation;
  • provenance.

46.1. Incident Severity​

Severity MAY be:

  • informational;
  • low;
  • moderate;
  • high;
  • critical;
  • constitutional.

46.2. Evidence Preservation​

Incident response SHALL preserve relevant evidence and chain of custody.

47. Tenant and White-Label Governance​

Candidate, projection, release and activation scope SHALL remain tenant- and white-label-aware.

47.1. Tenant Overlay​

A tenant overlay SHALL preserve:

  • base canonical version;
  • tenant-specific change;
  • contractual basis;
  • rights;
  • approval;
  • compatibility;
  • migration;
  • rollback;
  • provenance.

47.2. White-Label Overlay​

A white-label overlay SHALL preserve operator identity, branding scope, functional differences, contractual boundaries and isolation.

47.3. Global Change Impact​

A global Candidate SHALL assess:

  • tenant overrides;
  • white-label overrides;
  • incompatible configurations;
  • contractual commitments;
  • communication;
  • migration sequencing;
  • opt-in or opt-out rights.

47.4. Cross-Tenant Prohibition​

A Candidate or projection SHALL NOT reference another tenant's restricted objects, data, prompts, configurations or Findings.

47.5. Tenant Promotion​

A tenant-derived Candidate SHALL require explicit approval before promotion to global canonical state.

48. Communication and Stakeholder Treatment​

High-impact change SHOULD include a communication plan.

The plan MAY identify:

  • affected internal Roles;
  • tenants;
  • white-label operators;
  • partners;
  • auditors;
  • Certification Bodies;
  • regulators;
  • public users;
  • timing;
  • message;
  • required actions;
  • support;
  • provenance.

Communication SHALL distinguish proposed, approved, released and active state.

49. Publication and Reporting Boundary​

A Change Candidate or projection MAY affect reports, disclosures, public claims or verification pages.

Publication treatment SHALL follow ZYZ-CPF and PP-RLCPS.

A generated report template or disclosure mapping SHALL NOT be published merely because projection validation passes.

A public claim SHALL preserve:

  • source evidence;
  • authority;
  • rights;
  • applicable version;
  • approval;
  • release;
  • Publication status;
  • correction and withdrawal path.

50. Certification and Assurance Boundary​

A Candidate affecting certification or assurance SHALL identify:

  • scheme;
  • criterion;
  • test;
  • evidence;
  • decision rule;
  • Certification Body impact;
  • Accreditation Body impact;
  • certificate validity;
  • transition period;
  • affected certified entities.

A projection SHALL NOT create certification status or alter certificate validity without authorised certification processes.

51. Computation and Financial Impact Boundary​

Candidates affecting formulas, factors, scenarios or financial impact SHALL identify:

  • model;
  • model version;
  • variables;
  • units;
  • assumptions;
  • uncertainty;
  • validation;
  • affected calculations;
  • affected reports;
  • affected historical comparability;
  • restatement requirements;
  • rollback or recalculation plan.

A projected formula SHALL NOT become active Computation Hub logic without separate admission and activation.

52. Security​

Change and projection systems SHALL enforce:

  • authentication;
  • authorisation;
  • least privilege;
  • separation of duties;
  • tenant isolation;
  • white-label isolation;
  • encryption;
  • signing;
  • digest verification;
  • secrets management;
  • tamper evidence;
  • build isolation;
  • dependency integrity;
  • access logging;
  • Incident response;
  • backup;
  • recovery.

52.1. Candidate Integrity​

Candidate payloads SHOULD be digest-protected.

52.2. Decision Integrity​

High-impact Decisions SHOULD be signed or protected by verifiable approval receipts.

52.3. Artefact Integrity​

Released and activated artefact digests SHALL match.

52.4. Supply-Chain Security​

Compiler and generator dependencies SHALL be pinned, verified and monitored.

52.5. Privileged Operations​

Release, activation, rollback and withdrawal SHALL be privileged operations.

53. AI Agent Boundaries​

AI Agents MAY:

  • identify change signals;
  • classify differences;
  • draft Candidates;
  • propose impact;
  • propose dependencies;
  • identify conflicts;
  • generate draft migration plans;
  • generate draft tests;
  • support compiler input preparation;
  • analyse validation Findings;
  • propose rollback actions.

AI Agents SHALL NOT independently:

  • approve a Candidate;
  • issue a Change Decision;
  • waive Decision Conditions;
  • grant rights;
  • determine disputed legal meaning;
  • approve constitutional evolution;
  • release artefacts;
  • activate Runtime state;
  • conceal Findings;
  • alter historical records.

Every Agent action SHALL preserve:

  • Agent identity;
  • Agent Profile;
  • model;
  • model version;
  • prompt Profile;
  • tools;
  • retrieved objects;
  • output;
  • confidence;
  • human review state;
  • provenance.

54. Change Quality and Operational Metrics​

Metrics MAY include:

  • detection-to-Candidate time;
  • Candidate review time;
  • Decision time;
  • projection success rate;
  • deterministic-build rate;
  • validation failure rate;
  • rollback rate;
  • target-drift rate;
  • stale-Candidate rate;
  • unresolved-conflict rate;
  • tenant-impact rate;
  • Incident rate;
  • historical-reconstruction completeness.

Metrics SHALL NOT:

  • create authority;
  • auto-approve Candidates;
  • suppress low-frequency critical risk;
  • replace competent review.

55. Staleness and Expiration​

A Candidate, Decision, projection or validation receipt MAY become stale where:

  • source knowledge changes;
  • target version changes;
  • rights change;
  • applicability changes;
  • review expires;
  • Decision expires;
  • compiler changes;
  • validation profile changes;
  • dependencies change;
  • conflict emerges;
  • security vulnerability appears.

Stale objects SHALL be classified and re-evaluated before use.

56. Module and Component Lineage​

Every material change path SHALL preserve:

  • accountable Module;
  • source Components;
  • Change Intelligence Component;
  • Candidate Registry Component;
  • target-owning Component;
  • review workflow Components;
  • Decision authority;
  • Constitutional Compiler;
  • generator Components;
  • HECATE;
  • release Component;
  • activation Component;
  • Runtime-consuming Components;
  • Publication-consuming Components;
  • archive Component;
  • affected Modules;
  • affected Components;
  • tenant lineage;
  • white-label lineage.

Pergamum Pulse SHALL preserve both Module and Component lineage.

No orphan Component lineage is permitted.

57. Provenance​

Change and projection provenance SHALL connect:

  • Source Objects;
  • Source Captures;
  • Rights Records;
  • Knowledge Documents;
  • Source Fragments;
  • Knowledge Assertions;
  • Knowledge Entities;
  • Mapping Objects;
  • Crosswalk Sets;
  • Detection Events;
  • Difference Records;
  • Impact Assessments;
  • Dependency Assessments;
  • Candidates;
  • Candidate Packages;
  • Candidate Conflicts;
  • Reviews;
  • Change Decisions;
  • Decision Conditions;
  • projection-eligibility receipts;
  • Projection Manifests;
  • compiler executions;
  • generated artefacts;
  • validation receipts;
  • releases;
  • Activation Requests;
  • Activation Records;
  • monitoring;
  • rollbacks;
  • withdrawals;
  • incidents;
  • Module lineage;
  • Component lineage;
  • tenant lineage;
  • white-label lineage;
  • valid time;
  • transaction time.

Materially incomplete provenance SHALL block:

  • projection eligibility;
  • authoritative release;
  • activation;
  • unqualified Publication;
  • certification reliance;
  • definitive historical claims.

58. Historical Reconstruction​

Historical reconstruction SHALL answer:

  • what change was detected;
  • which old and new states were compared;
  • which source knowledge supported the Candidate;
  • which Candidate version was reviewed;
  • which target version was expected;
  • which impact and dependencies were identified;
  • which conflicts existed;
  • which reviewers participated;
  • which Decision was issued;
  • which conditions applied;
  • which compiler version executed;
  • which inputs and configuration were pinned;
  • which artefacts were generated;
  • which validation receipts passed;
  • which release occurred;
  • which activation occurred;
  • which tenant or white-label scope was active;
  • whether rollback, withdrawal or Incident followed;
  • what state was active at a target time.

58.1. Exact Replay​

Exact Replay SHALL reconstruct the projection using the exact historical:

  • Candidate;
  • Decision;
  • input snapshot;
  • compiler;
  • configuration;
  • environment;
  • dependencies;
  • templates;
  • Rights Records;
  • validation Profiles.

58.2. Semantic Replay​

Semantic Replay MAY evaluate a historical Candidate under later approved rules.

Exact Replay and Semantic Replay SHALL remain distinct.

58.3. Build Reproduction​

Where deterministic reproduction is expected, a digest mismatch SHALL create a Finding or Incident.

58.4. Non-Retroactivity​

Current Decisions, compilers, schemas, rights or activation rules SHALL NOT be silently applied to historical projections.

59. Conformance Levels​

59.1. Level 1 — Candidate-Identifiable​

The Candidate has:

  • stable identity;
  • version;
  • source basis;
  • target;
  • proposed operation;
  • basic provenance.

59.2. Level 2 — Decision-Governed​

It additionally has:

  • impact assessment;
  • dependency assessment;
  • authority;
  • rights;
  • applicability;
  • risk;
  • review;
  • Change Decision;
  • conditions;
  • conflict treatment.

59.3. Level 3 — Projection-Ready​

It additionally has:

  • projection eligibility receipt;
  • pinned inputs;
  • approved compiler;
  • deterministic configuration;
  • test plan;
  • migration and rollback treatment;
  • no blocking Findings;
  • HECATE validation readiness.

59.4. Level 4 — Historically Assured​

It additionally has:

  • immutable Projection Manifest;
  • generated artefact digests;
  • validation receipts;
  • release and activation separation;
  • monitoring;
  • rollback evidence;
  • Incident treatment;
  • Exact Replay;
  • Module and Component lineage;
  • complete historical provenance.

Level 4 SHALL NOT imply that activation occurred.

60. Conformance Fixtures​

Implementations SHOULD provide fixtures for:

  • editorial Change Detection Event;
  • semantic Difference Record;
  • rights Difference Record;
  • false-positive detection;
  • valid create Candidate;
  • valid replace Candidate;
  • valid deprecate Candidate;
  • valid merge Candidate;
  • invalid destructive Candidate without rollback;
  • Candidate without source basis;
  • AI-generated hypothesis Candidate;
  • Candidate with pinned target version;
  • Candidate with target-digest mismatch;
  • no-op Candidate;
  • JSON Patch Candidate;
  • Candidate containing an unrelated hidden change;
  • Candidate containing a secret;
  • complete rationale;
  • incomplete rationale;
  • low-impact assessment;
  • constitutional-impact assessment;
  • unknown-impact Candidate;
  • dependency graph;
  • cyclic dependency;
  • unresolved blocking dependency;
  • moderate-risk Candidate;
  • critical-risk Candidate;
  • Candidate with rights restriction;
  • Candidate with external-processing prohibition;
  • tenant-scoped Candidate;
  • unauthorised global promotion;
  • separate Candidate status dimensions;
  • complete Candidate Review;
  • reviewer conflict of interest;
  • conflicting Candidates;
  • Candidate Package with all-or-nothing atomicity;
  • partial Package approval;
  • approved Change Decision;
  • conditional Change Decision;
  • rejected Candidate;
  • expired Decision;
  • revoked Decision;
  • unsatisfied blocking condition;
  • successful Projection Eligibility Gate;
  • target drift at eligibility;
  • complete Projection Manifest;
  • Manifest with unpinned external input;
  • deterministic compiler execution;
  • non-deterministic output;
  • compiler dependency-integrity failure;
  • Generated Artefact;
  • unsigned critical artefact;
  • atomic multi-artefact projection;
  • cross-artefact inconsistency;
  • passed Validation Receipt;
  • expired Validation Receipt;
  • HECATE structural failure;
  • complete Test Plan;
  • blocking test failure;
  • Migration Plan dry run;
  • migration with unapproved data loss;
  • valid Rollback Plan;
  • non-reversible change with compensating controls;
  • Projection Release;
  • release incorrectly treated as activation;
  • Activation Request;
  • Activation Record with matching digest;
  • activation digest mismatch;
  • canary rollout;
  • failed cohort promotion;
  • automatic rollback;
  • post-activation monitoring;
  • complete Rollback Record;
  • partial rollback;
  • Projection Withdrawal;
  • Change Incident;
  • tenant overlay;
  • white-label overlay;
  • global Candidate with override conflicts;
  • Publication-impact Candidate;
  • certification-impact Candidate;
  • computation-impact Candidate;
  • Agent-drafted Candidate;
  • AI Agent attempting Decision;
  • stale Candidate;
  • stale projection;
  • complete Module lineage;
  • complete Component lineage;
  • materially incomplete provenance;
  • Exact Replay with matching digest;
  • Exact Replay with digest mismatch;
  • Semantic Replay;
  • historical active-state reconstruction.

61. Migration and Compatibility​

Specification revisions SHALL identify:

  • source specification version;
  • target specification version;
  • changed Candidate fields;
  • changed operation types;
  • changed Decision states;
  • changed condition types;
  • changed Projection Manifest fields;
  • changed artefact types;
  • changed validation Profiles;
  • migration rules;
  • compatibility;
  • affected Candidates;
  • affected Decisions;
  • affected projections;
  • affected releases;
  • affected activations;
  • validation;
  • provenance.

Migration SHALL NOT:

  • reuse object identifiers;
  • overwrite historical Candidates or Decisions;
  • infer approval;
  • infer rights;
  • infer applicability;
  • infer satisfied conditions;
  • convert unresolved impact to no impact;
  • conceal Candidate conflicts;
  • alter artefact digests;
  • treat release as activation;
  • activate projected output.

61.1. Legacy Projection Import​

A legacy generated artefact MAY be imported only with:

  • source identification;
  • best-available Decision lineage;
  • compiler or generator information;
  • digest;
  • validation;
  • authority;
  • limitations;
  • historical classification;
  • provenance.

An imported legacy artefact SHALL not be represented as fully conformant without evidence.

62. Assurance and Audit​

Change and projection assurance MAY evaluate:

  • source traceability;
  • Candidate completeness;
  • impact accuracy;
  • dependency completeness;
  • risk classification;
  • review competence;
  • Decision authority;
  • condition satisfaction;
  • input pinning;
  • deterministic generation;
  • artefact integrity;
  • validation;
  • release controls;
  • activation separation;
  • rollback readiness;
  • tenant isolation;
  • Incident response;
  • historical reconstruction.

An audit record SHALL identify:

  • audit identity;
  • scope;
  • criteria;
  • auditor;
  • independence;
  • sample;
  • evidence;
  • Findings;
  • conclusion;
  • remediation;
  • provenance.

63. Conformance Requirements​

An implementation conforms to this specification where it:

  1. represents detected change as governed Change Detection Events;
  2. distinguishes Detection Events from Candidates;
  3. preserves old and new state in Difference Records;
  4. classifies structural, semantic, rights, applicability and constitutional differences separately;
  5. prevents text change from automatically establishing semantic change;
  6. assigns stable PP-CC- identifiers to Candidates;
  7. prevents Candidate identifier reuse;
  8. preserves independent Candidate versions;
  9. preserves immutable completed Candidate versions;
  10. links Candidates to governed source basis;
  11. distinguishes source-mandated change from design proposal or hypothesis;
  12. propagates source withdrawal to dependent Candidates;
  13. pins target identity and version;
  14. identifies canonical versus derived target state;
  15. preserves target Module and Component ownership;
  16. fails invalid non-create Candidates with missing targets;
  17. represents proposed operations explicitly;
  18. preserves expected current state;
  19. supports compare-and-set protection;
  20. governs destructive operations;
  21. identifies no-op Candidates;
  22. preserves complete payloads or reproducible patches;
  23. prevents unrelated hidden changes;
  24. prevents secrets from entering Candidate payloads;
  25. requires human-readable rationale;
  26. distinguishes source requirements, expert interpretation, architecture judgement and AI recommendations;
  27. requires material Impact Assessments;
  28. evaluates constitutional, Registry, schema, computation, workflow, Runtime, tenant, Publication, certification, security, rights and historical impacts;
  29. represents unknown impact explicitly;
  30. requires Dependency Assessments;
  31. detects dependency cycles;
  32. respects dependency order;
  33. blocks unresolved mandatory dependencies;
  34. represents multidimensional risk;
  35. governs residual-risk acceptance;
  36. separates source authority from Candidate approval authority;
  37. routes constitutional-impacting change to constitutional governance;
  38. prevents Runtime authority before activation;
  39. preserves rights across Candidate and projection processing;
  40. blocks prohibited external processing;
  41. propagates rights expiration and revocation;
  42. represents Candidate applicability and scope explicitly;
  43. prevents tenant-specific Candidates from silently becoming global;
  44. governs scope promotion;
  45. separates detection, analysis, review, Decision, projection, release and activation status;
  46. requires risk-appropriate review;
  47. preserves reviewer competence;
  48. enforces separation of duties for high-impact change;
  49. preserves Candidate conflicts as first-class objects;
  50. prevents automated silent conflict selection;
  51. governs Candidate Packages;
  52. preserves member Candidate identity, authority, rights and Decision;
  53. governs Package atomicity;
  54. represents Change Decisions as separate objects;
  55. pins Decisions to Candidate versions and payloads;
  56. preserves Decision authority and signatures where required;
  57. preserves immutable Decisions;
  58. prevents expired or revoked Decisions from authorising new projection;
  59. represents Decision Conditions as enforceable objects;
  60. blocks according to unsatisfied blocking conditions;
  61. requires a Projection Eligibility Gate;
  62. prevents eligibility from implying release or activation;
  63. produces eligibility receipts;
  64. represents Projection Manifests as immutable governed objects;
  65. pins all material projection inputs and digests;
  66. prohibits unpinned mutable production inputs;
  67. records compiler identity, version, configuration and environment;
  68. preserves the Constitutional Compiler authority boundary;
  69. requires deterministic generation where feasible;
  70. discloses non-determinism;
  71. governs external generators;
  72. records Compiler Executions;
  73. isolates build environments;
  74. pins and verifies build dependencies;
  75. supports SBOMs for material builds;
  76. represents generated outputs as first-class artefacts;
  77. preserves artefact identity, media type, path, digest, rights, scope and provenance;
  78. distinguishes preview, projection, release and active artefacts;
  79. preserves immutable released artefacts;
  80. supports signing of high-impact artefacts;
  81. governs multi-artefact projection and atomicity;
  82. validates cross-artefact consistency;
  83. performs output-appropriate validation;
  84. produces Validation Receipts;
  85. classifies validation warnings;
  86. expires validation after material input or environment change;
  87. validates objective structure through HECATE;
  88. prevents HECATE from approving meaning, rights, release or activation;
  89. requires Test Plans for high-impact change;
  90. links tests to Candidates, invariants and artefacts;
  91. blocks release on blocking test failure;
  92. governs test-data rights and tenant isolation;
  93. requires Migration Plans where migration is needed;
  94. supports dry runs for high-impact migration;
  95. separately approves potential data loss;
  96. preserves bitemporal and historical integrity during migration;
  97. requires Rollback Plans for reversible high-impact change;
  98. governs non-reversible changes with compensating controls;
  99. validates rollback where feasible;
  100. represents Projection Releases separately from projections and activation;
  101. prevents release from being interpreted as activation;
  102. preserves release authority and notes;
  103. represents Activation Requests separately;
  104. prevents Activation Requests from creating active state;
  105. records Activation authority, scope, previous state, new state and provenance;
  106. verifies released and activated artefact digests;
  107. treats activation drift as an Incident;
  108. governs controlled rollout and cohorts;
  109. defines promotion and rollback criteria;
  110. monitors material activations;
  111. preserves monitoring baselines and thresholds;
  112. records rollback without deleting activation history;
  113. governs partial rollback and roll-forward;
  114. governs projection withdrawal;
  115. manages Change Incidents and preserves evidence;
  116. preserves tenant and white-label overlays;
  117. prevents cross-tenant references and leakage;
  118. assesses global change against tenant and white-label overrides;
  119. distinguishes proposed, approved, released and active states in communications;
  120. applies Publication governance to report and public-claim outputs;
  121. prevents projection from creating certification status;
  122. prevents projected formulas from becoming active computation without admission and activation;
  123. enforces security, signing, digest verification and privileged operations;
  124. prevents AI Agents from issuing Decisions, releasing or activating;
  125. measures change quality without creating authority;
  126. detects stale Candidates, Decisions, projections and receipts;
  127. preserves both Module and Component lineage;
  128. preserves complete end-to-end provenance;
  129. blocks critical actions where provenance is materially incomplete;
  130. supports historical reconstruction of Candidate, Decision, projection, release and activation state;
  131. supports Exact Replay;
  132. distinguishes Exact Replay from Semantic Replay;
  133. detects reproducibility digest mismatch;
  134. prevents retroactive application of current governance to historical projections;
  135. defines four conformance levels;
  136. supports conformance fixtures;
  137. governs migration and legacy import;
  138. supports assurance and audit;
  139. preserves tenant isolation, security, resilience and historical trust;
  140. never treats a generated artefact as active without a separate authorised Activation Record.

64. Foundational Principle​

Pergamum Pulse SHALL turn knowledge change into controlled possibility, not silent system mutation.

A detected difference is not yet an interpreted change. An interpreted change is not yet a Candidate. A Candidate is not a Decision. A Decision is not a Projection Manifest. A generated artefact is not a release. A release is not activation. Activation is not permanent truth.

Every step SHALL preserve identity, authority, rights, scope, impact, dependency, review, conditions, digests, Module lineage, Component lineage and provenance.

The compiler may generate. HECATE may validate. Reviewers may assess. Decision authorities may approve. Release authorities may release. Runtime authorities may activate. None of these roles SHALL silently absorb the authority of another.

By separating detection, analysis, proposal, Decision, projection, validation, release, activation, monitoring and rollback, Pergamum Pulse enables ZAYAZ to evolve continuously while preserving constitutional control, deterministic implementation, tenant isolation, legal defensibility, operational safety and complete historical trust.



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