Pergamum Pulse Change Candidate and Projection Specification

Version 0.2 — Assessment-First Proposal, Decision and Projection Contract

Version 0.2 reconciles Stage 7.14B assessment semantics with the Stage 7.15 Candidate boundary. It is a contract review baseline, not evidence that Stage 7.14B is implemented or deployed. The existing Core 1.0 schemas, loader and migration 009 still use the candidate-bound model; their coordinated successor work is specified in §61.2. PP-GOCF's entry and proof requirements remain mandatory before capability implementation and closure.

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.

3.1. Stage 7.14B Assessment Direction and Authority

The initial Stage 7.14B operational profile SHALL assess the exact Requirement Target-State Reconciliation evidence produced in Stage 7.13. Other detection sources in §5.1 require their own reviewed input and capability-proof coverage before admission to this profile.

The prerequisite direction SHALL be:

Exact PP-CDE / PP-DIF evidence and retained assessment scope
                      → PP-IA and PP-DA
                      → PP-CC referencing those assessment versions

An initial assessment SHALL NOT require an existing, placeholder or preallocated Change Candidate. Its subject is the observed change and explicitly retained scope, not a future Candidate identity. PP-IA and PP-DA SHALL be independently persistable from that evidence; neither requires the other to exist. Stage 7.15 SHALL select a compatible pair under §8.4, not infer compatibility from matching source IDs alone.

All seven PP-GOCF authority dimensions SHALL remain false for both assessments: Requirement Registry, change, projection, release, Runtime, Publication and recovery. Neither a favourable severity nor an empty blocker list grants authority. Approval remains Stage 7.16; projection eligibility, release and activation retain their separate later gates.

The Core 1.0 reverse Candidate references are a legacy persistence constraint, not an exception to this direction. §61.2 defines the adoption boundary; this specification revision alone does not enable the new profile.

4. Canonical Change and Projection Objects

Object	Prefix	Purpose
Change Detection Event	`PP-CDE-`	Records detected structural, semantic or rights change
Difference Record	`PP-DIF-`	Preserves old/new values and classified difference
Impact Assessment	`PP-IA-`	Records affected objects, systems and stakeholders
Dependency Assessment	`PP-DA-`	Records upstream and downstream dependencies
Change Candidate	`PP-CC-`	Represents one governed proposed change
Candidate Package	`PP-CCP-`	Groups Candidates for coordinated review or release
Candidate Conflict	`PP-CCF-`	Records incompatible or competing Candidates
Candidate Review	`PP-CRV-`	Records review of a Candidate or Package
Change Decision	`PP-CD-`	Records approval, rejection or conditional treatment
Decision Condition	`PP-DCO-`	Records an enforceable approval condition
Projection Manifest	`PP-PRJ-`	Records projection inputs, outputs and lineage
Compiler Execution	`PP-CEX-`	Records one compiler or generator execution
Generated Artefact	`PP-GA-`	Identifies one generated output
Validation Receipt	`PP-VR-`	Records deterministic validation results
Projection Release	`PP-REL-`	Records release of validated artefacts
Activation Request	`PP-AR-`	Requests separate activation
Activation Record	`PP-ACT-`	Records authorised activation
Rollback Record	`PP-RBK-`	Records reversal to a prior active state
Projection Withdrawal	`PP-PWD-`	Records withdrawal of a projection or release
Change Incident	`PP-CIN-`	Records a change or projection incident
Historical Change Record	`PP-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

This conceptual example illustrates the direction of references; it is not a complete loader payload. Exact source and assessment versions remain required.

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:
      - object_id: PP-CDE-000001
        version: 1.0.0
    differences:
      - object_id: PP-DIF-000001
        version: 1.0.0
    assertions:
      - object_id: PP-KA-000101
        version: 1.0.0
    mappings:
      - object_id: PP-MAP-000201
        version: 1.0.0

  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:
    object_id: PP-IA-000001
    version: 1.0.0
  dependency_assessment:
    object_id: PP-DA-000001
    version: 1.0.0

  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.

8.3. Assessment Consumption at Stage 7.15

A Candidate SHALL reference exact PP-IA and PP-DA versions, satisfy §8.4's pair predicate and demonstrate that their source evidence, target scope, tenant/applicability scope, rights and retained assumptions cover its proposed operation. Shared source IDs alone do not establish that coverage. The mapping and any exclusions SHALL be retained for review. Candidate admission SHALL rederive §15.9's mandatory evidence roles from the sealed Stage 7.13 bindings and recheck both assessments' current eligibility at one serialized admission coordinate; a previously accepted assessment or caller-supplied historical label cannot waive that check.

An operation or target outside that coverage requires new assessment versions before the Candidate can claim completed analysis. Candidate synthesis MAY preserve explicit unresolved findings for review; it SHALL NOT remove them, turn them into low risk, or satisfy a later eligibility gate merely by creating a proposal. Unknown-impact treatment remains governed by §15.4 and §17; unresolved blocking dependencies remain subject to §16.4.

Later Candidate references SHALL NOT be written back into an existing assessment. A material assessment correction creates a governed successor/version with lineage; a Candidate using it also creates a new version. No same-version circular reference is permitted.

8.4. Assessment-Pair Compatibility

Each independently created assessment SHALL retain a complete shared analysis context. It is immutable input data within each assessment's hash domain, not a new authority-bearing object or a prerequisite for creating the other assessment. Its analytical valid-time/transaction-time coordinates describe the world being assessed; they are distinct from the live eligibility checks required by §15.9. Both members may therefore be produced at different times against the same frozen context without backdating their processing or admission checks.

For the initial profile, a compatible pair requires exact equality of the following shared inputs after the reviewed canonicalisation and declared set ordering. A digest is an integrity check, not a substitute for resolving and comparing the required content.

Shared input	Required equality
Detection and source closure	Exact PP-CDE identity/version/digest, complete PP-DIF set, Stage 7.13 before/after Requirement bindings, admission-decision lineage, continuity relationship and derived evidence roles.
Scope and assumptions	Exact assessed targets/versions or evidenced absence, comparison boundaries, intended change-analysis purpose, considered operations and their preconditions, tenant/applicability/white-label scope, exclusions and governing assumptions. Complementary impact/dependency responsibilities do not permit different operation assumptions.
Analytical time and graph	Exact analytical valid-time/transaction snapshot coordinates, retained graph snapshot identity/digest, roots, relationship coverage, exclusions and truncation policy. Different graph projections must be traceable to that same frozen graph; a fresh live query cannot stand in for it.
Governing policies	One exact shared policy/configuration inventory with versions/digests covering lifecycle eligibility, rights-use constraints, impact/severity, dependency traversal/order and compatibility. It contains both role-specific policy bindings; the impact and dependency algorithms need not be identical.
Common supporting evidence	Exact versions/digests of every input used by both members, with the same analytical interpretation and temporal coordinate. Additional role-specific evidence must be retained and may add findings, but cannot override a shared assumption or contradict the other member's material conclusions without resolution.

The pair SHALL also have no unresolved contradiction between its material findings, assumptions or dependency treatment. A shared explicit unknown may remain for Candidate review under §8.3, but a known disagreement cannot be disguised as an unknown, removed from one member or resolved by selecting the more favourable result. Exact per-member identity, author, method, processing/provider Rights Decisions, creation anchors and admission-attempt records are expected to differ; each must independently validate, and the later Candidate's intended use must satisfy the combined rights conditions. Different wall-clock admission times alone do not invalidate a pair with the same analytical context.

Any shared-input mismatch, missing comparison evidence or material contradiction withholds Candidate consumption of that pair. This initial profile has no ad hoc reconciliation override: create governed successor assessment versions against a single reconciled context and preserve the old versions. A current source/graph/policy change affecting the covered operation likewise requires reassessment; a fresh eligibility pass cannot silently update frozen analysis. Stage 7.15 SHALL retain the exact pair references, comparison inputs, per-dimension result and current-use checks as Candidate provenance. It cannot use an incompatible pair even to claim completed analysis in a proposal-only Candidate.

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 reference an Impact Assessment that covers its proposed change. Under Stage 7.14B, the assessment is created first from the evidence and scope in §15.6.

The following conceptual example illustrates the assessment subject; it is not a Core 1.0 loader payload. Exact field serialization and schema selection must be bound in the successor contract described in §61.2.

impact_assessment:
  assessment_id: PP-IA-000001

  detection_event:
    object_id: PP-CDE-000001
    version: 1.0.0
  differences:
    - object_id: PP-DIF-000001
      version: 1.0.0

  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.

15.6. Shared Stage 7.14B Assessment Contract

The PP-IA and PP-DA Governed-Object Contracts SHALL each bind the following requirements before implementation. These are capability requirements for PP-GOCF; they do not register new contract IDs, executors or proof receipts by themselves.

Dimension	Required contract behaviour
Identity	Preserve the registered `impact_assessment` / `PP-IA-` and `dependency_assessment` / `PP-DA-` identities, exact versions and historical resolution.
Subject evidence	Pin one persisted Stage 7.13 detection event and its complete, nonempty persisted difference set by exact identity/version and verified content digest. Every difference must belong to that event; missing, extra, duplicated, substituted or mismatched versions fail admission. A no-change Stage 7.13 result creates no synthetic change event or assessment.
Assessed scope	Retain the affected target identities/versions, comparison boundaries, tenant and applicability scope, assessment purpose, considered operation assumptions, exclusions and their rationale. For a target not yet created, retain its proposed identity and evidenced absence within a pinned parent/scope; never fabricate a persisted version. The scope cannot be wider than the permitted evidence scope.
Supporting inputs	Retain the graph snapshot, evidence and policy/ruleset versions and digests needed for each conclusion, including the shared analysis context in §8.4. Mutable URLs, current Registry heads or an unretained live query do not establish historical evidence.
Authority	Use the assessment-only authority class, forbid inherited object-version authority and prove all seven authority dimensions false. Assessment storage does not change Requirement Registry membership or later-stage state.
Provenance	Retain the author/reviewer identity, recorded time, method/version, source linkage, scope and content digest. Pin the operation-specific Rights Records/Decision and Rights Gate evidence in §15.8 and the lifecycle policy, derived input roles, transition evidence and temporal coordinates in §15.9. Creation evidence belongs to the assessment digest; post-anchor admission evidence belongs to the separately bound attempt record in §15.10. Retaining a state does not establish permission or eligibility.
Replay	Initial assessment conclusions use RECORDED semantics with a verified creation-time DAL anchor and immutable replay manifest under §15.10. Structural validation and dependency traversal/order checks are deterministic and tested with EXACT comparisons. Executor contracts SHALL distinguish those responsibilities; a fresh AI response cannot substitute for historical assessment evidence.
Persistence	Reuse the existing assessment and reference relations through a reviewed forward migration. Persist common identity/version, typed payload and normalized references atomically; same identity/version with different content fails, identical retries are idempotent, and supersession preserves old payloads.
Serialization	Pin the source/graph snapshot and the eligibility evidence from each required processing/admission check in the appropriate assessment or attempt hash domain under §15.10. Final admission SHALL validate the required rights and lifecycle state consistently with persistence, including changes since processing began. Prove the chosen isolation/locking rule against concurrent source, rights, lifecycle, scope and graph changes and time-based expiry; do not copy Stage 7.13 topology locks without a demonstrated need.
TrustGate	Declare whether admission uses the existing governed transaction/callback path and its exact subject coverage. If required, it SHALL be enforced for every write path; a generic loader success cannot substitute for that proof.
Proof binding	Pin the PP-GOCF framework/ruleset and the exact reviewed schema, persistence, implementation and executor subjects. Supply assessment-specific proofs from §60.1; Stage 7.13 attestations cannot be relabelled as assessment coverage.

The initial operational capability validates and records supplied, evidence-backed assessments. It SHALL NOT invent materiality thresholds, risk weights, impact categories or graph completeness. Governed policy and competent review supply semantic judgments; missing policy or evidence remains explicit and prevents a claim of completed analysis. Open findings may be persisted as findings without granting downstream eligibility.

15.7. Impact Coverage and Unknowns

Each dimension in §15.1 SHALL have a supported finding, an explicit unresolved finding, or an evidenced applicability exclusion. An omitted dimension, unexamined target or missing graph relation SHALL NOT be interpreted as none. The assessment SHALL distinguish observed effects, expected benefits, adverse consequences and assumptions about a possible operation.

Severity and risk SHALL identify their governing policy/version and evidence; no numerical cut-off or aggregation formula is introduced by this stage. A conclusion of no material impact requires affirmative coverage evidence. Source integrity failures reject admission; legitimate knowledge gaps remain visible in the recorded assessment and its downstream restrictions.

15.8. Rights for Assessment Processing

Assessment processing is a material use governed by PP-RLCPS §§9–10, 23–25 and 30–38. Storage, availability, prior Stage 7.13 admission and permission for internal review SHALL NOT imply permission for another processing operation. Before reading protected payloads, disclosing them to a provider or processing them, the producer SHALL obtain a Rights Gate result for the actual operation. Supplied conclusions SHALL retain that original processing authorisation; an admission-time check cannot retrospectively authorise their creation.

The retained record SHALL include the Rights Decision authorising this assessment use and bind exact identities, versions and digests of all applicable Rights Records, licences/agreements and decisions; the governed gate policy/version and result; actor and provider/model where used; source and derived-output scope; intended use, audience, territory, channel, processing type, duration, tenant and white-label context; attribution, confidentiality, retention and other conditions; and evaluation time. Required agreement evidence and decision authority SHALL resolve. Any material source's narrower restriction applies to the derived assessment; conflicting rights use PP-RLCPS precedence, never the least restrictive interpretation. A legal exception requires the existing authorised decision path, not an assessment author's override.

Only Pass or a scoped Pass with Conditions, Internal Use Only or Restricted Audience result whose conditions are demonstrably satisfied for this operation permits processing. Legal Review Required, Additional Permission Required, Block, Quarantine, Unable to Determine, missing results and unknown outcomes do not. A permitted storage/internal-review path therefore cannot authorise external AI use; neither a favourable assessment nor all-false authority grants changes that result. Conditions that continue after creation SHALL remain enforceable and attached to the output.

Re-evaluate rights before a changed processing path, on resumption, at final admission and before a later material use. Expiration, revocation or a newly applicable restriction must block the affected operation and admission; previously lawful evidence remains distinguishable from current permission. Historical verification is itself subject to current access, retention and deletion rules: loss of lawful access SHALL withhold a successful replay claim, not trigger retrieval of prohibited bytes. Denial records SHALL retain only permitted audit metadata and SHALL NOT leak rejected source content. Unresolved permission or lifecycle admission is a failed prerequisite, not an impact unknown that can be stored as a successfully admitted assessment.

15.9. Lifecycle Eligibility and Temporal Coordinates

This initial profile selects canonical lifecycle values from config/system/pergamum-pulse/pergamum-pulse-lifecycle-registry.json; it introduces no new universal states or transitions. The validator SHALL derive and retain each input's evidence role from the exact persisted Stage 7.13 bindings and the governed assessment purpose. Caller labels are assertions to verify, not role-selection authority. These roles are not lifecycle states.

For the initial Requirement Target-State Reconciliation profile, the derivation is fixed:

Persisted binding	Mandatory treatment
PP-CDE and its complete PP-DIF set	Observations; independently verify the sealed detector method/configuration, source digests and exact before/after linkage.
Requirement in PP-CDE `current_state`	Required current basis, together with its exact admitted PP-RAD lineage. Verify agreement with `source_objects`, provenance and the source supplying every PP-DIF `current_value`; list order or similarity is not a substitute for those bindings.
Governed `supersedes` / `replaces` continuity relationship bound by Stage 7.13 provenance	Required current basis for the initial profile's claim that this source can inform change to this predecessor; verify exact endpoints, direction, version/digest and provenance.
Requirement in PP-CDE `previous_state`, also bound by PP-DIF `target_path` and `previous_value`	Historical/comparison subject with its admission lineage at the retained comparison coordinate. This treatment does not automatically make it a valid current execution target; proposed operations retain their separate target preconditions.
Additional evidence used to establish a currently applicable obligation or prerequisite	Current basis for that use under the reviewed purpose/policy. A comparison-only use must be evidenced as such and cannot discharge that prerequisite. If an exact input serves both uses, all current-basis checks still apply.

Omitting a mandatory basis, swapping before/after roles, substituting another version or presenting a historical label for a required current basis SHALL fail admission. If the current_state Requirement, its required PP-RAD or the continuity relationship has become ineligible, an active PP-CDE/PP-DIF set cannot rescue the assessment. Historical examination may retain lawful audit findings, but historical-only assessment admission is outside this initial profile and such findings SHALL NOT satisfy Stage 7.15's PP-IA/PP-DA prerequisites. Supporting that separate purpose later requires a reviewed profile with an explicit Candidate-consumption restriction; changing the purpose string cannot select an undocumented fallback. This leaves the sealed Stage 7.13 observation intact while refusing a new current-use claim.

For each processing/admission check, retain the database-controlled effective instant and committed transaction snapshot/watermark used to resolve lifecycle transitions and rights. Current-use eligibility uses that check's current coordinate, never a caller-supplied historical time. The final check SHALL include transitions effective and known by its admission coordinate. Competing changes and admission require a proven serialization order: a restriction effective and visible before admission must be enforced; an unprovable order requires rejection or retry. Retain authorised transition identity/version/digest, reason, authority, effective time, transaction time and conditions under PP-KORS §7. Missing, conflicting or ambiguous required transition evidence fails admission.

Historical reconstruction instead uses the exact retained valid-time and transaction-time coordinates of the Stage 7.13 detection/comparison and the original assessment checks. Preserve separate before/after coordinates where supplied; do not resolve mutable heads. Interpret recorded_at as inclusive and superseded_at as exclusive transaction-time bounds. An explicit valid_from/valid_to uses the existing Stage 7.13 inclusive bounds; null is open only when not declared unknown. Rights expiration/revocation still denies use at its effective instant. Later-recorded corrections are retained as separate evidence for current use and do not silently rewrite what the original snapshot knew.

Evidence role	Eligibility in the initial profile
Required PP-CDE and complete PP-DIF observation set	Exact persisted versions must be `admitted` or `active`, known by the transaction snapshot, with detection/recording no later than the check and no effective withdrawal, suspension, retirement, supersession or tombstone at that coordinate. The Stage 7.13 producer's explicitly unknown `valid_from`/`valid_to` is permitted for these observations: their detection instant supplies observational time, not an assertion of indefinite source validity. Any explicit validity restriction still applies.
Requirement, admission decision or relationship relied on as a current basis	`admitted` or `active` only, with applicable validity established at the current coordinate, no effective retirement/tombstone/supersession, and the exact admitted Requirement/PP-RAD lineage where required. Unknown validity cannot establish a current basis. Lifecycle alone never supplies authority or rights.
Input derived as a historical/comparison subject above	Retain the exact Stage 7.13 source/target binding and state at its recorded comparison coordinate, plus later transitions known at assessment admission. A historical authority claim must satisfy the previous row at its historical coordinate. Any registered lifecycle state may be described as an observed fact, including a tombstone; that description grants neither current authority nor access to its payload. Restricted subjects use only evidence permitted by §15.8, preserve unresolved coverage, and cannot satisfy a required current-basis input. Withdrawal alone never changes a derived current basis into this role.

For the first two rows, all other registered states (proposed, draft, active with conditions, review required, disputed, deprecated, superseded, suspended, withdrawn, retired, historical only, rejected, quarantined, deleted with retained tombstone) are ineligible. Extending this initial allowlist requires a reviewed profile change; an unknown value never falls back to eligibility. Reinstatement requires a governed transition and fresh current-use checks, not reuse of a cached pass. Preserve that outcome separately from historical replay and from an assessment's unchanged payload. A later Candidate must recheck current eligibility; successful historical verification grants no new use permission.

15.10. RECORDED Creation Anchor and Replay Manifest

TG-RP §§2.3, 4 and 6 require the final recorded conclusion itself to be DAL-anchored at creation. An immutable database row, local hash, queued anchor request or anchor first produced during replay is insufficient. The successor contracts SHALL bind the existing TG-CSI contracts comp.TG.OUTPUT.REPLAY-MANIFEST.v1_0, comp.DAL.OUTPUT.ANCHOR-RECEIPT.v1_0 and, where used by the governed anchor profile, comp.DAL.OUTPUT.MERKLE-PROOF.v1_0; they SHALL NOT invent parallel replay or ledger contracts.

Required retained binding	Validation obligation
Final assessment artifact	Pin exact identity/version, canonicalisation rule and hash algorithm, final artifact digest and complete input lineage. Its hash domain includes all material conclusions, the §8.4 analysis context, derived evidence roles, source/scope and provenance, and every processing/eligibility check completed before finalization. It excludes subsequent admission-attempt evidence and proof/receipt links, which have the separate integrity binding below. No field within the finalized conclusion or its creation evidence may be omitted or changed to match an old anchor.
Creation-time DAL anchor	Retain the exact anchor-receipt reference and digest, DAL record identity, anchored artifact identity/hash, creation/submission ordering evidence, signer/key identity and verifiable ledger proof under the pinned anchor profile. Verify against the trusted DAL record/receipt, not author-supplied timestamps. A later optional external batch anchor cannot substitute for the required creation-time DAL record.
Replay manifest	Retain its immutable reference, version and digest. The recorded output entry carries `replay_mode: RECORDED`, `artifact_hash`, `engine_cmi` and `config_snapshot_ref` under TG-RP §4, and binds the exact assessment and DAL receipt. Separate deterministic validation/traversal outputs declare `EXACT`; each output has exactly one mode.

The governed creation operation finalizes the artifact and obtains and verifies its creation-time DAL anchor. Final admission checks occur afterward against the frozen artifact and current eligibility; they SHALL NOT be inserted into its pre-existing digest or represented as if they had occurred before creation. Drafts are not admitted PP-IA/PP-DA outputs. Imported already-finalized RECORDED conclusions require their original creation-time anchor; import cannot substitute a later timestamp or manufacture historical assurance. Missing, late, substituted, unverifiable or hash/identity-mismatched anchors or manifests withhold admission and replay success.

15.10.1. Separate Admission-Attempt Evidence

Each final-admission attempt SHALL produce immutable evidence through the existing comp.TG.OUTPUT.AUDIT-RECORD.v1_0 contract, separately from the assessment payload. Its reviewed audit profile SHALL bind the following content; it grants no PP change, projection or Runtime authority and does not introduce a new PP object prefix:

the exact attempt identity, assessment identity/version/digest and original creation-anchor and replay-manifest references/digests;
the governed admission operation, executor/engine and configuration/policy versions/digests, actor and intended use/scope;
the newly derived evidence-role mapping and every final rights/lifecycle result, exact evidence/transition references and digests, effective instant, committed transaction snapshot/watermark and serialization evidence;
the comparison of current source/graph/policy/scope bindings with the frozen analysis and any resulting rejection or reassessment requirement;
the pass/deny result and reasons, canonicalisation/hash algorithm, attempt-content digest and trusted audit producer authentication; failed attempts retain only audit metadata permitted by §15.8.

The audit observation uses RECORDED semantics under TG-RP, with its own creation-time DAL receipt and immutable replay-manifest entry. Its content digest binds the assessment and its original proof; its own receipt/manifest links remain outside that content digest to avoid self-reference. The attempt anchor proves this later audit observation, never a replacement creation time for the assessment. Deterministic evaluation of its frozen inputs is a separate EXACT output under the existing declared replay profile; replay SHALL NOT rerun that decision against today's mutable state and call the result historical proof.

Accepted assessment status SHALL atomically reference the exact passing attempt identity/digest, its verified DAL receipt/manifest, and the exact assessment digest and original proof bindings in the PP persistence transaction. This acceptance binding is immutable; later use checks and lifecycle transitions retain separate records rather than replacing its attempt reference. A loose audit link, unsigned caller-provided result, missing attempt or pass belonging to a different assessment, operation or attempt is insufficient. No assessment is exposed as admitted until this binding commits. Verification of admitted status requires both the assessment creation proof and this successful-attempt binding; assessment-artifact integrity alone proves neither admission nor present eligibility. An audit pass followed by transaction failure is not an admitted assessment.

The final decision has a database-controlled serialization point. The adopted contract SHALL protect the checked state through proof publication and PP commit, including every competing writer in the declared conflict domains, and prove that time-based conditions remain valid through commit. An expired deadline, lost protection, newly visible relevant change or unverifiable ordering aborts that attempt; an additional check requires a new attempt record and proof, never mutation of an anchored one. This requirement applies while waiting for either audit persistence or DAL; a pre-anchor pass is not an unlimited lease. If a changed input alters the frozen analysis or required creation permission, admission fails and a governed successor assessment is needed; a new attempt cannot repair the old conclusion.

The adoption design SHALL specify durable receipt/manifest and audit storage and the atomic PP boundary. If DAL submission succeeds but PP admission fails, immutable ledger/audit evidence remains associated with the failed transaction, with no accepted assessment or authority; it is not deleted to simulate a cross-service rollback. A retry of an uncommitted admission may reuse the identical finalized assessment and its original verified anchor, but SHALL perform fresh final checks and create its own attempt evidence. A retry after a committed admission may return the original immutable acknowledgement idempotently; it SHALL NOT claim a fresh current-use pass. Subsequent use has its own eligibility check. Proofs must demonstrate zero residual accepted assessment writes on failure, reject rebinding any receipt to different content, and distinguish immutable attempt evidence from a successful commit.

16. Dependency Assessment

Every Candidate SHALL reference an assessment of upstream and downstream dependencies. Stage 7.14B creates that PP-DA from §15.6's evidence and scope before the Candidate exists.

This conceptual example uses the same source subject as the PP-IA example; full scope, snapshot and provenance bindings are required by §15.6.

dependency_assessment:
  assessment_id: PP-DA-000001

  detection_event:
    object_id: PP-CDE-000001
    version: 1.0.0
  differences:
    - object_id: PP-DIF-000001
      version: 1.0.0

  upstream:
    - object_id: PP-KA-000101
      version: 1.0.0
      dependency_type: semantic_dependency

  downstream:
    - object_id: schema.zayaz.requirement
      version: 1.0.0
      dependency_type: schema_dependency
    - object_id: report-template.esrs
      version: 1.0.0
      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.

16.6. Direction, Graph Closure and Ordering

For every retained dependency edge, direction SHALL be expressed relative to an exact assessed target version or an explicitly evidenced absent-target subject under §15.6. upstream means that target depends on the referenced prerequisite; downstream means the referenced dependent depends on that target. A multi-target assessment SHALL retain both endpoints for each edge. An edge describing a prerequisite is oriented prerequisite → dependent for ordering purposes; existing graph relationship direction SHALL be translated according to its registered semantics, never guessed or silently reversed.

Each edge SHALL retain its governed dependency type, evidence, blocking treatment and fallback where applicable. Typed, versioned node identities SHALL not collapse across tenants or versions. Absent-target subjects SHALL remain distinct from resolved existing objects and their expected relationships SHALL be labelled as assumptions. Unsupported edge types, inconsistent inverse relationships, missing versions for existing endpoints and cross-scope references fail validation. A genuinely unknown relationship may be recorded as an unresolved finding, not fabricated as a resolved edge.

Traversal SHALL use the retained graph snapshot and declare the relationship types, direction, roots, included nodes/edges, exclusions, completeness evidence and any truncation. Missing graph coverage remains unresolved; an empty edge list alone proves neither independence nor completeness. Traversal limits and fallback policy SHALL be pinned governed inputs, not hidden source-code thresholds.

Cycle detection SHALL cover the retained in-scope graph, including self-dependencies, and preserve a verifiable cycle path. Cycles and unresolved blocking dependencies may be recorded for review, but SHALL withhold a complete usable order. For a resolved acyclic graph, derive prerequisite-before-dependent order deterministically, with a declared stable tie-break on exact canonical identities/versions. Reordering equivalent inputs must not change the governed result.

The existing field name projection_order denotes an assessed ordering constraint only. Its presence does not grant projection eligibility or authorize execution. Stage 7.17 must verify it against the exact approved Candidate/Decision scope and current admission conditions. A partial order SHALL never be represented as a complete one.

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

Assessment processing and admission SHALL pass the earlier, operation-specific Rights Gate in §15.8; the projection gate below is an additional later check.

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 assessment, Candidate, projection, release and Publication impact analysis. Any resulting assessment processing must itself satisfy §15.8; the obligation to analyse a withdrawal does not permit prohibited processing of the withdrawn content.

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.

60.1. Stage 7.14B Acceptance and Closure

The following proofs SHALL be implemented against the exact adopted contracts and persistence profile. This is an acceptance plan, not a claim that these tests already exist or pass.

Case	Required evidence
Candidate-free admission	PP-IA and PP-DA can each persist with valid Stage 7.13 evidence, a complete §8.4 shared analysis context and no PP-CC or other assessment row. Validate each context against its retained inputs rather than trusting a declared digest. The later pair-consumption tests below belong to the Stage 7.15 handoff and are not 7.14B implementation prerequisites.
Exact source closure	Reject wrong event/type/version/digest, cross-event differences and incomplete/extra/duplicate difference sets. Preserve the no-change path without invented objects.
Scope and provenance	Reject unauthorized scope expansion, tenant/version substitution, fabricated versions for absent targets and missing provenance. Preserve historical coordinates and distinguish historical integrity from current permission and eligibility.
Assessment Rights Gate	Prove §15.8 before processing and admission: allow permitted in-scope operations with verified conditions; deny external-model use when only storage/internal review is permitted. Reject missing/substituted Rights Records or Decisions, wrong purpose/provider/audience/territory/channel/tenant, unresolved outcomes, unsatisfied conditions, expiration/revocation and retrospective permission. Denial must prevent the prohibited read/disclosure and assessment write, not merely reject its output later.
Lifecycle and time	Exercise every allowlisted and ineligible state in §15.9 for each evidence role, the transition matrix below, exact temporal boundaries, unknown observation dates, ambiguous history and historical/current-use separation. Prove concurrent transitions cannot admit stale eligibility.
Derived evidence roles	Derive roles from the sealed Stage 7.13 current/previous bindings, PP-RAD lineage and continuity evidence. Reject historical relabelling of the current Requirement, its PP-RAD or required relationship; omitted bases; before/after swaps; inconsistent DIF/source bindings; purpose-string fallback; and dual-use evidence that fails its current-basis check. An active CDE/DIF with a withdrawn current Requirement must fail even when the caller labels every source historical. A valid historical predecessor alone is not such a failure.
Impact semantics	Preserve benefits, adverse effects, evidence and unknowns; reject a missing dimension presented as no impact or a severity calculated without its required policy.
Dependency semantics	Demonstrate both directions with real endpoint pairs, transitive dependencies, optional fallback, disconnected nodes, self-cycles and multi-node cycles. Reject reversed or ambiguous edges and false completeness claims.
Determinism	Reordered equivalent inputs yield the same governed graph result and order; changed source, scope, policy or graph snapshots cannot reuse an old result. RECORDED conclusions preserve their creation-time evidence.
RECORDED anchor and manifest	Verify final artifact/identity/lineage against the trusted creation-time DAL receipt and immutable TG-RP manifest. Reject a missing or late anchor, queued-only request, forged timestamp, bad signature/proof, wrong identity/hash, substituted receipt, missing/wrong mode or artifact hash, unpinned engine/configuration and hash-domain omissions. An immutable SQL row alone must fail. Test unavailable lawful replay evidence, DAL failure, DAL success followed by SQL rollback, and exact retry reconciliation without an accepted residual assessment.
Admission-attempt binding	Prove both §15.10 hash domains and the atomic accepted-status binding. Change rights/lifecycle after assessment anchoring: a denied attempt cannot admit, while a still-eligible transition creates separately verifiable evidence without changing the assessment digest. Reject omitted/substituted/tampered/unauthenticated attempt evidence, wrong assessment/attempt/scope, missing audit anchor/manifest, and use of an earlier pass after rollback. Test expiry/revocation during audit anchoring, failed commit after an anchored pass, a fresh attempt after that failure, and idempotent acknowledgement after a successful commit without claiming new eligibility.
Authority ceiling	Attempts to add authority through direct fields, inherited metadata, references, derived ordering or alternate write paths fail closed. No assessment creates approval or projection/release/activation state.
Persistence and concurrency	Verify atomic rollback, idempotent retries, immutable old versions, reference/payload agreement, source-change races, competing same-version writes and zero rollback residue.
Independent proof	The reviewed executor exercises the exact IA/DA subjects and emits complete attestations; missing, stale, substituted or borrowed attestations fail. Seal only the proven source with its exact manifest.

The lifecycle/rights transition fixtures SHALL include the following matrix. These cases retain the original evidence and do not change existing objects merely to make a replay pass.

Transition or timing case	Expected new processing/admission or reuse	Expected historical treatment
`admitted` → `active`, with valid rights and temporal scope	Permit after a fresh check of the exact version and required authority lineage.	Resolve the state known at each retained coordinate.
An eligible observation/current basis → any ineligible state in §15.9	Reject that required role at or after the effective transition once known; exercise every state individually.	Prior lawful evidence remains verifiable only while current access permits; no new eligibility follows.
The derived historical predecessor becomes `superseded`, `withdrawn`, `retired` or `historical only`	It may remain a bound comparison subject, never a substituted current basis; restricted payload access still fails the Rights Gate. The same transition on the mandatory current Requirement, PP-RAD or continuity relationship rejects admission.	Preserve exact before/after source versions, derived roles, transition history and limited evidence coverage.
Ineligible state → `active` with governed restoration	Re-evaluate the current policy, rights, scope and authority; an old pass or an unproven restoration is insufficient.	Earlier denial and earlier assessment bytes remain unchanged.
Transition effective in the future, or recorded later with an earlier effective time	Test immediately before, at and after effective time and transaction visibility. Apply known effective restrictions to new use; reject ambiguous histories and caller-backdated checks.	Replay uses its original transaction snapshot and separately discloses later corrections.
PP-CDE/PP-DIF has the Stage 7.13 unknown validity bounds	Accept the permitted observation-time semantics; the same unknown bounds cannot prove a Requirement's current applicability.	Preserve the unknowns instead of treating them as unlimited validity.
Rights pass before processing, then expire or are revoked before final admission	Deny when the restriction is effective and known at admission; prove concurrent ordering or reject/retry. No fresh external read or accepted assessment may use the stale pass.	Preserve the original lawful processing record and the later denial as separate evidence.

The Stage 7.15 handoff SHALL exercise §8.4 with these pair cases; retaining the complete comparison inputs is a Stage 7.14B schema/persistence requirement, while implementing Candidate consumption remains Stage 7.15 work:

Pair case	Required Candidate result
Same frozen shared context, compatible findings, different authors/creation times/final-admission attempts	May consume after both proofs, per-member rights and a fresh common current-use check pass. Do not require wall-clock attempt times or artifact digests to match.
Same CDE/DIF and scope, different graph snapshot, analytical valid/transaction coordinate, policy/configuration inventory, common evidence version or derived source role	Reject the pair; exercise each mismatch independently, including equal snapshot labels with different digests and reordered sets with equivalent content. Equivalent declared sets may pass; changed content may not.
Same context identifier/digest claim, different resolved content, conflicting assumptions or material findings	Reject the pair; a self-declared digest, unresolved marker or favourable result cannot conceal a disagreement.
Individually valid assessments, but combined rights prohibit Candidate use, a current basis is now withdrawn, or covered source/graph/policy inputs have materially changed	Reject consumption; historical replay remains distinct from current eligibility. Re-derive roles rather than trusting either member's labels.
Corrected successor assessment versions against one reconciled context	Re-evaluate the whole pair and retain the exact accepted comparison in Candidate provenance; no mutation of old assessments and no informal override.

Stage 7.14B closes only after the registry contracts, successor schemas, migration and loader are aligned, these capability proofs and inherited PP-GOCF proofs pass, and review finds no unresolved material gap. Operational closure requires recorded migration/postflight and verification evidence for the intended environment. Any remaining assessment unknowns must retain their governed restrictions; they cannot be erased to close the engineering stage.

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.

61.2. Stage 7.14B Adoption and Existing Consumer Reconciliation

The checked repository baseline at this reconciliation is eb2e9291 (main after #211). It contains the following coordinated adoption work:

Existing surface	Current behaviour	Required successor treatment
Core 1.0 `change/impact-assessment.schema.json` and `change/dependency-assessment.schema.json`	Require a `candidate` reference; do not bind the Stage 7.13 source/scope closure in §15.6 or the rights, lifecycle and replay evidence in §§15.8–15.10.	Add explicitly versioned assessment schemas for the evidence-first contract, preserving exact historical schema resolution. Bind the authority ceiling, §8.4 shared analysis context, source/scope requirements, exact Rights Record/Decision and gate references, derived lifecycle roles/transition snapshots and coordinates, final artifact hash, DAL receipt and immutable replay-manifest references/digests. Specify separate assessment-creation and admission-attempt hash domains.
Core 1.0 `change/change-candidate.schema.json`	Requires exact assessment references.	Retain that direction; Stage 7.15 implements §8.4's strict shared-input equality and contradiction checks, retained pair-comparison evidence and current-use role derivation/rechecks. Do not weaken references to break the cycle or accept ad hoc compatibility overrides.
Object loader `src/adapters/change-governance.ts`	Both assessment adapters require `pp.change_candidate` and preflight `d.candidate`; the Candidate adapter preflights both assessments.	Select the reviewed schema/profile explicitly, remove the reverse prerequisite for the new profile, enforce the assessment proof/admission boundary, and retain truthful historical resolution. No apply path may silently bypass it.
Migration 009 `01-change-governance-foundation.sql`	Both assessment tables have non-null Candidate columns and deferred reverse foreign keys. Candidate rows also reference the assessments.	Use a forward migration with explicit schema/profile constraints and source-reference persistence. Deferred constraints alone do not remove the cycle. Never edit migration 009 in place or fabricate a Candidate to satisfy it.
`pp.impact_assessment_evidence_ref`, `pp.dependency_assessment_ref` and `pp.v_change_governance_reference_integrity`	Typed references and the integrity view expose the candidate-bound model.	Reconcile normalized source/edge references, both endpoints, indexes, views, verification and replay; add descriptions to every new/changed table and column. Retain historical truth and avoid broad nullable escape paths.
Rights schemas, `pp.rights_record` and assessment admission	Existing Rights Records and Rights Decision schemas do not by themselves prove permission for a particular assessment operation.	Bind the exact applicable records/decisions, policy and scoped gate result from §§15.8–15.9, with durable condition/evaluation evidence. Enforce pre-processing and final-admission checks, reference/payload agreement and concurrent revocation handling; do not create rights authority in an assessment.
`pp.object_version`, `pp.lifecycle_transition` and retained Stage 7.13 history	Common versions and transitions exist, but the transition relation's single `transition_at` does not by itself establish the required effective/transaction-time history and policy resolution.	Declare and migrate the exact temporal/transition evidence storage and fixed Stage 7.13 role derivation in §15.9, including current Requirement/RAD/continuity checks; preserve original snapshots and expose current-use rechecks separately. No fabricated backfill of unknown history and no change to sealed Stage 7.13 semantics.
DAL receipts, TG-RP replay manifests and TrustGate audit evidence	Migration 009 and the current assessment schemas have no required assessment-to-DAL-receipt/replay-manifest or final-attempt binding.	Add immutable, integrity-checked persistence for both §15.10 proof chains and the exact attempt referenced by accepted status; pin existing CSI schema/anchor-profile closure, separate canonical hash domains, signer/proof validation and historical lookup. The reviewed audit profile must bind the listed fields using the existing Audit Record contract; missing schema coverage requires its governed revision before implementation, not an undocumented payload extension. Enforce the atomic accepted-status link, serialization/expiry protection through anchoring and commit, failed-attempt retention and fresh retry checks. Prove the §60.1 negative cases; a local row/hash or queued request cannot replace either DAL receipt.
PP-GOCR and independent executor coverage	The active reference contracts are PP-RAD, PP-CDE and PP-DIF. IA/DA object-prefix registration is not executable conformance coverage.	Review and register assessment contracts with exact schema/persistence subjects and new capability proofs, preserving the three existing reference contracts and required independent gate.

Before applying a migration, perform a read-only inventory of existing assessment/Candidate rows and callers in the intended environment. The repository inspection does not establish that those tables are empty or that there are no external callers. Existing candidate-bound payloads and digests SHALL remain unchanged. Derive a new assessment only when its source closure can be established; otherwise preserve it as historical data without claiming new-profile conformance or new-write eligibility.

Delivery is ordered: review this semantic reconciliation; register and review the exact Governed-Object Contracts and executor bindings required by PP-GOCF; implement successor schemas, persistence and loader together; run capability and independent proofs; then verify the bounded rollout and record closure. Stage 7.15 follows that closure. This revision changes no executable schema, SQL, permission, verifier configuration or deployed service and does not satisfy those later steps by documentation alone.

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:

represents detected change as governed Change Detection Events;
distinguishes Detection Events from Candidates;
preserves old and new state in Difference Records;
classifies structural, semantic, rights, applicability and constitutional differences separately;
prevents text change from automatically establishing semantic change;
assigns stable PP-CC- identifiers to Candidates;
prevents Candidate identifier reuse;
preserves independent Candidate versions;
preserves immutable completed Candidate versions;
links Candidates to governed source basis;
distinguishes source-mandated change from design proposal or hypothesis;
propagates source withdrawal to dependent Candidates;
pins target identity and version;
identifies canonical versus derived target state;
preserves target Module and Component ownership;
fails invalid non-create Candidates with missing targets;
represents proposed operations explicitly;
preserves expected current state;
supports compare-and-set protection;
governs destructive operations;
identifies no-op Candidates;
preserves complete payloads or reproducible patches;
prevents unrelated hidden changes;
prevents secrets from entering Candidate payloads;
requires human-readable rationale;
distinguishes source requirements, expert interpretation, architecture judgement and AI recommendations;
requires material Impact Assessments;
evaluates constitutional, Registry, schema, computation, workflow, Runtime, tenant, Publication, certification, security, rights and historical impacts;
represents unknown impact explicitly;
requires Dependency Assessments;
detects dependency cycles;
respects dependency order;
blocks unresolved mandatory dependencies;
represents multidimensional risk;
governs residual-risk acceptance;
separates source authority from Candidate approval authority;
routes constitutional-impacting change to constitutional governance;
prevents Runtime authority before activation;
preserves rights across Candidate and projection processing;
blocks prohibited external processing;
propagates rights expiration and revocation;
represents Candidate applicability and scope explicitly;
prevents tenant-specific Candidates from silently becoming global;
governs scope promotion;
separates detection, analysis, review, Decision, projection, release and activation status;
requires risk-appropriate review;
preserves reviewer competence;
enforces separation of duties for high-impact change;
preserves Candidate conflicts as first-class objects;
prevents automated silent conflict selection;
governs Candidate Packages;
preserves member Candidate identity, authority, rights and Decision;
governs Package atomicity;
represents Change Decisions as separate objects;
pins Decisions to Candidate versions and payloads;
preserves Decision authority and signatures where required;
preserves immutable Decisions;
prevents expired or revoked Decisions from authorising new projection;
represents Decision Conditions as enforceable objects;
blocks according to unsatisfied blocking conditions;
requires a Projection Eligibility Gate;
prevents eligibility from implying release or activation;
produces eligibility receipts;
represents Projection Manifests as immutable governed objects;
pins all material projection inputs and digests;
prohibits unpinned mutable production inputs;
records compiler identity, version, configuration and environment;
preserves the Constitutional Compiler authority boundary;
requires deterministic generation where feasible;
discloses non-determinism;
governs external generators;
records Compiler Executions;
isolates build environments;
pins and verifies build dependencies;
supports SBOMs for material builds;
represents generated outputs as first-class artefacts;
preserves artefact identity, media type, path, digest, rights, scope and provenance;
distinguishes preview, projection, release and active artefacts;
preserves immutable released artefacts;
supports signing of high-impact artefacts;
governs multi-artefact projection and atomicity;
validates cross-artefact consistency;
performs output-appropriate validation;
produces Validation Receipts;
classifies validation warnings;
expires validation after material input or environment change;
validates objective structure through HECATE;
prevents HECATE from approving meaning, rights, release or activation;
requires Test Plans for high-impact change;
links tests to Candidates, invariants and artefacts;
blocks release on blocking test failure;
governs test-data rights and tenant isolation;
requires Migration Plans where migration is needed;
supports dry runs for high-impact migration;
separately approves potential data loss;
preserves bitemporal and historical integrity during migration;
requires Rollback Plans for reversible high-impact change;
governs non-reversible changes with compensating controls;
validates rollback where feasible;
represents Projection Releases separately from projections and activation;
prevents release from being interpreted as activation;
preserves release authority and notes;
represents Activation Requests separately;
prevents Activation Requests from creating active state;
records Activation authority, scope, previous state, new state and provenance;
verifies released and activated artefact digests;
treats activation drift as an Incident;
governs controlled rollout and cohorts;
defines promotion and rollback criteria;
monitors material activations;
preserves monitoring baselines and thresholds;
records rollback without deleting activation history;
governs partial rollback and roll-forward;
governs projection withdrawal;
manages Change Incidents and preserves evidence;
preserves tenant and white-label overlays;
prevents cross-tenant references and leakage;
assesses global change against tenant and white-label overrides;
distinguishes proposed, approved, released and active states in communications;
applies Publication governance to report and public-claim outputs;
prevents projection from creating certification status;
prevents projected formulas from becoming active computation without admission and activation;
enforces security, signing, digest verification and privileged operations;
prevents AI Agents from issuing Decisions, releasing or activating;
measures change quality without creating authority;
detects stale Candidates, Decisions, projections and receipts;
preserves both Module and Component lineage;
preserves complete end-to-end provenance;
blocks critical actions where provenance is materially incomplete;
supports historical reconstruction of Candidate, Decision, projection, release and activation state;
supports Exact Replay;
distinguishes Exact Replay from Semantic Replay;
detects reproducibility digest mismatch;
prevents retroactive application of current governance to historical projections;
defines four conformance levels;
supports conformance fixtures;
governs migration and legacy import;
supports assurance and audit;
preserves tenant isolation, security, resilience and historical trust;
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 Repo Request for Change (RFC)

Version 0.2 — Assessment-First Proposal, Decision and Projection Contract
1. Scope
2. Normative Language
3. Controlled Change Architecture
- 3.1. Stage 7.14B Assessment Direction and Authority
4. Canonical Change and Projection Objects
5. Change Detection Event
- 5.1. Detection Sources
- 5.2. Detection Non-Authority
- 5.3. Detection Reproducibility
6. Difference Record
- 6.1. Difference Classes
- 6.2. Structural Difference
- 6.3. Semantic Difference
- 6.4. Rights Difference
- 6.5. Difference Non-Equivalence
7. Change Classification
- 7.1. Constitutional Classification
- 7.2. Emergency Classification
- 7.3. Classification Review
8. Canonical Change Candidate
- 8.1. Required Candidate Fields
- 8.2. Optional Candidate Fields
- 8.3. Assessment Consumption at Stage 7.15
- 8.4. Assessment-Pair Compatibility
9. Candidate Identity and Versioning
10. Candidate Types and Operations
- 10.1. Target Operation
- 10.2. Compare-and-Set Protection
- 10.3. Destructive Operation
- 10.4. No-Op Candidate
11. Source Basis and Traceability
- 11.1. Minimum Source Basis
- 11.2. Derived Intelligence
- 11.3. Unsupported Candidate
- 11.4. Source Withdrawal
12. Target Contract
- 12.1. Target Classes
- 12.2. Canonical Target Requirement
- 12.3. Target Ownership
- 12.4. Missing Target
13. Proposed Payload
- 13.1. Payload Forms
- 13.2. Patch Determinism
- 13.3. Human-Readable Explanation
- 13.4. Hidden Change Prohibition
- 13.5. Secret Prohibition
14. Rationale
15. Impact Assessment
- 15.1. Impact Dimensions
- 15.2. Impact States
- 15.3. Negative and Positive Impact
- 15.4. Unknown Impact
- 15.5. Impact Evidence
- 15.6. Shared Stage 7.14B Assessment Contract
- 15.7. Impact Coverage and Unknowns
- 15.8. Rights for Assessment Processing
- 15.9. Lifecycle Eligibility and Temporal Coordinates
- 15.10. RECORDED Creation Anchor and Replay Manifest
16. Dependency Assessment
- 16.1. Dependency Types
- 16.2. Dependency Graph
- 16.3. Dependency Ordering
- 16.4. Blocking Dependency
- 16.5. Optional Dependency
- 16.6. Direction, Graph Closure and Ordering
17. Risk and Materiality
- 17.1. Risk State
- 17.2. Materiality
- 17.3. Risk Acceptance
18. Authority
- 18.1. Authority Non-Transitivity
- 18.2. Target Authority
- 18.3. Constitutional Authority
- 18.4. Runtime Authority
19. Rights
- 19.1. Rights Gate
- 19.2. Restricted Inputs
- 19.3. External Processing
- 19.4. Rights Change
20. Applicability and Scope
- 20.1. Scope Dimensions
- 20.2. Global and Tenant Scope
- 20.3. Scope Promotion
21. Candidate Status Model
- 21.1. Detection Status
- 21.2. Analysis Status
- 21.3. Review Status
- 21.4. Projection Eligibility
- 21.5. Projection Status
- 21.6. Activation Status
22. Candidate Review
- 22.1. Review Record
- 22.2. Separation of Duties
- 22.3. Reviewer Conflict of Interest
23. Candidate Conflict
- 23.1. Conflict Types
- 23.2. Conflict Resolution
- 23.3. Silent Winner Prohibition
24. Candidate Package
- 24.1. Package Atomicity
- 24.2. Package Non-Aggregation
- 24.3. Partial Package Approval
- 24.4. Package Versioning
25. Change Decision
- 25.1. Decision States
- 25.2. Decision Scope
- 25.3. Decision Immutability
- 25.4. Decision Expiration
- 25.5. Conditional Approval
- 25.6. Rejection
26. Decision Conditions
27. Projection Eligibility Gate
- 27.1. Gate Outcomes
- 27.2. Eligibility Non-Activation
- 27.3. Eligibility Receipt
28. Projection Manifest
- 28.1. Required Manifest Fields
- 28.2. Manifest Immutability
- 28.3. Projection Types
29. Projection Inputs
- 29.1. Input Snapshot
- 29.2. Input Drift
- 29.3. Dynamic Input Prohibition
- 29.4. Unknown Input
30. Compiler and Generator Contract
- 30.1. Compiler Authority Boundary
- 30.2. Generator Determinism
- 30.3. Non-Deterministic Generator
- 30.4. External Generator
31. Compiler Execution
- 31.1. Execution Status
- 31.2. Execution Logs
- 31.3. Execution Isolation
- 31.4. Dependency Integrity
- 31.5. Software Bill of Materials
32. Generated Artefact
- 32.1. Artefact Types
- 32.2. Artefact Identity
- 32.3. Generated Versus Canonical
- 32.4. Artefact Immutability
- 32.5. Artefact Signing
33. Multi-Artefact Projection
- 33.1. Atomic Projection
- 33.2. Independently Releasable Artefacts
- 33.3. Cross-Artefact Consistency
34. Projection Validation
- 34.1. Validation Receipt
- 34.2. Validation States
- 34.3. Warning Treatment
- 34.4. Validation Expiration
35. HECATE Validation
36. Test Plan
- 36.1. Test Traceability
- 36.2. Test Failure
- 36.3. Test Data
37. Migration Plan
- 37.1. Dry Run
- 37.2. Data Loss
- 37.3. Historical Integrity
38. Rollback Plan
- 38.1. Non-Reversible Change
- 38.2. Rollback Validation
39. Projection Release
- 39.1. Release Non-Activation
- 39.2. Release Channels
- 39.3. Release Authority
- 39.4. Release Notes
40. Activation Request
- 40.1. Request Preconditions
- 40.2. Request Non-Authority
41. Activation Record
- 41.1. Runtime Admission
- 41.2. Partial Activation
- 41.3. Activation Drift
42. Controlled Rollout
- 42.1. Cohort Definition
- 42.2. Promotion Criteria
- 42.3. Automatic Promotion
- 42.4. Automatic Rollback
43. Post-Activation Monitoring
- 43.1. Baseline
- 43.2. Thresholds
- 43.3. Observation Period
- 43.4. Monitoring Non-Authority
44. Rollback Record
- 44.1. Roll-Forward
- 44.2. Partial Rollback
45. Projection Withdrawal
46. Change Incident
- 46.1. Incident Severity
- 46.2. Evidence Preservation
47. Tenant and White-Label Governance
- 47.1. Tenant Overlay
- 47.2. White-Label Overlay
- 47.3. Global Change Impact
- 47.4. Cross-Tenant Prohibition
- 47.5. Tenant Promotion
48. Communication and Stakeholder Treatment
49. Publication and Reporting Boundary
50. Certification and Assurance Boundary
51. Computation and Financial Impact Boundary
52. Security
- 52.1. Candidate Integrity
- 52.2. Decision Integrity
- 52.3. Artefact Integrity
- 52.4. Supply-Chain Security
- 52.5. Privileged Operations
53. AI Agent Boundaries
54. Change Quality and Operational Metrics
55. Staleness and Expiration
56. Module and Component Lineage
57. Provenance
58. Historical Reconstruction
- 58.1. Exact Replay
- 58.2. Semantic Replay
- 58.3. Build Reproduction
- 58.4. Non-Retroactivity
59. Conformance Levels
- 59.1. Level 1 — Candidate-Identifiable
- 59.2. Level 2 — Decision-Governed
- 59.3. Level 3 — Projection-Ready
- 59.4. Level 4 — Historically Assured
60. Conformance Fixtures
- 60.1. Stage 7.14B Acceptance and Closure
61. Migration and Compatibility
- 61.1. Legacy Projection Import
- 61.2. Stage 7.14B Adoption and Existing Consumer Reconciliation
62. Assurance and Audit
63. Conformance Requirements
64. Foundational Principle

Version 0.2 — Assessment-First Proposal, Decision and Projection Contract​

1. Scope​

2. Normative Language​

3. Controlled Change Architecture​

3.1. Stage 7.14B Assessment Direction and Authority​

4. Canonical Change and Projection Objects​

5. Change Detection Event​

5.1. Detection Sources​

5.2. Detection Non-Authority​

5.3. Detection Reproducibility​

6. Difference Record​

6.1. Difference Classes​

6.2. Structural Difference​

6.3. Semantic Difference​

6.4. Rights Difference​

6.5. Difference Non-Equivalence​

7. Change Classification​

7.1. Constitutional Classification​

7.2. Emergency Classification​

7.3. Classification Review​

8. Canonical Change Candidate​

8.1. Required Candidate Fields​

8.2. Optional Candidate Fields​

8.3. Assessment Consumption at Stage 7.15​

8.4. Assessment-Pair Compatibility​

9. Candidate Identity and Versioning​

10. Candidate Types and Operations​

10.1. Target Operation​

10.2. Compare-and-Set Protection​

10.3. Destructive Operation​

10.4. No-Op Candidate​

11. Source Basis and Traceability​

11.1. Minimum Source Basis​

11.2. Derived Intelligence​

11.3. Unsupported Candidate​

11.4. Source Withdrawal​

12. Target Contract​

12.1. Target Classes​

12.2. Canonical Target Requirement​

12.3. Target Ownership​

12.4. Missing Target​

13. Proposed Payload​

13.1. Payload Forms​

13.2. Patch Determinism​

13.3. Human-Readable Explanation​

13.4. Hidden Change Prohibition​

13.5. Secret Prohibition​

14. Rationale​

15. Impact Assessment​

15.1. Impact Dimensions​

15.2. Impact States​

15.3. Negative and Positive Impact​

15.4. Unknown Impact​

15.5. Impact Evidence​

15.6. Shared Stage 7.14B Assessment Contract​

15.7. Impact Coverage and Unknowns​

15.8. Rights for Assessment Processing​

15.9. Lifecycle Eligibility and Temporal Coordinates​

15.10. RECORDED Creation Anchor and Replay Manifest​

15.10.1. Separate Admission-Attempt Evidence​

16. Dependency Assessment​

16.1. Dependency Types​

16.2. Dependency Graph​

16.3. Dependency Ordering​

16.4. Blocking Dependency​

16.5. Optional Dependency​

16.6. Direction, Graph Closure and Ordering​

17. Risk and Materiality​

17.1. Risk State​

17.2. Materiality​

17.3. Risk Acceptance​

18. Authority​

18.1. Authority Non-Transitivity​

18.2. Target Authority​

18.3. Constitutional Authority​

18.4. Runtime Authority​

19. Rights​

19.1. Rights Gate​

19.2. Restricted Inputs​

19.3. External Processing​

Version 0.2 — Assessment-First Proposal, Decision and Projection Contract

1. Scope

2. Normative Language

3. Controlled Change Architecture

3.1. Stage 7.14B Assessment Direction and Authority

4. Canonical Change and Projection Objects

5. Change Detection Event

5.1. Detection Sources

5.2. Detection Non-Authority

5.3. Detection Reproducibility

6. Difference Record

6.1. Difference Classes

6.2. Structural Difference

6.3. Semantic Difference

6.4. Rights Difference

6.5. Difference Non-Equivalence

7. Change Classification

7.1. Constitutional Classification

7.2. Emergency Classification

7.3. Classification Review

8. Canonical Change Candidate

8.1. Required Candidate Fields

8.2. Optional Candidate Fields

8.3. Assessment Consumption at Stage 7.15

8.4. Assessment-Pair Compatibility

9. Candidate Identity and Versioning

10. Candidate Types and Operations

10.1. Target Operation

10.2. Compare-and-Set Protection

10.3. Destructive Operation

10.4. No-Op Candidate

11. Source Basis and Traceability

11.1. Minimum Source Basis

11.2. Derived Intelligence

11.3. Unsupported Candidate

11.4. Source Withdrawal

12. Target Contract

12.1. Target Classes

12.2. Canonical Target Requirement

12.3. Target Ownership

12.4. Missing Target

13. Proposed Payload

13.1. Payload Forms

13.2. Patch Determinism

13.3. Human-Readable Explanation

13.4. Hidden Change Prohibition

13.5. Secret Prohibition

14. Rationale

15. Impact Assessment

15.1. Impact Dimensions

15.2. Impact States

15.3. Negative and Positive Impact

15.4. Unknown Impact

15.5. Impact Evidence

15.6. Shared Stage 7.14B Assessment Contract

15.7. Impact Coverage and Unknowns

15.8. Rights for Assessment Processing

15.9. Lifecycle Eligibility and Temporal Coordinates

15.10. RECORDED Creation Anchor and Replay Manifest

15.10.1. Separate Admission-Attempt Evidence

16. Dependency Assessment

16.1. Dependency Types

16.2. Dependency Graph

16.3. Dependency Ordering

16.4. Blocking Dependency

16.5. Optional Dependency

16.6. Direction, Graph Closure and Ordering

17. Risk and Materiality

17.1. Risk State

17.2. Materiality

17.3. Risk Acceptance

18. Authority

18.1. Authority Non-Transitivity

18.2. Target Authority

18.3. Constitutional Authority

18.4. Runtime Authority

19. Rights

19.1. Rights Gate

19.2. Restricted Inputs

19.3. External Processing