Pergamum Pulse — XBRL Taxonomy Runtime Activation

1. Purpose

This document defines the normative architecture by which an exact, immutable and already registered XBRL taxonomy release may become operative for a declared ZAYAZ Runtime Context.

It exists to preserve a strict constitutional distinction between:

1. taxonomy custody and registration;
2. projection release;
3. runtime activation authority;
4. runtime resolution;
5. semantic-mapping authority;
6. legal or methodological authority;
7. FOGE definition publication;
8. customer display;
9. XBRL validation and tagging use;
10. regulatory filing;
11. external publication; and
12. redistribution.

The central invariant is:

A registered taxonomy release is immutable evidence-backed platform data. Runtime activation is a separate, scoped, temporal and explicitly authorised constitutional binding between a Runtime Context and that exact registered release. Registration SHALL NOT imply release for activation; release SHALL NOT imply activation; and activation SHALL NOT imply legal authority, semantic-mapping authority, FOGE definition-publication authority, customer display, regulatory filing, external publication or redistribution authority.

This document builds on the authority boundaries established by PP-RXF-01, the release and activation objects owned by PP-CCPS, the validation boundary owned by PP-HKCP, the canonical Rights Gate owned by PP-RLCPS, the Runtime Context and temporal/event principles owned by ZYZ-CRF, ZYZ-CRF-7 and ZYZ-CRF-12, and the replay semantics owned by REPLAY-CONSTITUTION.

This version is an architecture and profile contract. It does not itself release or activate any taxonomy, grant any rights, create any Aurora migration, create any runtime pointer, or make any XBRL release operative.

---

2. Foundational authority chain

The architecture SHALL preserve the following chain:

Official XBRL Package
        │
        ▼
Governed Source Capture / Projection
        │
        ▼
pp.xbrl_taxonomy_release
immutable registered taxonomy release
        │
        ▼
pp.xbrl_taxonomy_registration_event
immutable registration evidence
        │
        │ registration creates no release or Runtime authority
        ▼
PP-REL
canonical Projection Release
exact released artefacts + digests
        │
        │ release creates no active Runtime state
        ▼
PP-AR
Activation Request
references exact PP-REL + released artefacts
        │
        ▼
Activation Admission
        │
        ├── PP-REL identity/version proof
        ├── released-artefact digest proof
        ├── taxonomy registration/seal proof
        ├── canonical Runtime Context binding
        ├── HECATE conformance evidence
        ├── canonical PP-RLCPS Rights Gate
        ├── activation authority
        ├── exact Temporal Profile binding
        ├── effective-boundary derivation proof
        ├── retroactivity proof where applicable
        ├── lifecycle-transition retroactivity proof where applicable
        ├── complete transaction-boundary proof
        ├── scope-intersection analysis
        ├── temporal-overlap analysis
        ├── resolver-multiplicity analysis
        ├── planned lifecycle-transition analysis
        └── rollback readiness
        │
        ▼
PP-ACT
Authorised Activation Record
preserves PP-REL + identical artefact digests
        │
        ▼
Runtime activation binding / derived projection
        │
        ▼
Runtime taxonomy resolver
        │
        ▼
Exact XBRL taxonomy_release_id

PP-ACT is the authority-bearing record of activation. Any database binding, materialized view, cache or runtime pointer derived from that record SHALL remain a projection of authority, never a second source of authority.

The PP-ACT.release reference SHALL resolve to the canonical PP-REL release used for activation. The registered XBRL taxonomy release is the domain object bound by the released artefacts; it SHALL NOT be substituted for the canonical PP-REL release field.

---

3. Core constitutional invariants

3.1 Registration is not release or activation

pp.xbrl_taxonomy_release SHALL remain an immutable registry of exact XBRL releases.

A taxonomy release MAY be registered, queryable and usable for separately authorised internal semantic analysis without having a PP-REL suitable for Runtime activation and without being runtime-active.

A registration event SHALL NOT:

• create a PP-REL;
• grant Runtime authority;
• grant semantic-mapping authority;
• create legal or methodological authority;
• grant customer-display authority;
• grant publication authority;
• grant filing authority; or
• grant redistribution authority.

3.2 Release is not activation

A PP-REL makes validated artefacts available for controlled use or later activation under PP-CCPS.

A PP-REL SHALL NOT itself create active Runtime state.

An XBRL activation SHALL therefore never jump directly from taxonomy registration to PP-AR or PP-ACT while omitting the canonical PP-REL boundary.

3.3 No global active flag

Runtime activation SHALL NOT be represented by a global mutable active boolean on pp.xbrl_taxonomy_release or an equivalent release-level shortcut.

The meaningful question is not:

Is this taxonomy active?

It is:

Which exact taxonomy release is operative for this declared Runtime Context, purpose/capability, consumer, scope and effective time under an exact PP-ACT-backed authority chain?

3.4 Activation is scoped by constitutional Runtime Context

Every activation SHALL be bounded by an explicit Runtime Context or an authorised projection of one.

The activation contract SHALL NOT define context merely as an ad hoc subset of convenient selector fields.

At minimum, it SHALL retain either:

1. the exact Runtime Context identity/version and canonical Context Fingerprint; or
2. an authorised Runtime Context projection conforming to ZYZ-CRF-12.

Where an authorised projection is used, it SHALL preserve:

• source Context Identifier;
• included dimensions;
• excluded dimensions;
• reason for each material exclusion;
• target capability;
• projection fingerprint;
• provenance; and
• the authority permitting that projection.

3.5 Activation is temporal and bitemporal

Activation SHALL preserve distinct temporal concepts including, where applicable:

1. activation effective time — when the binding is intended to be operative in Runtime;
2. activation transaction time — when the constitutional system records the activation authority/evidence;
3. transaction start and transaction end — the governed transaction boundary required for constitutionally significant change;
4. reporting context time — the reporting period/context for which the taxonomy may be selected;
5. taxonomy publication date;
6. regulatory applicability time; and
7. other transaction/recording times for later lifecycle events.

These SHALL NOT be collapsed into one timestamp.

Every activation effective interval SHALL declare its boundary semantics in accordance with ZYZ-CRF-7 §23.67.5. An implementation library, database range type or framework SHALL NOT silently choose whether valid_from or valid_to is inclusive or exclusive.

Every activation SHALL also bind the exact Temporal Profile resolved by CRP, including at least its canonical identity, version and immutable fingerprint. The Temporal Profile binding SHALL NOT be an optional mutable lookup because ZYZ-CRF-7 makes the Temporal Profile govern interval convention, clock source, time zone, calendar, precision, granularity, uncertainty treatment, correction policy, historical policy, replay policy and validation policy.

Every activation SHALL declare the governed status before activation required by ZYZ-CRF-7 §23.68.2 and SHALL represent the effective start as an explicit governed scheduled_boundary transition under §23.68.13. For a finite interval, it SHALL likewise declare the governed status after expiration and represent expiration as an explicit governed scheduled_boundary transition. Raw interval membership or non-membership alone is not sufficient lifecycle evidence.

The effective-start and expiration transition instants SHALL be derived deterministically from the exact interval value, declared boundary semantics and the pinned Temporal Profile's precision and granularity:

• effective start = the first governed instant included by the interval;
• expiration = the first governed instant not included after the interval's right boundary.

For a left-inclusive boundary, the effective-start instant will ordinarily equal valid_from; for a left-exclusive boundary it is the first governed instant after valid_from. For a right-exclusive boundary, the expiration instant will ordinarily equal valid_to; for a right-inclusive boundary it is the first governed instant after the included valid_to. If the pinned Temporal Profile cannot derive either edge deterministically, admission SHALL fail closed rather than silently changing interval semantics.

An activation whose effective start precedes its canonical recording transaction time is retroactive. Any newly recorded authority-bearing lifecycle transition whose effective edge precedes that transition's own canonical recording transaction time is likewise retroactive. Such activation or transition SHALL be permitted only under a governed retroactivity decision conforming to ZYZ-CRF-7 §23.68.4. The system SHALL NOT silently convert apply delay or delayed lifecycle recording into retroactive authority.

A scheduled boundary whose authority and effective edge were already fixed in an earlier authoritative activation plan is not a new retroactive authority decision merely because its later boundary-processing event is recorded after the edge. The later event is transaction-time evidence that the pre-authorized boundary was processed; it SHALL NOT redefine the boundary.

The declared boundary semantics, status-before-activation, status-after-expiration, derived effective edges, activation- and transition-level retroactivity treatment, complete transaction boundaries, exact transaction-time governance and exact Temporal Profile binding SHALL be part of the activation plan, activation-plan digest, overlap evaluation, boundary-event processing, resolver evaluation and historical replay/reconstruction evidence.

3.6 Activation grants only Runtime authority

A successful activation establishes only that the exact released XBRL activation artefacts may participate in the approved Runtime Context.

It SHALL NOT by itself create:

• legal authority;
• methodological authority;
• PP-MAP approval;
• PP-MD purpose authorization;
• FOGE compilation authority;
• FOGE definition-publication authority;
• customer-display authority;
• external-publication authority;
• regulatory-filing authority; or
• redistribution authority.

3.7 HECATE validates; HECATE does not activate

HECATE MAY produce activation-admission conformance evidence.

A passing HECATE receipt SHALL NOT itself release artefacts or activate Runtime state.

The sequence is:

HECATE validation
      │
      ▼
activation eligibility evidence
      │
      ▼
separate activation authority
      │
      ▼
PP-ACT

3.8 Rights are evaluated, not inherited

Projection, registration or release rights evidence SHALL NOT be treated as runtime-activation permission merely because it supported an earlier lifecycle stage.

Before activation, the complete intended activation use SHALL pass the canonical PP-RLCPS Rights Gate over all applicable Rights Records, Rights Decisions, agreements, conditions and evidence.

3.9 Mapping authority remains separate

An active taxonomy release does not make every PP-MAP traversable.

For any mapped use, the exact effective PP-MAP/PP-MD gate defined by PP-SMCS and PP-RXF-01 SHALL still be evaluated for the intended purpose and direction.

Conceptually:

PP-ACT answers:
May this exact PP-REL-backed taxonomy activation participate in this Runtime Context?

PP-MAP / PP-MD answers:
May this exact semantic mapping be traversed for this exact purpose?

Both MAY be required. Neither substitutes for the other.

3.10 Publication remains separate

Runtime activation SHALL NOT imply FOGE definition publication, report publication, taxonomy publication, customer display, public API exposure, filing or redistribution.

Publication and activation remain separate constitutional transitions.

---

4. Authority ownership

Responsibility	Governing owner	Meaning
XBRL source/capture/projection/registration lineage	Pergamum Pulse	Proves exact technical-semantic evidence and custody
Projection Release	PP-CCPS / PP-REL	Releases validated artefacts for controlled use or later activation
Activation Request	PP-CCPS / PP-AR	Requests separate activation; creates no active state
Activation-admission validation	HECATE under approved profile/rules	Proves conformance only
Rights eligibility	PP-RLCPS Rights Gate	Determines permission for the exact intended activation use
Runtime activation authority	Constitutional Runtime / authorised governance	Creates activation authority
Activation Record	PP-ACT- under PP-CCPS	Preserves the authorised activation outcome
Runtime binding/projection	Runtime Control Plane	Makes PP-ACT efficiently resolvable without becoming authority
Runtime taxonomy resolution	Runtime resolver	Selects the one applicable PP-ACT-backed release
Historical reconstruction	Constitutional Temporal/Event Runtime	Reconstructs governed state across requested time dimensions
Mapping-purpose authority	PP-SMCS PP-MAP/PP-MD	Governs semantic traversal/use
Publication	Constitutional Publication Framework and applicable domain authority	Separate audience-facing authority

Pergamum Pulse MAY prove that a registered release is technically and evidentially eligible to be packaged into a governed PP-REL. It SHALL NOT silently cross from:

"this registered release satisfies the evaluated eligibility predicates"

into:

"this release is now operative in Runtime"

Only the canonical release-plus-activation path may do that.

---

5. Canonical release and activation objects

This profile SHALL reuse the existing canonical PP-CCPS objects rather than introducing an XBRL-specific activation authority family.

5.1 Projection Release — PP-REL-

For XBRL Runtime activation, a canonical PP-REL- SHALL exist before PP-AR may request activation.

The PP-REL SHALL preserve validated released artefacts and exact digests. Those released artefacts SHALL immutably bind, directly or through a governed manifest, at least:

• exact taxonomy_release_id;
• exact taxonomy registration event;
• exact taxonomy package/network digests required by the profile;
• exact activation-plan/manifest bytes or digest where applicable;
• exact validation receipts required for release;
• release channel;
• release authority; and
• provenance.

The XBRL taxonomy registry row is therefore evidence referenced by released artefacts, not the canonical PP-REL itself.

5.2 Activation Request — PP-AR-

PP-AR- requests activation and creates no active state.

For XBRL activation, the canonical request SHALL preserve the fields required by the existing PP-AR contract, including:

• exact PP-REL identity/version in release;
• exact released_artefacts and digests from that PP-REL;
• target environment;
• target current state;
• requested canonical scope;
• requested effective time;
• migration readiness;
• monitoring readiness;
• rollback readiness;
• requester;
• required activation authority; and
• approvals where applicable.

A future PP-XRA-compatible canonical PP-AR machine contract SHALL additionally provide an authoritative representation, directly or through a canonical versioned evidence/contract reference, for:

• exact registered taxonomy release;
• exact registration evidence;
• canonical Runtime Context identity/fingerprint or authorised projection;
• complete effective interval and boundary semantics;
• status before activation;
• status after expiration for finite intervals;
• deterministic effective-start and expiration boundary derivation;
• exact resolved Temporal Profile identity/version/fingerprint;
• reporting context;
• runtime capability/use;
• Runtime Bundle or equivalent runtime-state binding where applicable;
• consumer Module and Component;
• exact activation-plan digest;
• multiplicity-policy binding;
• any lifecycle transition whose existence/effective time is required for the activation to resolve deterministically;
• governed retroactivity decision/evidence for the activation and any newly recorded lifecycle transition where applicable;
• exact transaction-time assignment/system-of-record contract, including the executable pre-commit retroactivity guard;
• replay profile/equivalence governance; and
• profile-specific provenance.

Registration evidence SHALL NOT replace the canonical release or released_artefacts fields.

5.3 Activation Record — PP-ACT-

PP-ACT- is the authority-bearing activation outcome.

For an XBRL activation, the canonical PP-ACT SHALL preserve the fields required by the existing PP-ACT contract, including:

• exact Activation Request;
• exact canonical PP-REL identity/version in release;
• exact activated artefact references/digests;
• activating authority;
• activated-by actor/service;
• target environment;
• canonical scope;
• previous active state;
• new active state;
• effective time;
• monitoring;
• rollback window; and
• result.

The activated artefact digests SHALL match the released artefact digests. Any digest difference SHALL be treated according to PP-CCPS as a trust-blocking defect/incident condition.

If result = partially_active, the Activation Record SHALL identify the exact successful and failed scopes as required by PP-CCPS §41.2. The successful/failed partition is authority-relevant applicability evidence, not diagnostic metadata.

A future PP-XRA-compatible canonical PP-ACT machine contract SHALL additionally preserve authoritative evidence for:

• exact taxonomy release;
• exact registration event/evidence;
• exact activation-plan digest;
• exact Runtime Context binding;
• complete effective interval and boundary semantics;
• status before activation;
• status after expiration for finite intervals;
• exact effective-start/expiration boundary evidence;
• exact resolved Temporal Profile identity/version/fingerprint;
• actual canonical activation transaction time and transaction ordering evidence;
• transaction start and transaction end where applicable;
• recording system and recording Component;
• actor, Execution Identifier and recorded event;
• prior version and new version where applicable;
• complete transaction provenance;
• governed retroactivity evidence for the activation and newly recorded lifecycle transitions where applicable;
• exact multiplicity-policy binding where one is used;
• exact successful/failed scope partition for partial outcomes;
• HECATE evidence;
• Rights Gate evidence;
• replay governance/manifest references; and
• provenance.

5.4 Rollback Record — PP-RBK-

Rollback SHALL use the canonical PP-RBK- object rather than mutating a prior PP-ACT- record.

A rollback SHALL preserve the affected activation, target prior state, authority, effective time, validation and provenance required by PP-CCPS.

For PP-XRA lifecycle replay, canonical lifecycle-transition evidence—including revocation, effective-start and expiration evidence where applicable—SHALL also be capable of preserving transition edge semantics, affected resolution scope, transaction start/end where applicable, transition-level retroactivity evidence and any deterministic transition-order contract required by Section 14.

5.5 No new XBRL-specific activation authority object

This profile SHALL NOT introduce an XRA-*, XBRL-ACT-* or other parallel first-class activation authority object.

PP-XRA-01 governs how canonical PP-REL, PP-AR, PP-ACT and PP-RBK semantics are applied to registered XBRL taxonomy releases.

5.6 Current Core 1.0 canonical-schema compatibility blocker

The currently published Pergamum Pulse Core 1.0 machine schemas for PP-AR, PP-ACT and PP-RBK are closed contracts. In particular:

• activation-request.schema.json permits requested_effective_at but does not provide the PP-XRA effective interval, boundary semantics, pre-activation/post-expiration states, effective-boundary derivation, activation- or transition-level retroactivity evidence, exact transaction-time governance/transaction-boundary evidence, exact Temporal Profile binding, multiplicity-policy binding, planned lifecycle-transition binding, replay binding or activation-plan digest fields required by this profile;
• activation-record.schema.json permits effective_at and optional successful_scopes / failed_scopes, but does not conditionally require the exact scope partition for partially_active and does not provide an authoritative PP-XRA interval/boundary/pre-activation/post-expiration/retroactivity/complete-transaction-record/Temporal Profile/multiplicity/replay representation; and
• rollback-record.schema.json permits rolled_back_at but does not provide the complete lifecycle transition edge/order/resolution-scope, retroactivity and transaction-boundary evidence required for deterministic cutover, effective start, expiration, revocation or replay.

Therefore the existing Core 1.0 schemas are not yet sufficient to emit a conforming PP-XRA activation.

This architecture document SHALL NOT solve that incompatibility by:

• inserting undeclared properties into closed Core 1.0 objects;
• storing authority only in a derived runtime-binding table;
• inventing an XBRL-specific parallel activation authority object; or
• mutating the generic Core 1.0 schemas silently inside this profile.

Before runtime implementation, PP-CCPS and its canonical machine contracts SHALL be compatibly evolved/versioned, or an approved canonical extension mechanism SHALL be introduced, so the complete PP-XRA authority evidence can be represented authoritatively.

Until that prerequisite is satisfied, no implementation SHALL claim that a PP-XRA activation has been canonically recorded or is Runtime-active merely because a derived binding contains the extra fields.

---

6. XBRL activation plan

An XBRL Taxonomy Runtime Activation Plan is a deterministic machine-readable plan used by preflight and apply tooling.

The plan is not a first-class activation authority object. Its identity SHALL be established by content digest and its binding to an exact PP-AR and exact PP-REL.

Conceptually:

activation_plan:
  plan_version: 0.1.0

  projection_release:
    id: PP-REL-...
    version: 1.0.0
    released_artefacts:
      - artefact: <versioned-artefact-ref>
        digest: sha256:<64-hex>

  activation_request:
    id: PP-AR-...
    version: 1.0.0

  taxonomy_release:
    taxonomy_release_id: XBRL-ESRS-SET1-2023-12-22

  registration_binding:
    registration_event_id: <uuid>
    registration_plan_sha256: sha256:<64-hex>
    projection_manifest_sha256: sha256:<64-hex>
    taxonomy_network_digest: sha256:<64-hex>

  runtime_context_binding:
    mode: full_context | authorised_projection
    source_context_id: <context-id>
    source_context_version: <version>
    context_fingerprint: sha256:<64-hex>
    projection_fingerprint: null
    included_dimensions: []
    excluded_dimensions: []
    exclusion_rationale: []
    target_capability: xbrl_validation
    provenance: []

  scope:
    target_environment: production
    knowledge_scope: <registered-scope>
    jurisdictions: []
    tenant_scope: {}
    white_label_scope: {}
    modules: []
    components: []
    purposes: []
    runtime_capabilities: []

  reporting_context:
    framework: ESRS
    period_from: null
    period_to: null

  runtime_binding:
    runtime_bundle: null
    consumer_modules: []
    consumer_components: []

  temporal_profile_binding:
    profile_id: <canonical-temporal-profile-id>
    profile_version: <version>
    profile_fingerprint: sha256:<64-hex>
    resolved_by: CRP

  temporal:
    time_dimension: effective_time
    valid_from: <date-time>
    valid_to: null
    boundary_semantics: left_inclusive_right_exclusive
    status_before_activation: future_effective
    status_after_expiration: expired
    effective_start_transition_at: <derived-first-included-instant>
    expiration_transition_at: null

  retroactivity:
    mode: none | governed
    decision_authority_ref: null
    legal_or_policy_basis: null
    affected_historical_outcomes: []
    restatement_requirements: []
    notification_requirements: []
    provenance: []

  transaction_time_governance:
    contract_id: <canonical-transaction-time-contract-id>
    contract_version: <version>
    contract_fingerprint: sha256:<64-hex>
    system_of_record_id: <canonical-system-of-record-id>
    system_of_record_version: <version>
    system_of_record_fingerprint: sha256:<64-hex>
    recording_component_id: <component-id>
    observation_point: <governed-recording-or-commit-event>
    clock_source_id: <canonical-clock-source-id>
    clock_source_version: <version>
    clock_source_fingerprint: sha256:<64-hex>
    time_normalization_profile: <canonical-ref>
    precision: <governed-precision>
    granularity: <governed-granularity>
    transaction_order_contract:
      id: <canonical-transaction-order-contract-id>
      version: <version>
      fingerprint: sha256:<64-hex>
    retry_semantics: successful_canonical_record_only
    retroactivity_guard:
      mode: reserved_authoritative_time | atomic_commit_constraint
      contract_id: <canonical-retroactivity-guard-contract-id>
      contract_version: <version>
      contract_fingerprint: sha256:<64-hex>
      outcome_writer_fence:
        mode: shared_serialization | commit_revalidation
        contract_id: <canonical-outcome-writer-fence-contract-id>
        contract_version: <version>
        contract_fingerprint: sha256:<64-hex>
        impact_mutation_domain:
          selector_schema:
            id: <canonical-impact-selector-schema-id>
            version: <version>
            fingerprint: sha256:<64-hex>
          writer_identity_registry:
            id: <canonical-writer-identity-registry-id>
            version: <version>
            fingerprint: sha256:<64-hex>
          mutation_vocabulary:
            id: <canonical-mutation-vocabulary-id>
            version: <version>
            fingerprint: sha256:<64-hex>
          canonicalization_contract:
            id: <canonical-domain-canonicalization-contract-id>
            version: <version>
            fingerprint: sha256:<64-hex>
          affected_outcome_selector: <instance-valid-under-pinned-selector-schema>
          writer_class_ids: []
          mutation_class_ids: []
          domain_fingerprint: sha256:<64-hex>
    transaction_record_requirements:
      transaction_start: required
      transaction_end: required_where_applicable
      recording_system: required
      recording_component: required
      actor: required
      execution_id: required
      event: required
      prior_version: required_where_applicable
      new_version: required_where_applicable
      provenance: required

  replay_governance:
    replay_profile: EXACT
    constitution_id: REPLAY-CONSTITUTION
    constitution_version: 1.0.0
    constitution_fingerprint: sha256:<64-hex>
    manifest_schema_id: <canonical-replay-manifest-schema-id>
    manifest_schema_version: <version>
    manifest_schema_fingerprint: sha256:<64-hex>
    equivalence_contract:
      id: <canonical-exact-equivalence-contract-id>
      version: <version>
      fingerprint: sha256:<64-hex>
    manifest_required_temporal_evidence:
      - execution_id
      - effective_time_coordinate
      - as_recorded_transaction_boundary
      - transaction_sequence_or_snapshot_fingerprint

  multiplicity_policy:
    mode: fail_closed | governed_reduction
    contract: null
    # when mode = governed_reduction:
    # contract:
    #   id: <canonical-contract-id>
    #   version: <version>
    #   fingerprint: sha256:<64-hex>

  planned_lifecycle_transitions: []
  # when a lifecycle/boundary transition must change applicability for this activation to resolve:
  # - mode: preexisting | atomic_with_activation | scheduled_boundary
  #   affected_activation:
  #     id: PP-ACT-...
  #     version: <version>
  #   transition_type: effective_start | suspension | reinstatement | expiration | revocation | rollback | retirement | supersession | cutover
  #   transition_effective_at: <date-time>
  #   affected_scope: {}
  #   resulting_lifecycle_state: <state>
  #   authority_ref: <canonical-authority-ref>
  #   retroactivity:
  #     mode: none | governed
  #     decision_authority_ref: null
  #     legal_or_policy_basis: null
  #     affected_historical_outcomes: []
  #     restatement_requirements: []
  #     notification_requirements: []
  #     provenance: []
  #   transition_payload:
  #     # mandatory for atomic_with_activation; complete authority-selected payload for the transition type
  #     # suspension SHALL include every ZYZ-CRF-7 §23.68.10 field
  #     # revocation uses transition_effective_at as its canonical effective revocation time
  #     suspension_start: null
  #     expected_or_actual_end: null
  #     reason: null
  #     emergency_status: null
  #     reinstatement_policy: null
  #     revocation_decision: null
  #     future_use_prohibition: null
  #     historical_use_treatment: null
  #     affected_dependants: []
  #     transaction_time_assignment_ref: activation_plan.transaction_time_governance
  #     provenance: []
  #   transition_payload_fingerprint: sha256:<64-hex>
  #   transition_evidence_ref: null
  #   transition_evidence_fingerprint: null

  lifecycle_transition_semantics:
    edge_convention: post_transition_state_effective_at_derived_transition_instant
    simultaneous_transition_policy: require_pinned_order_contract_or_fail_closed
    transition_order_contract: null
    # mandatory whenever an order-sensitive collision exists:
    # transition_order_contract:
    #   id: <canonical-order-contract-id>
    #   version: <version>
    #   fingerprint: sha256:<64-hex>

  authority_boundary:
    creates_legal_authority: false
    creates_semantic_mapping_authority: false
    authorizes_customer_display: false
    authorizes_publication: false
    authorizes_regulatory_filing: false
    authorizes_redistribution: false

boundary_semantics is mandatory. The value shown above is illustrative of an explicit half-open interval; it SHALL NOT be inferred merely because a particular database or programming library uses that convention.

The temporal_profile_binding is also mandatory. CRP SHALL resolve the applicable Temporal Profile before authorization, and the plan SHALL pin the exact resolved identity/version/fingerprint rather than re-resolving a mutable profile later.

status_before_activation is mandatory for every activation. The plan SHALL include a transition_type: effective_start entry with mode: scheduled_boundary; its transition_effective_at SHALL be the first governed instant included by the interval, derived deterministically from valid_from, the declared left-boundary semantics and the pinned Temporal Profile's precision/granularity.

status_after_expiration is mandatory whenever valid_to is finite. In that case the plan SHALL also include a transition_type: expiration entry with mode: scheduled_boundary; its transition_effective_at SHALL be the first governed instant after the final included instant, derived deterministically from valid_to, the declared right-boundary semantics and the same pinned precision/granularity. Under a right-exclusive boundary this will ordinarily equal valid_to; under a right-inclusive boundary it will be the next governed instant after valid_to. A scheduled boundary is authorized with the activation itself; the boundary-event record may be emitted when the boundary is processed, but neither its existence nor its resulting lifecycle state is chosen later. If either boundary instant cannot be derived deterministically, admission SHALL block.

The activation-level retroactivity.mode default is none. If the activation's derived effective-start instant precedes the actual canonical transaction time at which activation authority is recorded, the activation is retroactive and mode SHALL be governed. The authorized plan SHALL then preserve the ZYZ-CRF-7 §23.68.4 decision authority, legal/policy basis, effective start, affected historical outcomes, restatement requirements, notification requirements and provenance. The actual transaction time remains observational and is captured at successful canonical persistence under transaction_time_governance.

Every newly recorded authority-bearing lifecycle transition SHALL apply the same test against its own transaction time. If transition_effective_at precedes that transition's authoritative recording time, its transition-level retroactivity.mode SHALL be governed and its exact ZYZ-CRF-7 §23.68.4 evidence SHALL be bound before authorization. This applies to backdated suspension, reinstatement, revocation, rollback, retirement, supersession and cutover, and to any other newly recorded transition capable of altering historical applicability/cardinality. A preexisting transition is re-proved from its already-authoritative evidence; a scheduled_boundary whose authority was fixed earlier by the activation interval does not acquire a new retroactivity decision merely because processing evidence is emitted later.

transaction_time_governance is mandatory for authoritative activation recording and for every lifecycle event whose transaction time is constitutionally significant. It SHALL bind the exact system of record, recording Component, observation point, Clock Source, normalization/precision/granularity, transaction-order contract, retry/abort semantics, executable retroactivity guard, outcome-writer fence and complete transaction-record requirements. A generic phrase such as canonical_persistence_time or a Clock Source alone is insufficient.

The retroactivity guard SHALL make the apply-time predicate executable. If observation_point is available before the irreversible commit point, reserved_authoritative_time MAY be used only where the governed system of record can reserve the exact authoritative transaction time/order that a successful commit will use; a failed or aborted transaction SHALL NOT make that reservation authoritative. If the authoritative observation point is the commit event itself, atomic_commit_constraint is mandatory: the same governed system-of-record transaction SHALL compare every newly recorded authority-bearing effective edge against the actual commit-time transaction value and SHALL abort the commit atomically whenever retroactivity.mode = none would be violated. A commit-only timestamp with no such atomic constraint is non-conforming because the caller cannot inspect it before commit and then truthfully claim the transaction was blocked on that value.

The outcome_writer_fence SHALL close the opposite side of the same race. Its impact_mutation_domain SHALL be machine-deterministic before it is fingerprinted. The plan SHALL pin: (1) an exact versioned selector schema defining the authoritative shape and semantics of affected_outcome_selector; (2) an exact versioned canonical registry for writer-class identities; (3) an exact versioned canonical vocabulary/registry for mutation-class identities; and (4) an exact versioned canonicalization contract defining the bytes that are hashed, including field inclusion, null handling, string/Unicode normalization, key ordering, list-versus-set semantics, deterministic ordering of set-valued identities, duplicate handling, timestamp normalization where applicable and digest algorithm/envelope. writer_class_ids and mutation_class_ids SHALL contain only exact registered canonical identities from those pinned registries; free strings, service-local enum values, inferred aliases and implementation-specific normalizations are prohibited.

The pinned mutation vocabulary SHALL be semantically complete for every operation capable of changing the authorized ZYZ-CRF-7 §23.68.4 impact analysis. That coverage SHALL include creation and non-additive changes such as correction, replacement/supersession, retraction, invalidation, reclassification, deletion or tombstoning where constitutionally permitted, and restatement/notification treatment changes. PP-XRA does not invent the machine tokens for those meanings: each meaning SHALL map to an exact approved registry identity before implementation. If a required writer identity, mutation identity, selector-schema construct or canonicalization rule is missing from the canonical registries, that is an implementation blocker requiring the applicable governed registry change/explicit approval; an implementation SHALL NOT silently invent or normalize a value merely to complete the domain.

Only after those bindings are resolved SHALL domain_fingerprint be computed from the canonicalized domain bytes. The fingerprint SHALL cover the selector schema identity/version/fingerprint, writer registry identity/version/fingerprint, mutation vocabulary identity/version/fingerprint, canonicalization-contract identity/version/fingerprint, the validated selector instance, and the deterministically ordered canonical writer and mutation identity sets. Two services consuming the same authorized plan SHALL therefore derive byte-identical domain material and the same fingerprint or fail closed.

The resulting conflict domain SHALL include every canonical execution, ingestion, correction, deletion/tombstone, retraction, invalidation, supersession/replacement, reclassification, restatement-treatment or notification-treatment writer capable of changing impact-set membership, the authoritative identity/version/status of an affected outcome, or the restatement/notification treatment compared to the authorization. Such a writer SHALL either participate in the same serialization boundary or atomically revalidate the relevant committed authority state and impact-treatment invariants at its own commit. A writer that began under an older authority snapshot SHALL NOT publish a stale result or treatment merely because it acquired work, a lock or a provisional order before the retroactive authority committed. If the relevant authority changed before the writer's canonical recording point, the writer SHALL abort/retry or recompute/re-evaluate under the newly committed authority according to the pinned Temporal Profile's late-arrival/correction policy and transaction-order contract.

A writer MAY be ordered constitutionally before the retroactive authority only where the governing transaction-order contract actually assigns that order and the exact writer mutation plus its resulting impact-set/restatement/notification state was included in the authorized §23.68.4 analysis. A reservation or transaction start alone SHALL NOT manufacture an earlier authoritative order after the retroactive authority has committed. Conversely, a normal writer that records after the retroactive authority and re-evaluates under that current authority is a later transaction, even if its reporting/effective coordinate is earlier; it SHALL NOT be mislabeled as an earlier as-recorded outcome merely to avoid the new authority.

Every constitutionally significant activation/lifecycle transaction SHALL additionally preserve the complete transaction record required by ZYZ-CRF-7 §23.70.1: transaction start; transaction end where applicable; recording system; recording Component; actor; Execution Identifier; event; prior version; new version; and provenance. The selected authoritative transaction_time/order point is part of that transaction record; it does not replace its start/end boundary.

The PP-XRA resolver is a deterministic governed component and SHALL use constitutional replay profile EXACT. HISTORICAL_REPLAY is the product evaluation mode; it is not a substitute replay profile. The plan SHALL pin the exact Replay Constitution, replay-manifest schema and exact-equivalence contract. Every replayable activation/resolution execution SHALL produce an immutable replay manifest that includes the original Execution Identifier, original effective-time coordinate(s), the as-recorded transaction-time boundary/snapshot and sufficient transaction-order evidence to reproduce what the system knew at that execution.

Where multiplicity_policy.mode is governed_reduction, the exact multiplicity-reducing contract identity, version and immutable fingerprint SHALL be present. Where no such governed contract exists, mode SHALL be fail_closed and overlap that leaves resolver multiplicity SHALL block.

Where the candidate activation would remain ambiguous unless another activation is ended, narrowed, started, reinstated, expired or revoked, the required lifecycle/boundary transition SHALL be part of planned_lifecycle_transitions. It SHALL either:

1. reference an already-authoritative lifecycle transition and pin its exact evidence/fingerprint for re-proof;
2. be an exact authorized planned transition to be persisted atomically with the activation; or
3. for effective start or finite interval expiration, be an exact scheduled_boundary transition whose effective time and resulting state are fixed by the authorized interval and boundary-derivation semantics.

Resumption of a suspended activation SHALL use the canonical machine transition type reinstatement. resume/resumption describe the lifecycle intent; they SHALL NOT create a second synonymous machine transition value.

For every atomic_with_activation transition, the plan SHALL bind the complete authority-selected transition semantics before authorization. Where a transition contains a constitutionally observational field that can exist only when the system records the event, the plan SHALL instead bind the exact transaction-time governance contract that will produce that field and the canonical evidence SHALL preserve the actual observed value, transaction start/end and transaction ordering evidence.

For an atomic suspension, that payload SHALL include all suspension semantics required by ZYZ-CRF-7 §23.68.10, including suspension start, expected or actual end, authority, reason, affected scope, emergency status, reinstatement policy and provenance. Apply SHALL NOT choose or change any of those semantics after plan authorization.

For an atomic reinstatement, the payload SHALL bind at least the governing suspension evidence, satisfaction of the applicable reinstatement policy, reinstatement effective time, affected scope, resulting operative state, authority and provenance. Apply SHALL NOT invent or change those reinstatement semantics after plan authorization.

For an atomic revocation, transition_effective_at is the single canonical effective instant and SHALL be the effective revocation time required by ZYZ-CRF-7 §23.68.9. A second independent effective-time value SHALL NOT exist. The plan SHALL bind the revocation decision, authority, future-use prohibition, historical-use treatment, affected dependants, provenance, transition-level retroactivity treatment and exact transaction-time governance contract. The actual transaction_time SHALL be assigned only when the governed system of record successfully records the revocation under the pinned guard/observation semantics, and SHALL then be preserved with its complete transaction record and transaction-order evidence in canonical revocation evidence.

Where the activation transaction contains any order-sensitive concurrent or constitutionally same-time lifecycle transitions within the resolver collision domain, transition_order_contract SHALL be non-null and SHALL pin the exact canonical order-contract identity, version and immutable fingerprint before authorization. A generic policy such as require_pinned_order_contract_or_fail_closed is not itself the tie-breaker contract.

The activation plan SHALL NOT rely on an unplanned future cutover, effective start, suspension, reinstatement, expiration, revocation, rollback, retirement or supersession event to make resolver cardinality become valid after authorization.

A conforming machine schema SHOULD be introduced under the Pergamum Pulse Core schema tree only after this architecture is accepted and the canonical PP-CCPS compatibility requirement in Section 5.6 is resolved.

---

7. Runtime Context binding and fingerprints

7.1 Canonical Runtime Context requirement

ZYZ-CRF requires every authoritative Runtime Context to possess a deterministic Context Fingerprint.

Every XBRL activation SHALL therefore bind to either:

• the complete canonical Runtime Context identity/version plus Context Fingerprint; or
• an authorised projection of that Runtime Context.

An implementation SHALL NOT create a second, weaker notion of Runtime Context merely for XBRL activation.

7.2 Authorised Runtime Context projection

Where only a subset of dimensions is constitutionally relevant to the activation capability, the projection SHALL conform to ZYZ-CRF-12 and preserve:

source Context Identifier
included dimensions
excluded dimensions
reason for exclusion
target capability
projection fingerprint
provenance

The projection SHALL be authorised. Omission by convenience, implementation limitation or caller preference is not an authorised projection.

A dimension MAY be excluded only where the governing Runtime Profile/authority establishes that the dimension is irrelevant to the target capability.

7.3 Canonical scope envelope

Within that Runtime Context binding, activation SHALL reuse the canonical Pergamum Pulse scope/isolation envelope for:

• knowledge scope;
• jurisdictions;
• tenant scope;
• white-label scope;
• Modules;
• Components;
• purposes; and
• security boundaries.

XBRL activation MAY add profile-specific selector dimensions such as taxonomy family, declared runtime capability, reporting context and consumer identity, but these SHALL supplement rather than replace constitutional Runtime Context semantics.

7.4 Selector scope fingerprint

A selector fingerprint MAY be used as an indexing and conflict-detection aid.

It SHALL NOT replace the canonical Runtime Context Fingerprint or authorised projection fingerprint.

The selector fingerprint SHOULD be computed from deterministic canonical JSON containing, where applicable:

canonical Context Fingerprint or authorised projection fingerprint
target_environment
taxonomy_family/framework
knowledge_scope
tenant_scope
white_label_scope
jurisdiction
runtime_capability / declared use
consumer_module_id
consumer_component_id
Runtime Bundle identity/version
reporting-context selector
security-boundary references

The result SHOULD be represented as:

selector_scope_sha256 = sha256:<64-hex>

Two different source Runtime Contexts SHALL NOT be treated as equivalent merely because a smaller set of selector fields happens to hash to the same value.

7.5 Activation contract digest

The complete activation-plan digest SHOULD cover at minimum:

PP-REL identity/version
released artefact references/digests
PP-AR identity/version
exact taxonomy_release_id
registration_event_id
registration_plan_sha256
projection_manifest_sha256
taxonomy_network_digest
source Runtime Context identity/version
Context Fingerprint or authorised projection fingerprint
included/excluded projection dimensions where applicable
selector_scope_sha256
Temporal Profile identity/version/fingerprint
time dimension
valid_from
valid_to
boundary_semantics
status_before_activation
status_after_expiration
derived effective-start transition instant
derived expiration transition instant where finite
activation retroactivity mode and governed retroactivity evidence where applicable
transaction-time governance contract identity/version/fingerprint
system-of-record / recording Component / observation-point semantics
Clock Source identity/version/fingerprint
normalization / precision / granularity
transaction-order contract identity/version/fingerprint
retry/abort semantics
retroactivity-guard mode/contract identity/version/fingerprint
outcome-writer-fence mode/contract identity/version/fingerprint
impact-mutation selector schema identity/version/fingerprint
impact-mutation writer-identity registry identity/version/fingerprint
impact-mutation mutation-vocabulary identity/version/fingerprint
impact-mutation canonicalization contract identity/version/fingerprint
impact-mutation validated selector instance
impact-mutation canonical writer-class identity set
impact-mutation canonical mutation-class identity set
impact-mutation domain fingerprint
transaction-record start/end capture requirements
Replay Constitution identity/version/fingerprint
replay profile = EXACT
replay-manifest schema identity/version/fingerprint
exact replay-equivalence contract identity/version/fingerprint
required replay-manifest temporal evidence
multiplicity-policy mode
multiplicity contract identity/version/fingerprint where applicable
planned lifecycle-transition mode
planned affected activation identity/version
planned transition type/effective time/affected scope/resulting state
planned transition authority reference
transition-level retroactivity mode and complete governed evidence where applicable
complete authority-selected atomic transition payload or immutable transition-payload fingerprint
preexisting transition evidence identity/fingerprint where applicable
lifecycle transition edge convention
simultaneous-transition policy
transition-order contract identity/version/fingerprint where order-sensitive collisions exist
Rights Gate evidence fingerprint
HECATE receipt fingerprint
Runtime Bundle identity/version
activation-authority fingerprint

For an atomic_with_activation suspension, the digested transition payload SHALL cover the complete suspension contract required by ZYZ-CRF-7 §23.68.10, including suspension start, expected/actual end, authority, reason, affected scope, emergency status, reinstatement policy and provenance.

For an atomic_with_activation reinstatement, the digested transition payload SHALL cover the governing suspension evidence, satisfaction of the applicable reinstatement policy, reinstatement effective time, affected scope, resulting operative state, authority and provenance.

For an atomic_with_activation revocation, the digested transition semantics SHALL cover the revocation decision, authority, canonical effective instant in transition_effective_at, future-use prohibition, historical-use treatment, affected dependants, provenance, exact transition-level retroactivity semantics and the exact transaction-time governance contract. The pre-authorization digest SHALL NOT contain a fabricated literal transaction_time; canonical post-apply revocation evidence SHALL contain the actual recording time, complete transaction boundary and transaction-order evidence generated under that contract.

For every newly recorded atomic_with_activation lifecycle transition, if the authorized effective edge can precede the transition's authoritative recording time, the plan digest SHALL bind either retroactivity.mode: governed with the complete ZYZ-CRF-7 §23.68.4 evidence or a mode: none predicate that is enforced by the exact pinned retroactivity guard at apply/commit.

For a scheduled_boundary effective start, the digest SHALL bind valid_from, declared left-boundary semantics, status_before_activation, the exact first-included transition instant, resulting operative state and authority derivation from the authorized activation interval.

For a scheduled_boundary expiration, the digest SHALL bind the finite valid_to, declared right-boundary semantics, status_after_expiration, exact first-excluded transition instant, resulting state and authority derivation from the authorized activation interval.

For governed retroactivity, the digest SHALL bind the complete ZYZ-CRF-7 §23.68.4 authority-selected evidence other than observational actual transaction timestamps/end values that can exist only at runtime; those values are generated under the digested transaction-time governance contract and preserved in canonical evidence. The exact outcome-writer-fence contract and every canonical impact_mutation_domain semantics binding are also digest-bound because they determine which operations are inside the protected mutation domain and exactly which bytes define its fingerprint. A bare domain hash without the pinned selector schema, canonical writer identities, canonical mutation vocabulary and canonicalization contract SHALL NOT be accepted as sufficient authority evidence.

The result SHOULD be represented as:

activation_plan_sha256 = sha256:<64-hex>

A multiplicity, Temporal Profile, boundary-derivation, activation/transition retroactivity, transaction-time, retroactivity-guard, outcome-writer-fence, impact-mutation-domain schema/registry/vocabulary/canonicalization rule, replay-equivalence, transition-order, planned lifecycle transition or lifecycle-semantics rule that can alter which PP-ACT resolves or how its historical output is verified SHALL NOT be mutable outside the authorized plan digest.

7.6 Fingerprint non-transitivity

A matching selector fingerprint proves only selector identity under the governed selector construction.

It SHALL NOT by itself prove:

• Runtime Context equivalence;
• scope non-intersection;
• rights equivalence;
• temporal equivalence; or
• activation authority.

---

8. Scope intersection, interval semantics and resolver multiplicity

8.1 Exact selector equality is insufficient

Conflict detection SHALL NOT be limited to activations with identical selector_scope_sha256 values.

Two different scope encodings may intersect semantically. Examples include:

global tenant scope          ∩ selected tenant scope       != empty
all jurisdictions            ∩ EU                          != empty
global white-label scope     ∩ one white-label operator    != empty
all consumers                ∩ one Component               != empty
broad reporting-period rule  ∩ one reporting period        != empty

8.2 Intersection test

Admission SHALL determine whether two candidate activation selectors can match at least one common authoritative Runtime Context.

The intersection test SHALL consider all material governed dimensions, including where applicable:

• Runtime Context / authorised projection;
• environment;
• knowledge scope;
• tenant scope;
• white-label scope;
• jurisdiction;
• Module;
• Component;
• declared use/capability;
• Runtime Bundle;
• reporting context;
• security boundary; and
• other capability-specific dimensions.

8.3 Interval-boundary-aware temporal overlap

If semantic scope intersection is non-empty, the activation layer SHALL test effective-time overlap using the declared boundary semantics of both intervals, the exact pinned Temporal Profiles and the derived first-included/first-excluded effective edges.

The test SHALL NOT infer closed, open or half-open behavior from implementation defaults or re-resolve a newer Temporal Profile version.

For example, if both activations explicitly use left-inclusive/right-exclusive intervals:

activation A = [2026-09-15T00:00Z, 2026-10-01T00:00Z)
activation B = [2026-10-01T00:00Z, 2026-11-01T00:00Z)

then the intervals do not overlap at 2026-10-01T00:00Z; A's expiration transition is effective at that first-excluded instant while B's effective-start transition may be effective at that first-included instant.

For a right-inclusive interval such as [2026-09-15, 2026-10-01] at governed day granularity, 2026-10-01 remains included. The expiration transition is therefore the first governed instant after that included boundary, not the included valid_to itself. Equivalent logic applies to a left-exclusive valid_from.

If another resolver-affecting event is constitutionally same-time and ordering can change the result, Section 14.5 ordering semantics apply.

If declared boundary semantics would make two activation intervals include the same governed instant, they overlap and admission SHALL evaluate resolver multiplicity accordingly.

8.4 Resolver multiplicity is the admission invariant

Admission SHALL reject or deterministically resolve every semantically intersecting, temporally overlapping activation combination that could produce more than one applicable authorised activation for the same Runtime Context and effective time.

This rule applies regardless of whether the underlying taxonomy releases are:

• different;
• identical;
• considered compatible; or
• semantically equivalent for some downstream purpose.

Release compatibility alone SHALL NOT permit overlapping activation authority.

A same-release duplicate activation is still a second applicable activation unless an explicit governed coalescing, precedence or coexistence contract reduces the resolver result to exactly one authoritative activation.

When cardinality becomes valid only because another activation will be ended, narrowed, started, reinstated, expired or revoked, admission SHALL evaluate the projected post-transaction/boundary state defined by the exact planned lifecycle/boundary transition in Section 6, while separately proving that the state transition cannot expose an ambiguous active state.

8.5 Multiplicity-reducing contracts are pinned authority inputs

Any precedence, coexistence, coalescing or other multiplicity-reducing contract that can change resolver cardinality or select one PP-ACT over another SHALL be treated as an authority-relevant input.

Where such a contract is used:

• its canonical identity SHALL be pinned;
• its exact version SHALL be pinned;
• its immutable fingerprint SHALL be pinned;
• the binding SHALL be included in the authorized activation-plan digest;
• apply SHALL re-prove the exact binding;
• the resolver SHALL use the exact pinned contract rather than a mutable current/latest rule; and
• historical replay SHALL preserve and evaluate the exact contract that governed the original result.

If the contract changes materially, the prior activation authorization SHALL NOT silently authorize the changed resolver behavior. A new governed decision/activation transition is required where the changed rule would alter cardinality, selected authority or scope.

Where no exact pinned multiplicity-reducing contract exists, the default is fail closed.

8.6 Broad-over-narrow precedence is not implicit

A broad activation SHALL NOT automatically lose to, override or defer to a narrower activation unless a governed precedence rule explicitly says so and the exact rule is pinned under Section 8.5.

Without such a rule, both are applicable and the state is ambiguous.

---

9. Reporting and temporal context

9.1 Reporting time is not activation time

The resolver SHALL distinguish activation effective time from reporting period/context and transaction time.

Example:

temporal_profile_binding:
  profile_id: <canonical-temporal-profile-id>
  profile_version: <version>
  profile_fingerprint: sha256:<64-hex>

activation_time:
  valid_from: 2026-09-15T00:00:00Z
  valid_to: 2026-12-31T00:00:00Z
  boundary_semantics: left_inclusive_right_exclusive
  status_before_activation: future_effective
  status_after_expiration: expired

reporting_context:
  framework: ESRS
  period_from: 2026-01-01
  period_to: 2026-12-31

The activation interval's boundary semantics, pre-activation/post-expiration states, derived effective edges and exact Temporal Profile are part of the governed temporal authority context and SHALL remain available for overlap testing, boundary-event processing, bitemporal evaluation and replay.

9.2 Historical and amendment workflows

A newer taxonomy release MAY become active for new reporting contexts while an older release remains historically resolvable for:

• prior reporting periods;
• amended filings;
• correction workflows;
• exact historical replay of a prior execution;
• current historical reconstruction under ZYZ-CRF-7 §23.71;
• evidence reconstruction;
• assurance replay; or
• tenant cohorts not yet migrated.

A newer registration or activation SHALL NOT erase historical activation state.

Exact historical replay and current historical reconstruction are not the same operation. Exact replay reproduces what the system knew for a specific original execution under its original as-recorded transaction boundary. Historical reconstruction may answer what the governed system now understands to have been effective at a past instant, including later-recorded corrections or retroactive events when the applicable policy permits them.

---

10. Canonical PP-RLCPS Rights Gate

10.1 Affirmative permission is required

Every material activation SHALL pass the canonical PP-RLCPS Rights Gate over all applicable rights evidence.

The gate SHALL NOT be reduced to checking one PP-RGT row, one historical permission flag or the absence of a block outcome.

Activation admission requires an outcome that affirmatively permits the exact intended activation context.

At minimum:

• Pass is authorising for the evaluated context;
• Pass with Conditions is authorising only when every applicable condition is satisfied and preserved;
• Internal Use Only is authorising only where the exact requested activation remains within that internal-use boundary and all conditions are satisfied;
• Restricted Audience is authorising only where the exact requested activation remains within the permitted audience and all conditions are satisfied;
• Legal Review Required is non-authorising;
• Additional Permission Required is non-authorising;
• Block is non-authorising;
• Quarantine is non-authorising; and
• Unable to Determine is non-authorising.

The implementation SHALL NOT infer permission from any outcome that does not affirmatively authorize the intended purpose, audience, territory, channel, duration, processing type, tenant/white-label scope and other applicable rights dimensions.

10.2 Conditions remain part of authority

Where a permitting Rights Gate outcome contains conditions, those conditions SHALL be bound into activation evidence and enforced for the duration of the activation.

A condition change that materially alters permission SHALL trigger impact analysis and, where current operability is affected, suspension, revocation, rollback, retirement or a new governed activation decision as appropriate.

10.3 Activation permission is not downstream publication permission

A Rights Gate that permits runtime activation SHALL NOT be cached or interpreted as permission for later materially distinct uses.

Customer display, external publication, filing, public API exposure and redistribution SHALL each satisfy their own applicable Rights Gate and separate authority requirements at time of use.

---

11. Rights semantics over time

11.1 Historical activation evidence remains immutable

If a Rights Record expires or is revoked after an activation occurred, the historical PP-ACT remains immutable evidence that the activation decision occurred under the evidence then evaluated.

It SHALL NOT be rewritten or deleted to make history resemble current permission state.

11.2 Current operational resolution requires current eligibility

For a current operational resolution, historical PP-ACT existence is insufficient when an applicable present-day rights condition has expired, been revoked or otherwise become non-authorising.

Conceptually:

historical PP-ACT exists       = true
current rights eligibility     = non-authorising
current operational resolution = NOT_ACTIVE / BLOCKED_RIGHTS

11.3 Historical replay is as-recorded, not hindsight reconstruction

For exact historical replay, the resolver SHALL reconstruct lifecycle, rights and other authority evidence using both the original effective-time coordinate and the original execution's as-recorded transaction-time boundary.

A later-recorded expiration event, suspension, reinstatement, revocation, rollback, retirement, supersession, rights change, correction or retroactive decision SHALL NOT be introduced into exact replay if it was not yet recorded within the original execution's transaction snapshot, even if its effective time precedes the original effective-time coordinate. Such later evidence belongs to later provenance and may affect a separate current historical reconstruction.

The current authority to perform the replay is a separate question and SHALL be evaluated under current access, security and rights rules.

Conceptually:

original execution effective time     = T_eff
original as-recorded boundary          = T_tx
exact replay evidence                  = recorded by T_tx
later retroactive correction           = excluded from exact replay input
current historical reconstruction      = may include it under governed policy
current permission to replay           = evaluated separately now

A current replay-access denial SHALL prevent access to or execution of the replay without falsifying the historical result.

---

12. HECATE activation-admission boundary

The activation gate SHALL require the applicable HECATE conformance profile and receipt where mandated.

The receipt SHOULD pin:

• target versions;
• rule/profile versions;
• evidence snapshot;
• findings;
• outcome;
• digest/signature where required; and
• validity/expiry rules.

A passing HECATE receipt is eligibility evidence only.

The sequence is:

HECATE pass
   ↓
activation-admission eligibility
   ↓
separate authority decision
   ↓
PP-ACT

HECATE SHALL NOT create release authority, activation authority, legal authority, rights permission or publication authority.

---

13. Activation admission gate

An activation SHALL fail closed unless every mandatory predicate passes.

13.1 Canonical PP-REL proof

The gate SHALL prove that:

• the exact PP-REL identity/version exists;
• the PP-REL is the release referenced by PP-AR;
• the requested released artefacts exactly match the PP-REL artefacts;
• released artefact digests are exact;
• required release validation receipts exist; and
• release authority/channel are compatible with the requested activation.

13.2 Registered and sealed taxonomy proof

The gate SHALL prove that:

• the exact taxonomy_release_id exists;
• the released artefacts bind that exact taxonomy release;
• exact registration evidence exists;
• the registration event is immutable/sealed;
• registration-plan and projection-manifest digests match where required;
• taxonomy package/network digests match expected evidence; and
• no post-registration mutation is accepted as equivalent.

13.3 Canonical Runtime Context proof

The gate SHALL prove that the activation is bound to:

• a complete authoritative Runtime Context with Context Fingerprint; or
• a valid authorised projection preserving the ZYZ-CRF-12 projection contract.

Incomplete or unauthorized projection shall fail closed.

13.4 Canonical repository/provenance proof

Where the plan or identity depends on canonical Git-controlled registry/configuration, preflight and apply SHALL independently prove the expected canonical repository, branch/commit, path and digest.

A stale, crafted or uncommitted configuration SHALL NOT create activation authority.

13.5 Source/capture eligibility

The gate SHALL confirm that relevant source/capture state has not become invalid for the intended activation due to revocation, withdrawal, supersession or another governed blocking condition.

13.6 HECATE validation

Required HECATE activation-admission evidence SHALL be valid for the exact target versions, context and activation plan.

13.7 PP-RLCPS Rights Gate

The canonical Rights Gate SHALL return an outcome that affirmatively permits the exact activation context under Section 10.

Anything less SHALL fail closed.

13.8 Explicit activation authority

The requested activation SHALL be approved by the authority required for the declared environment, scope, consumer, capability and risk class.

Technical database permission is not activation authority.

13.9 Runtime compatibility

Where a Runtime Bundle, Runtime Manifest, consumer contract or Component version is part of the approved context, compatibility SHALL be verified before activation.

13.10 Temporal, bitemporal and replay profile proof

CRP SHALL resolve the applicable Temporal Profile before authorization.

The gate SHALL prove the exact canonical Temporal Profile identity, version and immutable fingerprint bound into the activation plan. Admission SHALL fail if the profile cannot be resolved deterministically, if the pinned profile is unavailable, or if a different current/latest profile would be substituted at apply time.

Admission SHALL prove that status_before_activation is declared, that the scheduled effective-start boundary is the exact first included governed instant under the pinned boundary/precision/granularity semantics, and—when finite—that status_after_expiration is declared and the scheduled expiration boundary is the exact first excluded governed instant. If either edge cannot be derived deterministically, admission SHALL block.

Admission SHALL prove the exact transaction-time governance contract, including system of record, recording Component, observation point, Clock Source, normalization/precision/granularity, transaction-order contract, retry semantics, retroactivity guard, outcome-writer fence and complete transaction-record requirements. If commit is the authoritative observation point, admission SHALL require an atomic_commit_constraint; otherwise, any reserved_authoritative_time mode SHALL prove that the successful record will use exactly the reserved authoritative time/order.

For every impact_mutation_domain, admission SHALL additionally prove all machine-semantics bindings before accepting domain_fingerprint: the exact selector-schema identity/version/fingerprint; exact canonical writer-identity registry identity/version/fingerprint; exact canonical mutation-vocabulary identity/version/fingerprint; exact canonicalization-contract identity/version/fingerprint; selector-instance validity under that schema; and membership of every writer_class_id and mutation_class_id in the pinned registries. The canonicalization contract SHALL deterministically define the hashed bytes and ordering semantics. Admission SHALL fail closed if different conforming consumers could produce different domain bytes/fingerprints, if a local/unregistered identity is present, or if a constitutionally possible operation capable of changing the §23.68.4 impact analysis—including deletion/tombstoning where permitted—is not mapped to an exact covered canonical mutation identity and writer identity.

Admission SHALL also prove that the resolver replay governance is pinned to constitutional profile EXACT, with exact Replay Constitution, replay-manifest schema and equivalence-contract identity/version/fingerprint. A product mode named HISTORICAL_REPLAY SHALL NOT be treated as the constitutional replay profile.

13.11 Scope-intersection, temporal-overlap, planned-transition and multiplicity check

The gate SHALL compare the candidate activation against all potentially applicable existing activations using:

1. semantic scope intersection;
2. effective-time overlap under each activation's declared boundary semantics, pinned Temporal Profile and derived first-included/first-excluded edges;
3. exact preexisting, atomic or scheduled lifecycle/boundary transitions—including effective start, expiration, reinstatement and revocation—whose effective result changes applicability; and
4. final resolver cardinality after those exact transitions and any exact pinned governed precedence/coexistence/coalescing rule.

Admission SHALL fail if there exists any Runtime Context/effective-time combination in the candidate scope for which more than one activation would remain applicable after the exact authorized transitions and governed multiplicity rules are applied.

This requirement applies even where the overlapping activations reference the same or compatible taxonomy release.

It SHALL NOT limit conflict detection to equal selector fingerprints or to releases classified as incompatible.

If admission depends on a lifecycle transition that does not already exist authoritatively, that exact transition SHALL be authorized as part of the activation plan and SHALL be eligible for atomic persistence or scheduled-boundary execution under Section 18.4. An unplanned future transition SHALL NOT be assumed.

For revocation, admission SHALL prove that transition_effective_at is the sole effective revocation instant and that no conflicting second effective-time value exists. If an atomic revocation participates, admission SHALL also prove the exact transaction-time governance and transition-retroactivity contracts rather than a fabricated future transaction timestamp.

If multiple planned transitions are order-sensitive within the resolver collision domain, admission SHALL prove that the activation plan pins the exact transition-order contract identity/version/fingerprint. If an atomic suspension, reinstatement or revocation participates, admission SHALL also prove that its required payload/derivation evidence is included in the authorized plan.

13.12 Retroactivity gate

The activation plan SHALL declare activation-level retroactivity.mode; every newly recorded authority-bearing planned lifecycle transition SHALL likewise declare its own transition-level retroactivity.mode.

Where the requested/derived activation effective start is already earlier than the earliest possible governed activation transaction time, admission SHALL require mode: governed and complete ZYZ-CRF-7 §23.68.4 evidence before authorization.

Where any planned atomic_with_activation lifecycle transition has an effective edge already earlier than the earliest possible governed transaction time for that transition, admission SHALL require transition-level mode: governed and complete ZYZ-CRF-7 §23.68.4 evidence before authorization.

Where an activation or transition is future-effective at admission but becomes earlier than its actual canonical transaction time because apply is delayed, apply SHALL reclassify that activation or transition as retroactive. It SHALL NOT commit under the relevant mode: none; a new governed retroactivity decision and activation authorization are required unless the already-authorized plan contains the complete governed retroactivity semantics.

For mode: governed, completeness is evaluated again at the guarded actual transaction boundary, not frozen at the earlier authorization instant. Apply SHALL recompute the exact set of affected historical outcomes created by the retroactive effective edge through the candidate authoritative transaction time and SHALL compare that set, together with its restatement and notification coverage, to the exact §23.68.4 evidence bound into the authorized plan digest. If apply delay, concurrent execution or any other intervening activity has added, removed, replaced, corrected, retracted, invalidated, reclassified or otherwise changed an affected historical outcome or its authoritative identity/version/status, or has changed the required restatement or notification treatment, the old authorization is stale: the transaction SHALL abort and a refreshed deterministic plan/digest plus new governed retroactivity authorization SHALL be required. A previously complete governed decision SHALL NOT be treated as open-ended permission for outcomes or treatment states that did not exist or were not covered when it was authorized.

Before that protected impact-set snapshot is taken, apply SHALL establish the exact plan-bound outcome_writer_fence over the complete canonical impact_mutation_domain. The fence SHALL use the exact selector schema, writer registry, mutation vocabulary, canonicalization contract and canonical identities authorized in the plan; reinterpreting aliases, service-local enums or implementation defaults is prohibited. The domain SHALL cover every canonical writer/operation that can change impact-set membership, affected-outcome identity/version/status, or the restatement/notification treatment compared with the authorized §23.68.4 evidence. The fence SHALL already prevent, defer or commit-revalidate every such mutation while the impact set and treatment coverage are being recomputed. Taking the snapshot first and establishing the fence afterward, fencing only operations that can add outcomes, or omitting a covered deletion/tombstone mutation because one service uses a different local name is non-conforming.

The impact-set revalidation itself SHALL be race-safe. Under reserved_authoritative_time, the affected-outcome and treatment domain SHALL be re-evaluated through the exact reserved transaction boundary only after the writer fence is active, while serialization/locking prevents any covered mutation from changing membership, outcome authority state or restatement/notification treatment before successful commit. Under atomic_commit_constraint, the same governed commit SHALL establish/enforce the writer fence before or atomically with the protected impact-set/treatment evaluation and SHALL either evaluate the affected-outcome set/restatement/notification coverage using the actual authoritative commit boundary or enforce an equivalent serialization invariant; if it cannot atomically prove that the authorized impact analysis remains complete and unchanged, the commit SHALL fail closed.

Closing the activation-side guard is not sufficient. Every canonical writer/operation whose authoritative result can mutate the governed impact set or its restatement/notification treatment SHALL obey the exact plan-bound outcome_writer_fence. Under shared_serialization, such writers participate in the same conflict domain and, after any wait/retry, re-read the committed authority state before they may record. Under commit_revalidation, the writer's own canonical commit atomically proves that the authority state used to produce the mutation is still current for its effective context and that the mutation does not invalidate the accepted §23.68.4 impact analysis. If a writer began before the retroactive activation/transition committed but attempts to record afterward, and the authority state changed while it was in flight, it SHALL abort/retry or recompute/re-evaluate under the new authority before recording. A stale pre-activation snapshot SHALL NOT be grandfathered merely because work began earlier.

Where a delayed writer is intentionally to retain transaction order before the retroactive authority, that order SHALL come from the exact governing transaction-order contract, and the exact canonical mutation identity, writer identity and resulting outcome/restatement/notification state SHALL already be covered by the authorized §23.68.4 analysis. If it was not covered, the writer SHALL fail closed and the retroactivity decision SHALL be refreshed before such prior-order recording can become authoritative. A provisional timestamp, reservation, queue position, transaction start or pre-existing lock acquisition SHALL NOT independently establish constitutional priority.

After the retroactive authority has committed, a new or retried writer that records later SHALL resolve and use the current committed authority for its effective context and SHALL re-evaluate any impact-set/restatement/notification mutation against that authority. The fact that its reporting period or other effective coordinate precedes the authority's transaction time does not permit the writer to masquerade as an earlier as-recorded outcome. Where the applicable Temporal Profile treats the data as late-arriving or corrective, its late-arrival/correction policy and provenance requirements apply in addition to the current authority revalidation.

A governed retroactive activation or lifecycle transition SHALL preserve:

• decision authority;
• legal or policy basis;
• effective start/effective transition edge;
• actual transaction time once recorded;
• affected historical outcomes;
• restatement requirements;
• notification requirements; and
• provenance.

The apply path SHALL enforce this predicate through the pinned transaction_time_governance.retroactivity_guard; it SHALL NOT depend on reading a commit timestamp after an irreversible commit. Commit may be the authoritative observation point only when an atomic commit constraint uses that same authoritative value to reject the transaction before it becomes committed. Otherwise the system of record must reserve the exact authoritative time/order before the irreversible point and use those exact values on successful commit.

Retroactivity SHALL NOT rewrite the historical transaction record of what the platform knew before the retroactive activation/transition was recorded.

13.13 Canonical authority-carrier compatibility

Before a PP-ACT may be created, the canonical PP-CCPS machine contracts in force SHALL be capable of authoritatively representing the PP-XRA evidence required by Sections 5, 6, 7, 8 and 14.

A derived runtime binding SHALL NOT compensate for a canonical activation object that cannot carry or canonically reference the required authority evidence.

Until Section 5.6 is resolved by canonical schema evolution or an approved canonical extension mechanism, this predicate fails closed.

13.14 Rollback readiness

Where rollback is required, the gate SHALL prove that rollback procedures, target prior state and verification steps are available.

---

14. Activation lifecycle

14.1 Event-sourced authority

Mutable lifecycle status SHALL NOT be the constitutional source of truth.

Canonical history SHALL be reconstructable from immutable PP-REL, PP-AR, PP-ACT, PP-RBK and related evidence plus effective-time and complete transaction-time rules.

Every constitutionally significant activation/lifecycle transaction SHALL preserve the complete ZYZ-CRF-7 §23.70.1 transaction record: transaction start; transaction end where applicable; recording system; recording Component; actor; Execution Identifier; event; prior version; new version; and provenance. A selected authoritative transaction_time/order value SHALL remain distinct from that full record.

14.2 PP-ACT outcomes and partial activation

This profile SHALL reuse canonical PP-ACT result semantics, including:

• active;
• partially_active;
• failed;
• suspended;
• rolled_back; and
• retired.

It SHALL NOT invent an incompatible XBRL-only state vocabulary.

Where result = partially_active, the record SHALL identify the exact successful and failed scopes required by PP-CCPS §41.2.

The resolver SHALL treat only the exact successful scopes as activation-applicable. A Runtime Context that falls wholly within a failed scope SHALL NOT resolve that PP-ACT as active. A Runtime Context that intersects an incompletely partitioned or ambiguous successful/failed boundary SHALL fail closed until applicability can be determined exactly.

The successful/failed partition SHALL be preserved for current resolution and historical replay. Later repair or retry SHALL create governed successor evidence rather than rewriting which scopes succeeded historically.

14.3 Resume and reinstatement

A suspended activation SHALL NOT be resumed by mutating historical evidence.

Resumption SHALL create a new governed authority/evidence transition. Within the PP-XRA machine contract, that transition SHALL use transition_type: reinstatement rather than introducing a second resume or resumption machine value.

Where reinstatement changes applicability, cardinality or the selected PP-ACT for an activation plan, it SHALL be represented under planned_lifecycle_transitions as either exact preexisting evidence or an atomic_with_activation transition. Its authority-relevant payload/evidence and transition-level retroactivity semantics SHALL be bound into the activation plan and digest under Sections 6 and 7.5, applied under Section 18.4 and preserved for replay under Section 15.5.

14.4 Supersession and cutover

Registration of a newer taxonomy release SHALL NOT automatically deactivate or supersede an older activation.

The required path is:

new taxonomy registered
        │
        ▼
compatibility / impact analysis
        │
        ▼
new validated activation artefacts
        │
        ▼
PP-REL
        │
        ▼
PP-AR
        │
        ▼
activation admission
        │
        ├── exact predecessor-ending transition pinned if required
        ▼
PP-ACT + authoritative lifecycle transition
        │
        ▼
explicit cutover

An existing immutable open-ended PP-ACT SHALL NOT be mutated merely to insert a later valid_to. Its operative end SHALL be derived from the authoritative lifecycle-ending event under Section 14.5.

Where a successor activation depends on ending a predecessor at cutover time T, the exact predecessor-ending transition SHALL either pre-exist authoritatively and be pinned/re-proved or be included in the same authorized activation plan and persisted atomically with the successor activation. The system SHALL NOT approve the successor on the assumption that an unspecified later cutover event will make the overlap disappear.

14.5 Lifecycle and boundary edge semantics

Every transition that can change Runtime applicability—including effective start, expiration, suspension, reinstatement/resumption, revocation, rollback, retirement, supersession and explicit cutover—SHALL have a deterministic effective edge.

For PP-XRA, the general transition convention is:

prior lifecycle state applies for t < transition_effective_at
post-transition state applies for t >= transition_effective_at

For scheduled effective-start and expiration boundaries, transition_effective_at is not assumed to equal the raw interval endpoint. It is the deterministically derived first-included or first-excluded governed instant under the pinned Temporal Profile, boundary semantics, precision and granularity. Therefore the general transition convention remains consistent with left/right-inclusive and left/right-exclusive intervals.

This convention SHALL NOT be implemented by rewriting historical PP-ACT evidence. The effective interval is reconstructed from the original activation plus authoritative lifecycle-transition/boundary evidence.

Every resolver-affecting lifecycle or boundary transition SHALL preserve or canonically reference evidence sufficient to establish at least:

• affected activation identity/version;
• transition type;
• transition effective time;
• affected resolution scope;
• resulting lifecycle state;
• authority and actor/service or authority derivation where the boundary is pre-authorized;
• applicable Temporal Profile identity/version/fingerprint;
• relevant boundary semantics, precision and granularity where the transition is interval-derived;
• transition-level retroactivity mode/evidence where the transition's authority is newly recorded;
• complete transaction start/end and ZYZ-CRF-7 §23.70.1 transaction record where applicable;
• this transition edge convention or the exact governing semantics profile/version/fingerprint;
• provenance; and
• any required transition-order contract.

An effective-start transition SHALL exist for every activation. Its effective instant SHALL be the first governed instant included by the authorized interval. Its prior state SHALL equal status_before_activation; its resulting state SHALL equal the authorized operative activation state. Effective start is authorized by the activation interval itself and SHALL use mode: scheduled_boundary. ZYZ-CRF-7 §23.68.13 boundary-event evidence SHOULD be emitted/preserved when the boundary is processed. Failure or delay in emitting a boundary notification SHALL NOT delay an already-authorized effective start.

An expiration transition SHALL exist for every finite activation interval. Its effective instant SHALL be the first governed instant not included after the authorized right boundary, and its resulting lifecycle state SHALL equal the declared status_after_expiration. Expiration is authorized by the activation interval itself and SHALL use mode: scheduled_boundary; it SHALL NOT require a later discretionary authority decision merely to make the already-authorized end effective. ZYZ-CRF-7 §23.68.13 boundary-event evidence SHOULD be emitted/preserved when the boundary is processed. Failure or delay in emitting a boundary notification SHALL NOT silently extend the authorized effective interval.

For both scheduled boundaries, any actual boundary-event transaction/recording time SHALL be established under the exact transaction-time governance contract. The effective boundary remains determined by the authorized interval, not by notification delivery time. Because the authority/effective edge was fixed in the earlier activation record, delayed processing evidence does not create a new retroactive authority decision.

A newly recorded authority-bearing lifecycle transition whose transition_effective_at precedes its own authoritative transaction time is retroactive under ZYZ-CRF-7 §23.68.4. This rule applies uniformly to suspension, reinstatement, revocation, rollback, retirement, supersession, cutover and any future resolver-affecting transition type. Such a transition SHALL bind the complete retroactivity decision before authorization and SHALL pass the same executable apply/commit guard as the activation itself. preexisting transition evidence is re-proved rather than re-authorized.

A revocation SHALL additionally preserve the complete revocation evidence required by ZYZ-CRF-7 §23.68.9:

• revocation decision;
• authority;
• effective revocation time;
• transaction time;
• future-use prohibition;
• historical-use treatment;
• affected dependants; and
• provenance.

For PP-XRA, transition_effective_at SHALL be the single canonical value for the revocation's effective revocation time. Canonical revocation evidence SHALL map that same value to the constitutional field; a separate conflicting effective-time value is prohibited.

Revocation SHALL take effect at that governed effective instant, SHALL participate in boundary-event processing under ZYZ-CRF-7 §23.68.13, and SHALL NOT erase historical applicability before that time.

The revocation transaction_time is different: under ZYZ-CRF-7 §§23.67.2 and 23.70.2 it is the time the governed system of record actually records the knowledge. For an atomic_with_activation revocation, the activation plan SHALL therefore bind the exact transaction-time governance and transition-retroactivity contracts before authorization, but SHALL NOT preselect a literal future transaction timestamp. Atomic apply SHALL establish the actual transaction time/order only through the pinned reserved_authoritative_time or atomic_commit_constraint path and preserve it together with transaction start/end, recording system/Component, actor, Execution Identifier, event, prior/new version and provenance in immutable revocation evidence.

A suspension SHALL additionally preserve the complete suspension evidence required by ZYZ-CRF-7 §23.68.10:

• suspension start;
• expected or actual end;
• authority;
• reason;
• affected scope;
• emergency status;
• reinstatement policy; and
• provenance.

PP-XRA SHALL NOT replace or weaken those constitutional suspension requirements with a smaller generic lifecycle record.

A reinstatement SHALL preserve or canonically reference the suspension being reinstated and evidence sufficient to prove that the governing reinstatement policy has been satisfied. It SHALL preserve the reinstatement effective time, affected scope, resulting operative state, authority and provenance. Reinstatement SHALL NOT be inferred merely because a suspension's expected end has passed.

For an atomic_with_activation revocation, every authority-selected revocation field above SHALL be fixed before authorization, together with transition-level retroactivity semantics and the exact transaction-time governance contract. Apply SHALL prove semantic identity to those authorized semantics, establish only the actual recording time/order under the executable guard, and SHALL NOT alter the revocation decision, effective instant, future-use prohibition, historical treatment, affected dependants or provenance after approval.

For an atomic_with_activation suspension, the complete suspension evidence above SHALL be fixed before authorization and included directly in the activation plan or bound by an immutable transition-payload fingerprint included in activation_plan_sha256. The apply step SHALL prove byte/semantic identity to that authorized payload; it SHALL NOT fill in duration, reason, emergency state, reinstatement policy or provenance after approval. If the suspension edge is backdated relative to its own recording time, transition-level governed retroactivity is additionally mandatory.

For an atomic_with_activation reinstatement, the complete authority-relevant reinstatement payload SHALL likewise be fixed before authorization and included directly in the activation plan or bound by an immutable transition-payload fingerprint included in activation_plan_sha256. Apply SHALL re-prove that exact payload and SHALL NOT infer reinstatement from elapsed time or select a different reinstatement policy after approval. If the reinstatement edge is backdated relative to its own recording time, transition-level governed retroactivity is additionally mandatory.

For transition ordering, the collision domain is not limited to events that name the same activation. It includes every concurrent or constitutionally same-time transition whose ordering can change applicability, cardinality or the selected PP-ACT for the same Runtime Context/resolver result.

Examples include:

• a planned A -> B cutover concurrent with a rollback of B to A;
• effective start of B concurrent with expiration of same-scope A;
• revocation of a broad activation concurrent with activation of a same-scope successor;
• suspension of a broad activation concurrent with activation of a narrower successor;
• retirement of one activation concurrent with supersession or reinstatement affecting another activation in the same resolution scope.

Where two or more such transitions are concurrent or have constitutionally equivalent effective time and their order could change the resolver result, an exact governed transition-order contract SHALL determine the order. That contract SHALL be pinned by canonical identity, version and immutable fingerprint in the relevant transition/activation evidence.

For any such collision involving one or more atomic_with_activation transitions, the exact transition-order contract identity/version/fingerprint SHALL appear directly in the authorized activation plan and activation_plan_sha256. It SHALL NOT be selected during apply merely because the generic policy says a pinned contract is required.

This rule implements ZYZ-CRF-7 §23.74.7: concurrent events SHALL NOT be arbitrarily ordered unless applicable policy defines a deterministic tie-breaker.

If no deterministic order contract exists, the resolver state at that instant is ambiguous and current resolution/replay SHALL fail closed rather than allowing activation identifier, storage order, event-arrival order or implementation ordering to decide authority. Constitutionally significant transaction order itself SHALL be preserved under the separate pinned transaction-order contract required by ZYZ-CRF-7 §23.70.10.

The current Core 1.0 canonical machine contracts do not yet carry all of this lifecycle/boundary, retroactivity and complete transaction-record evidence; Section 5.6 therefore remains an implementation blocker until the canonical contract is compatibly evolved.

14.6 Historical state preservation

Effective start, expiration, revocation, retirement or supersession from current production use SHALL NOT rewrite the historical transaction record of what the platform knew at earlier transaction times. Retroactive lifecycle authority MAY change a current governed reconstruction of past effective state only through the complete §23.68.4 contract; it SHALL NOT alter earlier as-recorded execution history. Effective-time historical reconstruction and exact as-recorded replay SHALL remain distinguishable under Sections 15 and 21.

---

15. Runtime resolution contract

15.1 Single governed resolver

Consumers SHALL resolve XBRL taxonomy state through one governed resolver contract or an equivalent constitutionally conformant service boundary.

Conceptually:

resolveXbrlTaxonomy(RuntimeContext, declared_use, evaluation_mode, effective_time, replay_execution_id?)

evaluation_mode SHALL distinguish at least:

• CURRENT_OPERATIONAL; and
• HISTORICAL_REPLAY.

These are product evaluation modes. They SHALL NOT replace the constitutional Replay Profile. The PP-XRA resolver SHALL declare replay profile EXACT under REPLAY-CONSTITUTION.

For HISTORICAL_REPLAY, replay_execution_id (or an immutable equivalent replay-manifest reference) is mandatory. The replay SHALL use the original execution's effective-time coordinate(s), transaction-time/as-recorded boundary and transaction-order/snapshot evidence from the immutable replay manifest. A caller-supplied past effective time alone is insufficient to define exact replay.

A request asking what the system now understands to have been effective at a past instant is a Historical Reconstruction request governed by ZYZ-CRF-7 §23.71 and SHALL NOT be mislabeled as HISTORICAL_REPLAY merely to gain hindsight over later-recorded evidence.

Consumers SHALL NOT bypass activation governance by directly selecting a release from pp.xbrl_taxonomy_release using publication date, registration time, lexical version order or another latest heuristic.

The following pattern is prohibited as a source of Runtime authority:

SELECT ...
FROM pp.xbrl_taxonomy_release
WHERE release_status = 'registered'
ORDER BY publication_date DESC
LIMIT 1;

15.2 Resolver inputs

The resolver SHALL receive enough information to identify or derive the authoritative Runtime Context, including where applicable:

• Runtime Context identity/version;
• Context Fingerprint;
• authorised context projection if used;
• environment;
• taxonomy family/framework;
• tenant;
• organisation/legal entity when governed by the Runtime Profile;
• white-label operator;
• jurisdiction;
• consumer Module;
• consumer Component;
• declared use/runtime capability;
• Runtime Bundle;
• reporting context;
• effective time;
• access/publication profile where relevant;
• execution mode where relevant;
• constitutional release where relevant;
• security context; and
• for exact replay, original Execution Identifier / replay-manifest reference.

Missing required context SHALL fail closed rather than be silently defaulted.

15.3 Resolver applicability and cardinality

The resolver SHALL evaluate semantic scope applicability and interval membership using the declared temporal boundary semantics, exact pinned Temporal Profile and derived first-included/first-excluded effective edges, not merely selector-hash equality or raw timestamp comparison.

Before the derived effective-start instant, the activation SHALL remain in status_before_activation. At or after that transition instant, it may become operative subject to all other gates. For finite intervals, at or after the derived first-excluded expiration instant it SHALL be in status_after_expiration. Boundary-event notification timing SHALL NOT shift either authorized edge.

For a partially_active PP-ACT, applicability SHALL first be restricted to the exact successful scopes recorded under Section 14.2. Failed scopes SHALL be excluded before cardinality is evaluated.

The default rule is:

0 applicable authorised activations  -> NOT_ACTIVE
1 applicable authorised activation   -> RESOLVED
>1 applicable authorised activations -> AMBIGUOUS_ACTIVATION

AMBIGUOUS_ACTIVATION SHALL be blocking unless an exact governed multiplicity-reducing contract pinned under Section 8.5 yields exactly one authoritative activation before final resolution.

The resolver SHALL use the exact identity/version/fingerprint authorized in the applicable activation evidence. It SHALL NOT fetch a mutable latest precedence/coalescing rule at resolution time.

Compatibility or equality of the underlying taxonomy release SHALL NOT by itself collapse multiple activation authorities into one result.

15.4 Current operational resolution

For CURRENT_OPERATIONAL, the resolver SHALL verify at least:

• exact PP-REL and released artefact digests;
• exact registered taxonomy evidence;
• exact successful/failed scope partition where result = partially_active;
• exact pinned Temporal Profile identity/version/fingerprint;
• selected activation is effective for the current/requested operational time under its declared interval boundary semantics and derived effective edges;
• effective start, expiration, suspension, reinstatement, revocation and other lifecycle transitions are applied under Section 14.5;
• every newly recorded backdated lifecycle transition carries valid governed retroactivity evidence;
• current transaction-state knowledge is evaluated under the governed transaction-time/system-of-record semantics;
• no effective revocation prohibits current/future use for the resolved context;
• current lifecycle state is operative;
• current mandatory rights state affirmatively permits the intended operational use;
• required Runtime compatibility remains valid; and
• exactly one activation applies after exact scope partitioning, planned/applied lifecycle transitions and the exact pinned governed multiplicity rules.

15.5 Exact historical replay resolution

For HISTORICAL_REPLAY, the resolver SHALL operate under constitutional replay profile EXACT and SHALL target a specific original execution. Exact replay means the governed historical resolver output is reproduced identically under the pinned equivalence contract using the evidence that was recorded as known for that original execution—not a hindsight reconstruction using later transaction state.

The replay SHALL:

1. require the exact original Execution Identifier or immutable replay-manifest reference;
2. use the exact immutable replay manifest for that execution, conforming to the pinned replay-manifest schema;
3. recover from that manifest the original effective-time coordinate(s), exact as-recorded transaction-time boundary/snapshot and transaction-order/sequence evidence;
4. use only object/event/evidence versions that were recorded within that original transaction boundary, in accordance with ZYZ-CRF-7 §§23.70.5–23.70.6;
5. use the exact Replay Constitution identity/version/fingerprint and exact replay-equivalence contract bound by the governing activation/replay evidence;
6. use the exact Temporal Profile identity/version/fingerprint that governed the original execution rather than a current/latest profile;
7. evaluate interval membership at the original effective coordinate using the declared boundary semantics and derived first-included/first-excluded edges;
8. evaluate the exact historical status_before_activation / status_after_expiration where applicable;
9. for a historical partially_active result, apply the exact successful/failed scope partition recorded for that execution;
10. evaluate only lifecycle/boundary transitions recorded within the original transaction boundary, under the exact edge/order semantics that governed that execution;
11. for a revocation already recorded within that boundary, apply its exact historical-use treatment; exclude later-recorded revocations/corrections from the replay input even where they carry earlier effective time;
12. where a lifecycle transition recorded within that boundary was itself retroactive, use its exact governed retroactivity evidence as part of the historical authority record;
13. use the exact multiplicity-reducing contract identity/version/fingerprint that governed the original resolver result, where one existed;
14. use the exact transition-order contract and transaction-order evidence that governed any relevant concurrent transitions in the original snapshot;
15. evaluate the rights and validation evidence recorded and relied upon for the original execution;
16. identify the exact PP-REL, released artefacts and taxonomy release selected by the original execution;
17. reproduce the exact governed resolver output fields declared by the equivalence contract, including resolution status/cardinality and selected authority/release identity;
18. preserve later-recorded lifecycle events, corrections and retroactive decisions as later provenance rather than silently introducing them into the original replay input; and
19. separately evaluate present-day authority, rights, security and access to perform or disclose the replay now.

A historically replayed state MAY therefore differ from a current Historical Reconstruction for the same effective-time coordinate if later-recorded corrections, retroactive activations or retroactive lifecycle transitions changed what the system now understands about that period. Both results can be constitutionally correct because they answer different bitemporal questions.

If replay does not reproduce the exact governed output under the pinned equivalence contract, the execution SHALL emit/record REPLAY-DRIFT (or the canonical governed equivalent) and SHALL NOT silently substitute a current reconstructed result. Decision-material drift requires constitutional review under REPLAY-CONSTITUTION.

15.6 Historical Reconstruction remains separate

A current request to reconstruct what is now understood to have been effective at a past time SHALL use the governed Historical Reconstruction mechanism under ZYZ-CRF-7 §23.71. Such a request SHALL declare the requested time dimensions and may incorporate later-recorded corrections, retroactive activations or retroactive lifecycle transitions according to the applicable Temporal Profile and reconstruction authority.

Historical Reconstruction SHALL NOT overwrite, relabel or replace the immutable output of an exact replay of an earlier execution.

15.7 Resolver output

A resolved result SHOULD expose at least:

{
  "resolution_status": "RESOLVED",
  "evaluation_mode": "CURRENT_OPERATIONAL",
  "replay_profile": "EXACT",
  "effective_time": "...",
  "effective_interval": {
    "valid_from": "...",
    "valid_to": null,
    "boundary_semantics": "left_inclusive_right_exclusive",
    "status_before_activation": "future_effective",
    "status_after_expiration": "expired",
    "effective_start_transition_at": "...",
    "expiration_transition_at": null
  },
  "temporal_profile": {
    "id": "...",
    "version": "...",
    "fingerprint": "sha256:..."
  },
  "transaction_state": {
    "system_of_record": "...",
    "transaction_start": "...",
    "transaction_time": "...",
    "transaction_end": "...",
    "transaction_sequence": "..."
  },
  "multiplicity_policy": {
    "mode": "fail_closed",
    "contract": null
  },
  "lifecycle_transition_semantics": {
    "edge_convention": "post_transition_state_effective_at_derived_transition_instant",
    "transition_order_contract": null
  },
  "projection_release": {
    "id": "PP-REL-...",
    "version": "..."
  },
  "activation_record": {
    "id": "PP-ACT-...",
    "version": "..."
  },
  "taxonomy_release_id": "XBRL-ESRS-SET1-2023-12-22",
  "runtime_context": {
    "source_context_id": "...",
    "context_fingerprint": "sha256:...",
    "projection_fingerprint": null
  },
  "selector_scope_sha256": "sha256:...",
  "activation_plan_sha256": "sha256:...",
  "authority_boundary": {
    "runtime_activation": true,
    "legal_authority": false,
    "semantic_mapping_authority": false,
    "publication": false,
    "regulatory_filing": false,
    "redistribution": false
  },
  "provenance": {
    "registration_event_id": "...",
    "released_artefact_digests": [],
    "hecate_receipt": "...",
    "rights_gate_evidence": [],
    "replay_manifest": "..."
  }
}

For historical replay, the output SHOULD additionally distinguish:

original_execution_id
original_effective_time
as_recorded_transaction_boundary
historical_resolution_status
replay_equivalence_status
current_replay_access_status

The output SHALL make authority boundaries explicit enough that Runtime resolution cannot reasonably be interpreted as legal, publication or redistribution authority.

---

16. Consumer contract

Every consuming Component SHALL:

1. resolve through the governed activation resolver;
2. pass the complete Runtime Context or authorised projection and declared use;
3. consume only the exact resolved taxonomy release;
4. preserve PP-REL, PP-ACT, taxonomy release and Runtime Context provenance;
5. separately evaluate any PP-MAP/PP-MD purpose gate required for semantic traversal;
6. separately evaluate any downstream Rights Gate or publication/filing authority required for the material use; and
7. fail closed if activation cannot be resolved deterministically.

No consumer MAY silently substitute another registered release when resolution fails.

---

17. Logical persistence model

This version defines logical constructs without choosing the final physical schema owner.

17.1 Authoritative evidence

Authoritative release/activation evidence SHALL be represented by canonical PP-REL, PP-AR, PP-ACT, PP-RBK and associated governed evidence.

A future relational projection SHALL NOT become a parallel source of constitutional authority.

The current Core 1.0 PP-AR, PP-ACT and PP-RBK JSON Schemas do not yet expose enough authoritative structure for every PP-XRA temporal, bitemporal, plan, partial-scope, multiplicity, replay, complete-transaction-record and lifecycle-transition invariant. That gap is a canonical contract defect to be resolved under PP-CCPS, not a reason to move authority into this profile's derived binding.

17.2 Effective runtime binding

A future implementation SHOULD expose a logical construct equivalent to:

xbrl_taxonomy_runtime_activation_binding

Its purpose is to make the effective scoped, temporal PP-ACT → XBRL release binding queryable.

It SHOULD preserve at least:

projection_release_id/version
released_artefact references/digests
activation_record_id/version
activation_request_id/version
taxonomy_release_id
registration_event_id
source Runtime Context identity/version
Context Fingerprint
authorised projection fingerprint + projection contract where used
selector_scope_sha256
activation_plan_sha256
target_environment
scope/reporting-context projection
partial-activation successful/failed scope partition where applicable
Temporal Profile identity/version/fingerprint
valid_from
valid_to
boundary_semantics
status_before_activation
status_after_expiration
derived effective-start/expiration transition instants
activation retroactivity mode/evidence where applicable
per-transition retroactivity mode/evidence where applicable
activation transaction start/time/end + transaction order evidence
transaction-time governance + retroactivity-guard + outcome-writer-fence contracts
impact-mutation selector schema identity/version/fingerprint
impact-mutation writer registry identity/version/fingerprint
impact-mutation mutation vocabulary identity/version/fingerprint
impact-mutation canonicalization contract identity/version/fingerprint
impact-mutation validated selector + canonical writer/mutation identity sets + domain fingerprint
recording system/Component, actor, execution/event, prior/new version, provenance
replay profile + Replay Constitution identity/version/fingerprint
replay-manifest schema identity/version/fingerprint
exact replay-equivalence contract identity/version/fingerprint
original Execution Identifier + as-recorded transaction boundary for replay
multiplicity-policy mode
multiplicity contract identity/version/fingerprint where applicable
planned/preexisting/scheduled lifecycle-transition bindings including effective start, expiration, reinstatement and revocation where applicable
atomic transition payload fingerprint where applicable
actual canonical transition transaction records where applicable
transition-order contract identity/version/fingerprint where applicable
lifecycle transition semantics/evidence references
Runtime Bundle reference
consumer Module/Component lineage
HECATE evidence reference
Rights Gate evidence fingerprint
provenance

This derived binding MAY repeat authoritative fields for efficient resolution. It SHALL NOT be used as the sole carrier for evidence that the canonical activation/lifecycle contracts cannot represent.

17.3 Optional current pointer

A high-performance pointer or materialized current view MAY exist.

It SHALL be:

• derived;
• reconstructable;
• non-authoritative;
• updated only after authoritative activation evidence is committed; and
• independently verifiable against release/activation history.

17.4 Physical schema ownership is deferred

Pergamum Pulse owns taxonomy evidence lineage. Constitutional Runtime Governance owns activation authority.

The final physical schema placement SHALL be chosen before database migration through an explicit architecture decision that preserves both ownership lineages.

---

18. Activation execution pipeline

The implementation SHOULD follow:

BUILD DETERMINISTIC PLAN
        │
        ▼
READ-ONLY PREFLIGHT
        │
        ▼
EXPLICIT DIGEST-BOUND AUTHORIZATION
        │
        ▼
ATOMIC APPLY
        │
        ▼
INDEPENDENT READ-ONLY POST-COMMIT VERIFY

18.1 Build plan

The planner SHALL:

• resolve the exact PP-REL;
• resolve the exact PP-AR;
• pin released artefact references/digests;
• pin exact taxonomy registration evidence;
• bind the canonical Runtime Context or authorised projection;
• canonicalize profile-specific selector scope;
• ask CRP to resolve and then pin the exact Temporal Profile identity/version/fingerprint;
• bind the time dimension, interval bounds, boundary semantics, status before activation and status after expiration;
• derive and bind the exact first-included effective-start transition from valid_from and the exact first-excluded expiration transition for every finite interval;
• bind activation-level retroactivity.mode and all authority-selected ZYZ-CRF-7 §23.68.4 evidence where governed retroactivity is requested or already unavoidable;
• bind the complete transaction-time governance contract, including system of record, recording Component, observation point, Clock Source, normalization/precision/granularity, transaction ordering, retry semantics, executable retroactivity guard, exact outcome-writer fence and complete transaction-record requirements;
• resolve and pin, for every impact-mutation domain, the exact selector schema, writer-identity registry, mutation vocabulary and canonicalization contract identity/version/fingerprint; validate the selector instance; resolve only registered writer/mutation identities; prove semantic coverage including deletion/tombstoning where applicable; and compute the domain fingerprint only from canonicalized bytes;
• pin Replay Constitution identity/version/fingerprint, constitutional replay profile EXACT, replay-manifest schema and exact-equivalence contract;
• require every replay manifest to preserve original Execution Identifier, effective-time coordinate(s), as-recorded transaction boundary/snapshot and transaction-order evidence;
• pin any multiplicity-reducing contract identity/version/fingerprint;
• identify every lifecycle/boundary transition—including effective start, expiration, suspension, reinstatement, revocation, rollback, retirement, supersession and cutover—required to make the planned resolver state deterministic;
• for each newly recorded authority-bearing transition, bind transition-level retroactivity.mode plus complete ZYZ-CRF-7 §23.68.4 evidence where governed retroactivity is requested or already unavoidable;
• for each such transition, pin exact affected activation, type, effective time, affected scope, resulting state, authority/authority derivation and preexisting evidence/fingerprint where applicable;
• for every atomic_with_activation transition, bind the complete authority-selected canonical transition semantics or an immutable fingerprint of those semantics;
• for every atomic suspension, bind every ZYZ-CRF-7 §23.68.10 suspension field before authorization;
• for every atomic reinstatement, bind the governing suspension evidence, satisfaction of reinstatement policy, effective time, affected scope, resulting state, authority and provenance before authorization;
• for every atomic revocation, bind the revocation decision, authority, canonical effective instant, future-use prohibition, historical-use treatment, affected dependants, provenance, transition-level retroactivity semantics and exact transaction-time governance contract before authorization;
• detect order-sensitive collisions across the full resolver collision domain and, where present, pin the exact transition-order contract identity/version/fingerprint;
• bind lifecycle transition edge semantics;
• compute selector and complete-plan digests;
• identify required HECATE evidence;
• identify required rights evidence;
• identify activation authority requirements;
• identify all semantically intersecting activation candidates;
• identify rollback/cutover/effective-start/expiration/reinstatement/revocation requirements; and
• produce deterministic plan bytes.

The planner SHALL create no active Runtime state.

18.2 Read-only preflight

Preflight SHALL be read-only and verify every admission predicate.

A ready result SHOULD expose at least:

{
  "status": "READY_FOR_EXPLICIT_RUNTIME_ACTIVATION",
  "read_only": true,
  "projection_release_id": "PP-REL-...",
  "taxonomy_release_id": "XBRL-ESRS-SET1-2023-12-22",
  "context_fingerprint": "sha256:...",
  "temporal_profile_fingerprint": "sha256:...",
  "boundary_semantics": "left_inclusive_right_exclusive",
  "effective_start_transition_at": "...",
  "expiration_transition_at": null,
  "retroactivity_mode": "none",
  "transaction_time_contract_fingerprint": "sha256:...",
  "retroactivity_guard_mode": "atomic_commit_constraint",
  "impact_mutation_domain_fingerprint": "sha256:...",
  "replay_profile": "EXACT",
  "selector_scope_sha256": "sha256:...",
  "activation_plan_sha256": "sha256:..."
}

Where any gate is not affirmatively satisfied—including canonical authority-carrier compatibility under Section 13.13—preflight SHALL return a blocking outcome and reviewable provenance.

18.3 Explicit digest-bound authorization

Human or governed automation approval SHALL bind to the exact activation-plan digest.

Approval of a different plan, PP-REL, artefact set, Runtime Context, scope, Temporal Profile, temporal boundary semantics/derived edges, pre-activation/post-expiration state, activation/transition retroactivity treatment, transaction-time governance/retroactivity guard/outcome-writer fence/impact-mutation schema-registry-vocabulary-canonicalization bindings/transaction-record requirements, replay governance, multiplicity contract, planned lifecycle transition, atomic transition semantics, transition-order contract or taxonomy release SHALL NOT authorize current apply.

18.4 Atomic apply and scheduled-boundary registration

Apply SHALL re-prove rather than blindly trust preflight.

A conforming apply SHOULD, in one governed transaction boundary where technically possible:

1. re-prove canonical configuration/provenance;
2. verify the exact activation-plan digest;
3. verify exact PP-REL identity/version;
4. verify released artefact references/digests;
5. verify the exact registered taxonomy and seal evidence;
6. verify canonical Runtime Context identity/fingerprint or authorised projection;
7. verify the exact Temporal Profile identity/version/fingerprint;
8. verify the exact temporal interval, boundary semantics, pre-activation/post-expiration states and derived effective-start/expiration edges;
9. verify the exact transaction-time governance contract, including system of record, recording Component, observation point, Clock Source, normalization/precision/granularity, transaction-order, retry semantics, retroactivity guard, outcome-writer fence and transaction-record requirements;
10. verify every impact-mutation domain's exact selector schema, writer-identity registry, mutation vocabulary and canonicalization-contract identity/version/fingerprint; validate the selector instance; re-prove every writer/mutation identity is registered; reproduce byte-identical canonical domain material and domain_fingerprint; and prove every operation capable of changing the authorized impact analysis, including deletion/tombstoning where permitted, maps to a covered canonical identity;
11. capture/preserve the governed transaction start, recording system/Component, actor, Execution Identifier, event and applicable prior-version evidence at transaction initiation;
12. establish the executable retroactivity guard before authority can become committed:
    • under reserved_authoritative_time, obtain from the governed system of record the exact transaction time/order that a successful commit will use and prove that unsuccessful/aborted attempts cannot make those values authoritative; or
    • under atomic_commit_constraint, prove that the authoritative commit-time value will be compared atomically against every newly recorded authority-bearing effective edge and that the same commit will be rejected whenever a mode: none retroactivity predicate fails;
13. verify every activation has its exact scheduled effective-start transition and every finite interval its exact scheduled expiration transition, and persist/register the governed boundary schedule/evidence needed to process them;
14. verify the exact REPLAY-CONSTITUTION binding, replay profile EXACT, replay-manifest schema and equivalence contract;
15. verify the exact multiplicity-policy mode and multiplicity contract identity/version/fingerprint where applicable;
16. verify every planned lifecycle/boundary transition, including effective start, expiration, suspension, reinstatement, revocation, rollback, retirement, supersession and cutover, against its affected activation, transition type/time/scope/resulting state and authority/authority derivation;
17. where a planned transition is preexisting, re-prove the exact authoritative transition evidence/fingerprint;
18. where a planned transition is scheduled_boundary, verify its effective instant/resulting state are fully derived from and identical to the authorized interval contract and Temporal Profile;
19. where a planned transition is atomic_with_activation, verify the complete authority-selected transition semantics, transition-level retroactivity contract or immutable fingerprint against the authorized plan before persistence;
20. for an atomic suspension, verify exact suspension start, expected/actual end, authority, reason, affected scope, emergency status, reinstatement policy and provenance against the authorized payload;
21. for an atomic reinstatement, verify the governing suspension evidence, satisfied reinstatement policy, reinstatement effective time, affected scope, resulting operative state, authority and provenance against the authorized payload;
22. for an atomic revocation, verify transition_effective_at as the sole effective revocation instant and verify revocation decision, authority, future-use prohibition, historical-use treatment, affected dependants, provenance, transition-retroactivity semantics and the exact transaction-time governance contract;
23. verify and establish the exact outcome-writer-fence contract over the complete canonical, digest-bound impact_mutation_domain before any protected impact-set snapshot is taken. The fence SHALL use the same pinned schema/registry/vocabulary/canonicalization semantics proven in step 10 and SHALL include every covered writer/operation capable of changing affected-outcome membership/state or restatement/notification treatment. Any already-in-flight covered mutation SHALL either be ordered before the authority under the pinned transaction-order contract and already be represented in the authorized impact/treatment state, or be forced after the authority and marked for mandatory authority revalidation/recompute/re-evaluation before its own commit;
24. evaluate activation-level and every newly recorded transition-level retroactivity against the guarded authoritative transaction-time value only after the writer fence in step 23 is active. In reserved_authoritative_time mode this SHALL occur before the irreversible commit point. In atomic_commit_constraint mode the same predicate and writer fence SHALL be enforced inside the commit itself using the actual authoritative commit value. Any effective edge earlier than its transaction time SHALL block mode: none and require exact authorized governed-retroactivity evidence. For every mode: governed activation or transition, recompute the exact affected historical outcomes and authoritative outcome states through that same guarded candidate transaction boundary inside the already-established impact-mutation conflict boundary and prove that the authorized §23.68.4 affected-outcome set, restatement requirements and notification requirements remain complete and unchanged. If membership, outcome identity/version/status or required restatement/notification treatment differs from the digest-bound authorization, abort and require a refreshed plan/digest and new governed authorization. The fence SHALL remain effective from before this protected snapshot through successful commit;
25. where an order-sensitive collision exists, verify the exact transition-order contract identity/version/fingerprint bound into the authorized plan;
26. verify that the canonical lifecycle contract can represent every planned atomic/scheduled transition, complete transaction record and retroactivity evidence authoritatively and stage/register it inside the governed transaction boundary;
27. verify canonical authority-carrier compatibility under Section 13.13;
28. re-evaluate or re-prove an affirmatively permitting PP-RLCPS Rights Gate outcome;
29. verify source/capture current eligibility;
30. verify HECATE activation-admission evidence;
31. verify Runtime Bundle/consumer compatibility;
32. serialize or otherwise protect all semantically intersecting scope and lifecycle-transition candidates, every governed-retroactivity impact-mutation domain being revalidated, and all covered outcome/treatment writers from races through successful commit;
33. compute the projected post-transaction/boundary resolver state using only the exact authorized transition semantics/order contract and prove that no affected Runtime Context/time has unresolved multiplicity after the exact authorized transitions and pinned multiplicity rules;
34. atomically persist any atomic_with_activation authoritative lifecycle transitions with authority-selected semantics identical to the authorized plan and actual observational transaction evidence generated only under their pinned transaction-time governance;
35. persist the immutable canonical activation authority/evidence record, including exact successful/failed scopes if partially_active, the complete §23.70.1 transaction record fields available before commit, and the selected transaction-time/order evidence governed by the chosen guard;
36. emit/persist the activation execution's immutable replay manifest under the pinned EXACT replay governance, including original Execution Identifier, effective-time coordinate(s), exact as-recorded transaction boundary/snapshot and transaction-order evidence;
37. persist/update the derived effective binding;
38. update any derived current pointer last;
39. re-resolve the exact Runtime Context and effective time and prove it selects exactly the intended activation/release under the exact pinned Temporal Profile, partial-scope partition, effective-start/expiration/reinstatement/revocation and other lifecycle transitions, transition-order contract and multiplicity rule;
40. commit under the pinned retroactivity-guard and continuously active outcome-writer-fence semantics. On successful commit, preserve the authoritative transaction time/order selected by the guard, set/preserve transaction_end where applicable, finalize new-version/event provenance, preserve evidence that every governed-retroactivity affected-outcome/restatement/notification state still matched the authorized plan at the guarded commit boundary, and publish the new committed authority state/fence so blocked or in-flight covered writers must observe it before their own canonical commit; and
41. emit immutable execution evidence.

The activation SHALL NOT commit if a required lifecycle transition/scheduled-boundary registration fails, if a derived boundary edge differs from the authorized derivation, if the activation or any newly recorded lifecycle transition is retroactive without governed retroactivity authorization, if a governed retroactivity decision no longer covers the complete affected historical-outcome/restatement/notification state at the guarded transaction boundary, if an impact-mutation selector schema/writer registry/mutation vocabulary/canonicalization contract is absent, substituted, unregistered or fingerprint-mismatched, if any writer/mutation identity is local/unregistered, if a semantically possible impact-changing operation such as deletion/tombstoning is not mapped into the covered domain where applicable, if two conforming consumers cannot reproduce byte-identical domain material/fingerprint, if the protected impact-set snapshot was taken before the exact writer fence covered the complete canonical impact-mutation domain, if the outcome-writer fence is absent/substituted or permits any covered mutation to commit stale authority or alter the accepted impact analysis after the snapshot, if authority-selected atomic transition semantics differ from the authorized plan, if the transaction-time governance/guard/observation point is substituted, if a commit-time observation point lacks an enforceable atomic commit constraint, if the complete transaction record cannot be preserved, if the required transition-order contract differs from the authorized contract, if replay governance differs from the authorized contract, or if the post-transaction resolver result differs from the authorized plan.

After a governed retroactive authority commits, every writer/operation covered by its outcome_writer_fence SHALL, before its own canonical recording point, prove one of exactly two conditions: (1) the pinned transaction-order contract constitutionally orders that exact canonical mutation/writer identity before the authority and the mutation plus its resulting impact-set/restatement/notification state was already included in the authorized §23.68.4 analysis; or (2) the mutation is ordered after the authority and has re-resolved/recomputed/re-evaluated under the committed authority state. If neither condition can be proved, the writer SHALL abort/retry rather than record stale output or treatment. This requirement survives release of the activation transaction's locks; releasing the guard SHALL NOT release in-flight writers from authority revalidation.

When a scheduled effective-start or expiration boundary is processed, the runtime SHOULD emit/preserve its boundary-event evidence and actual transaction/recording record under the governing transaction-time contract. Boundary-event processing SHALL NOT move or redefine the already-authorized effective edge and SHALL NOT be mistaken for a new retroactive authority decision merely because processing occurs after that edge.

Where one atomic boundary is impossible, the transition contract SHALL define phased state, compatibility, failure and compensation semantics without exposing a falsely active or ambiguously active state. Such a phased design SHALL itself preserve the same digest-bound transition identities, authority-selected semantics, activation/transition retroactivity semantics, complete transaction-time governance/records, outcome-writer fencing, canonical impact-mutation semantics and ordering contracts and shall not treat an unplanned later event as equivalent.

18.5 Independent post-commit verification

Post-commit verification SHALL be read-only and independently reconstruct expected state from committed evidence.

It SHALL verify:

• exact PP-REL;
• exact released artefact digests;
• exact activation record;
• exact successful/failed scope partition where partially active;
• exact plan digest;
• exact taxonomy release;
• exact Runtime Context / authorised projection fingerprint;
• selector scope;
• exact Temporal Profile identity/version/fingerprint;
• effective interval;
• boundary semantics;
• status before activation and exact scheduled effective-start boundary;
• status after expiration and scheduled expiration boundary where finite;
• exact boundary-edge derivation under pinned precision/granularity;
• actual activation transaction time/order and exact transaction-time governance/retroactivity-guard/outcome-writer-fence contracts;
• exact impact-mutation selector schema, writer-identity registry, mutation vocabulary and canonicalization contract identity/version/fingerprint;
• selector validity, canonical writer/mutation identity membership, semantic mutation coverage and byte-identical recomputation of the exact domain fingerprint;
• transaction start and transaction end where applicable;
• recording system/Component, actor, Execution Identifier, event, prior/new version and transaction provenance;
• exact governed activation retroactivity evidence where applicable;
• exact governed transition-level retroactivity evidence for every newly recorded backdated lifecycle transition;
• exact replay profile, Replay Constitution, replay-manifest schema/evidence and equivalence contract;
• replay manifest includes original Execution Identifier, effective coordinate and as-recorded transaction boundary/order evidence;
• exact multiplicity contract where applicable;
• exact planned/preexisting/scheduled lifecycle-transition evidence, including effective start, expiration, reinstatement and revocation where applicable;
• exact authority-selected atomic transition semantics/fingerprint where applicable;
• exact actual canonical transition transaction record where applicable;
• exact revocation historical-use treatment where applicable;
• exact transition-order contract identity/version/fingerprint where applicable;
• lifecycle transition evidence/edge/order semantics where applicable;
• governed-retroactivity impact-set/treatment revalidation and evidence that the exact outcome-writer fence covered the complete canonical impact-mutation domain before the protected impact-set snapshot and remained effective through activation commit;
• derived binding/pointer consistency;
• resolver cardinality;
• authority-boundary flags; and
• provenance.

A mismatch SHALL create a governed finding/incident and SHALL NOT be represented as trusted activation.

---

19. Failure and blocking outcomes

The implementation SHOULD distinguish at least these semantic conditions, whether represented by these exact codes or by a governed equivalent registry:

Condition	Required behaviour
Canonical PP-REL absent	Block
Released artefact mismatch	Block
Release/activation artefact digest mismatch	Block + incident/finding
Taxonomy release not registered/sealed	Block
Registration evidence mismatch	Block
Activation-plan digest mismatch	Block
Runtime Context incomplete	Block
Runtime Context projection unauthorised/incomplete	Block
Exact Temporal Profile identity/version/fingerprint absent	Block
Temporal Profile substitution/drift	Block
Effective interval boundary semantics absent	Block
status_before_activation or scheduled effective-start transition absent	Block
Finite interval lacks status-after-expiration or scheduled expiration transition	Block
Effective-start/expiration edge cannot be derived deterministically from boundary semantics + pinned precision/granularity	Block
Scheduled boundary effective instant differs from authorized derived edge	Block
Activation becomes retroactive at actual persistence but retroactivity.mode = none	Block transaction; require new governed authorization
Newly recorded authority-bearing lifecycle transition is backdated but transition retroactivity.mode = none	Block transaction; require governed transition authorization
Governed retroactivity evidence incomplete under ZYZ-CRF-7 §23.68.4	Block
Governed retroactivity affected-outcome membership, authoritative outcome state, restatement treatment or notification treatment changes between authorization and guarded transaction boundary	Block transaction; rebuild plan/digest and obtain new governed authorization
Governed retroactivity impact analysis cannot be protected from concurrent covered mutations through commit	Block
Impact-mutation selector schema, writer-identity registry, mutation vocabulary or canonicalization contract absent/unversioned/unfingerprinted	Block activation
Impact-mutation selector instance fails pinned schema validation	Block activation
Impact-mutation writer or mutation identity is unregistered, locally invented or alias-normalized outside the pinned registry	Block activation
Impact-changing operation has no canonical mutation/writer mapping, including deletion/tombstoning where applicable	Block activation; require governed registry/schema update
Impact-mutation canonicalization cannot produce byte-identical domain material across conforming consumers	Block activation
Impact-mutation domain fingerprint does not recompute from the exact pinned schema/registry/vocabulary/canonicalization bindings and canonical identity sets	Block activation
Protected impact-set snapshot taken before exact outcome-writer fence covers complete canonical impact-mutation domain	Block transaction
Outcome-writer fence absent, substituted or does not cover all writers/operations capable of changing affected-outcome membership/state or restatement/notification treatment	Block activation
In-flight/delayed covered writer attempts to record after authority changed without current-authority revalidation/recompute/re-evaluation	Block writer; abort/retry/recompute/re-evaluate
Writer claims transaction order before retroactive authority but exact canonical mutation/resulting impact state was not included in authorized impact analysis/order contract	Block writer; require refreshed governed authorization if prior ordering is required
Transaction-time governance contract incomplete or substituted	Block
Retroactivity guard absent or substituted	Block
Commit is authoritative observation point without atomic commit constraint	Block
Reserved authoritative transaction time/order cannot be guaranteed as the successful record values	Block
Complete ZYZ-CRF-7 §23.70.1 transaction record cannot be preserved	Block
Transaction start absent	Block
Transaction end absent where applicable	Block/finding according to transaction state
System-of-record observation point or transaction-order contract absent	Block
Aborted/retried attempt timestamp is treated as authoritative transaction time	Block + finding
Replay profile absent or not EXACT	Block replay conformance
Replay manifest/equivalence governance absent or mismatched	Block replay conformance
Exact replay lacks original Execution Identifier or as-recorded transaction boundary/order evidence	Block replay conformance
Exact replay incorporates evidence recorded after the original as-recorded boundary	Record replay defect/drift; fail exact replay verification
Exact replay result diverges	Record REPLAY-DRIFT; fail replay verification
HECATE activation-admission failure	Block
Rights Gate not affirmatively permitting exact activation context	Block
Rights conditions unsatisfied	Block
Required activation authority absent	Block
Runtime compatibility fails	Block
Partial activation lacks exact successful/failed scope partition	Block partial result/resolution
Runtime Context falls in failed partial-activation scope	Do not resolve that activation as active
Multiplicity-reducing contract required but unpinned/mismatched	Block
Required cutover/lifecycle transition absent from authorized plan	Block
Required reinstatement/resumption absent from authorized plan	Block
Required revocation absent from authorized plan	Block
Planned preexisting transition evidence mismatch	Block
Atomic transition semantics absent or differ from authorized plan	Block
Atomic suspension lacks complete ZYZ-CRF-7 §23.68.10 payload	Block
Atomic reinstatement lacks governing suspension/reinstatement-policy evidence	Block
Revocation contains conflicting effective-time values	Block
Atomic revocation lacks complete authority-selected ZYZ-CRF-7 §23.68.9 semantics	Block
Atomic revocation preselects/fabricates literal future transaction time	Block
Atomic revocation transaction-time governance absent or substituted	Block
Effective revocation historical-use treatment absent/indeterminate	Block historical replay/reconstruction according to governing policy
Order-sensitive collision lacks exact plan-bound transition-order contract	Block as ambiguity
Planned atomic transition cannot be persisted with activation	Block transaction
Semantically intersecting/time-overlapping activations would create resolver multiplicity	Block unless exact pinned governed rule/transition yields exactly one
More than one binding resolves without governed precedence/coalescing	Block as ambiguity
Lifecycle transition edge evidence incomplete	Block
Suspension evidence omits a ZYZ-CRF-7 §23.68.10 field	Block suspension applicability/replay
Same-time/concurrent resolver-affecting transitions are order-sensitive without a pinned order contract	Block as ambiguity
Canonical PP-CCPS authority carrier cannot represent required PP-XRA evidence	Block implementation/activation
No binding resolves	Return not active
Pointer differs from reconstructable authority history	Quarantine/incident
Current operational rights expired/revoked/non-authorising	Do not resolve as currently active
Exact historical state was valid in original execution but replay access is denied now	Preserve historical result; deny current replay access

Failure codes SHALL NOT themselves create governance semantics. Controlled values should be registered before implementation hardcodes them.

---

20. Threat model

20.1 Registration-to-activation confusion

Threat: A consumer treats release_status = 'registered' as Runtime authority.

Control: canonical PP-REL → PP-AR → PP-ACT chain plus governed resolver.

20.2 PP-REL bypass

Threat: An implementation places an XBRL taxonomy registry reference directly into the canonical activation release field.

Control: release SHALL resolve to exact canonical PP-REL; XBRL release identity is bound by released artefacts.

20.3 Latest-release substitution

Threat: A service selects the latest publication/version when no activation exists.

Control: no implicit latest fallback; zero matches is NOT_ACTIVE.

20.4 Context truncation

Threat: An activation hash omits constitutionally relevant organisation, legal-entity, publication/access, execution-mode, constitutional-release or other Runtime Context dimensions.

Control: bind full Context Fingerprint or a formally authorised projection preserving exclusion rationale and provenance.

20.5 Scope broadening/intersection

Threat: A broad and a narrow scope have different hashes but both match one Runtime Context.

Control: semantic scope-intersection plus interval-boundary-aware temporal-overlap analysis; hash equality is not sufficient.

20.6 Interval-boundary ambiguity

Threat: One implementation treats an endpoint as included while another treats it as excluded, causing opposite start/cutover/expiration decisions.

Control: every activation interval declares boundary semantics; first-included and first-excluded transition instants are derived under the exact pinned Temporal Profile/precision/granularity and included in the activation-plan digest.

20.7 Right-inclusive expiration conflict

Threat: a right-inclusive interval remains valid at valid_to while an expiration transition also changes it to expired at the same raw endpoint.

Control: expiration is not mechanically set to raw valid_to; it is the first governed instant after the final included instant. Right-exclusive intervals ordinarily expire at valid_to; right-inclusive intervals expire at the next governed instant. If that instant cannot be derived deterministically, admission blocks.

20.8 Missing effective-start semantics

Threat: a future-effective activation silently becomes operative at valid_from without governed pre-activation state, boundary evidence or collision handling.

Control: every activation declares status_before_activation and an exact scheduled_boundary effective-start transition at the first included governed instant. Delayed event delivery cannot shift that edge.

20.9 Silent retroactivity

Threat: a valid_from that predates canonical activation recording—or becomes past because apply is delayed—rewrites historical effective-time cardinality without the authority/evidence required by ZYZ-CRF-7 §23.68.4.

Control: retroactivity defaults to none; apply compares the derived effective-start edge to authoritative activation transaction time under an executable guard and blocks unless a complete governed retroactivity decision was authorized. Historical transaction state remains unchanged.

20.10 Temporal Profile drift

Threat: authorization uses one Temporal Profile but apply or replay resolves a later profile whose clock, time-zone, precision, granularity, normalization or replay policy changes timestamp equivalence.

Control: CRP resolves the profile before authorization; exact profile identity/version/fingerprint is pinned into the activation plan and digest and replay uses that exact profile.

20.11 Partial-activation scope leakage

Threat: a partially_active record is resolved through its broad general scope even for a tenant/white-label scope recorded as failed.

Control: exact successful/failed scope partition is mandatory for partial outcomes; only successful scopes participate in applicability and replay.

20.12 Compatible-overlap multiplicity

Threat: Two activations are allowed to overlap because they point to the same or compatible taxonomy release, but the resolver sees two authority records and returns AMBIGUOUS_ACTIVATION.

Control: admission rejects every overlap that can leave more than one applicable activation unless an exact pinned governed multiplicity rule or exact planned lifecycle transition deterministically reduces the result to one.

20.13 Unbound cutover transition

Threat: a successor is authorized while its predecessor remains open-ended, relying on an unspecified later cutover event to make the new state valid.

Control: every required predecessor-ending transition is pinned into the authorized plan as preexisting evidence or an exact atomic transition; apply persists/re-proves it before commit and verifies projected/post-transaction resolver cardinality.

20.14 Under-specified atomic suspension

Threat: an atomic predecessor suspension is authorized by type/time/scope, but apply chooses a different end, reason, emergency status or reinstatement policy after approval.

Control: the complete constitutional suspension payload, or an immutable fingerprint of it, is bound into the activation plan and digest before authorization and re-proved before persistence.

20.15 Unbound reinstatement

Threat: a suspended activation becomes operative again through a reinstatement/resumption that was not represented in the authorized plan, or apply infers reinstatement merely from elapsed time.

Control: resumption is represented canonically as transition_type: reinstatement; resolver-affecting reinstatement is plan-bound, digest-bound, authority-bearing, explicitly applied and historically replayable. Passing a suspension's expected end alone does not reinstate authority.

20.16 Revocation effective-time split

Threat: generic transition_effective_at and revocation effective_revocation_time differ, so admission/order logic and resolver logic disagree about when revocation applies.

Control: PP-XRA uses one canonical effective instant: transition_effective_at is the constitutional effective revocation time and no independent second value is permitted.

20.17 Ambiguous transaction-time observation

Threat: a Clock Source is pinned but implementations choose transaction start, row insert, event append or commit as transaction_time, and retries create different authoritative timestamps/order.

Control: the plan pins a full transaction-time governance contract: system of record, recording Component, exact observation point, Clock Source, normalization/precision/granularity, transaction-order contract, retry/abort semantics and complete transaction-record requirements. Only the successful canonical record establishes authoritative transaction time/order.

20.18 Fabricated revocation transaction time

Threat: authorization preselects a future transaction_time, forcing apply either to lie about when the revocation was recorded or to change the authorized payload.

Control: the plan binds deterministic transaction-time governance; actual transaction_time is generated only through the pinned executable guard/observation semantics and preserved with transaction start/end and transaction-order evidence.

20.19 Unbound revocation

Threat: an activation is revoked outside the authorized lifecycle plan, or a same-time successor is activated without binding the revocation that makes resolver cardinality deterministic.

Control: resolver-affecting revocation is a first-class plan-bound transition. Its authority-selected ZYZ-CRF-7 §23.68.9 semantics, transition retroactivity and transaction-time governance are digest-bound before authorization, applied at the exact effective revocation time, included in collision ordering, and preserved for historical replay without erasing earlier transaction history.

20.20 Replay-profile ambiguity

Threat: HISTORICAL_REPLAY is treated as an implementation-defined replay mode, leaving unclear whether the resolver must reproduce history exactly or merely verify recorded evidence.

Control: the PP-XRA resolver declares constitutional profile EXACT; Replay Constitution, manifest schema and equivalence contract are pinned, and divergence produces governed replay drift.

20.21 Hindsight contamination of exact replay

Threat: exact replay at effective time T includes a revocation/correction recorded only after the original execution, causing replay to reproduce today's reconstructed history rather than what the system actually knew then.

Control: exact replay is keyed to the original Execution Identifier and immutable replay manifest. The manifest supplies the as-recorded transaction boundary/snapshot and order evidence; later-recorded knowledge is excluded from replay input. Hindsight reconstruction is handled separately under ZYZ-CRF-7 §23.71.

20.22 Mutable transition-order rule

Threat: an order-sensitive atomic lifecycle batch is authorized without binding the exact tie-breaker, allowing apply to choose a different order and therefore a different resolved PP-ACT.

Control: exact transition-order contract identity/version/fingerprint is a mandatory activation-plan and digest input wherever the resolver collision domain is order-sensitive.

20.23 Mutable precedence/coalescing rule

Threat: A precedence/coalescing rule changes after activation and silently selects a different PP-ACT without changing the authorized activation-plan digest.

Control: exact multiplicity contract identity/version/fingerprint is part of the plan digest, apply proof, resolver evidence and historical replay.

20.24 Lifecycle-edge ambiguity

Threat: At exactly an effective-start, expiration, suspension, reinstatement, revocation, rollback, retirement, supersession or cutover transition, implementations disagree whether the prior or post-transition state governs.

Control: PP-XRA defines post-transition state as effective at the derived transition instant and prior state only before it. Interval-derived transition instants are themselves governed evidence.

20.25 Incomplete suspension evidence

Threat: a suspension says only that an activation is suspended at a timestamp, without enough scope/end/reinstatement information to determine applicability.

Control: suspension evidence preserves all ZYZ-CRF-7 §23.68.10 fields, including affected scope, expected/actual end, reason, emergency status and reinstatement policy.

20.26 Cross-activation concurrent-event ambiguity

Threat: different activation IDs participate in concurrent transitions whose ordering changes the same resolver result—for example, expiration or cutover of A concurrent with effective start of B, rollback of B -> A, revocation of A, or reinstatement of another intersecting activation.

Control: transition-order collision domain is the resolver result/Runtime Context, not one activation ID. Order-sensitive concurrent events require an exact pinned deterministic tie-breaker under ZYZ-CRF-7 §23.74.7 or fail closed.

20.27 Canonical-carrier gap

Threat: Extra PP-XRA authority fields exist only in a derived runtime table while the closed canonical PP-ACT/PP-RBK contracts cannot represent them.

Control: canonical contract compatibility is a mandatory admission prerequisite; derived bindings cannot create missing authority.

20.28 Overlap race

Threat: Concurrent activations or lifecycle transitions create multiple operative activations over intersecting scope/time.

Control: serialize/lock intersecting scope and resolver-affecting transition candidates and recheck projected and committed cardinality inside apply.

20.29 Stale preflight

Threat: state changes between preflight and apply.

Control: apply re-proves every material predicate and exact digest-bound authorization, including whether a previously future-effective activation or lifecycle transition became retroactive by apply time.

20.30 Rights drift

Threat: current operational resolution continues after permission becomes non-authorising.

Control: current operational resolver requires current affirmative Rights Gate permission.

20.31 Historical erasure

Threat: later expiration, revocation, retirement or rights expiry makes an earlier valid historical execution appear never to have occurred.

Control: exact replay uses the original as-recorded transaction boundary and preserves the original result; later evidence remains later provenance. Current Historical Reconstruction may separately incorporate later evidence under governed policy.

20.32 Publication-authority escalation

Threat: Runtime activation is interpreted as customer-display, filing, publication or redistribution permission.

Control: explicit false authority boundaries plus fresh downstream gates.

20.33 Mapping-authority escalation

Threat: an active taxonomy is assumed to authorize all PP-MAP traversals.

Control: exact PP-MAP/PP-MD purpose/direction gates remain separate.

20.34 Pointer corruption/drift

Threat: a mutable current pointer differs from authority history.

Control: pointer is non-authoritative, updated last, reconstructable and independently verified.

20.35 Configuration substitution

Threat: crafted branch-local configuration changes authority or scope.

Control: canonical repository/commit/path/digest proof before authorization and apply.

20.36 Backdated lifecycle transition bypass

Threat: an activation that is itself non-retroactive carries a newly recorded revocation, suspension, reinstatement, rollback, retirement, supersession or cutover whose effective edge predates its recording time, silently changing past applicability without the ZYZ-CRF-7 §23.68.4 decision/evidence.

Control: every newly recorded authority-bearing lifecycle transition has its own plan-bound retroactivity mode. Apply compares each transition edge against that transition's guarded authoritative transaction time and blocks mode: none if the edge is earlier.

20.37 Unenforceable commit-time retroactivity check

Threat: commit is the authoritative transaction-time observation point, but the system attempts to inspect that value before commit to decide whether commit is allowed.

Control: commit may be the observation point only with an exact atomic_commit_constraint that evaluates the retroactivity predicate using the same authoritative commit value and rejects the transaction atomically. Otherwise the system must use a governed reservation of the exact authoritative transaction time/order before the irreversible point. A post-commit check is never a substitute for admission.

20.38 Incomplete transaction boundary

Threat: canonical evidence stores one selected transaction timestamp/order but omits transaction start, transaction end or other ZYZ-CRF-7 §23.70.1 fields, making the multi-step apply impossible to reconstruct as a transaction.

Control: every constitutionally significant activation/lifecycle change preserves transaction start; transaction end where applicable; recording system; recording Component; actor; Execution Identifier; event; prior/new version; and provenance in addition to the selected authoritative transaction time/order.

20.39 Stale governed-retroactivity impact set

Threat: a mode: governed retroactive activation or lifecycle transition is authorized with a complete affected-outcome/restatement/notification state, but apply is delayed and an execution, correction, deletion/tombstone, retraction, invalidation, reclassification or treatment update changes that state before the authority is recorded. The old decision is then committed even though the actual impact membership or required treatment no longer matches what was authorized.

Control: before recomputing the impact analysis, apply establishes the exact plan-bound writer fence over the complete canonical impact_mutation_domain. Only inside that already-fenced boundary does it re-evaluate the exact affected historical outcomes and authoritative states through the guarded candidate transaction boundary and compare them, plus restatement and notification treatment, to the digest-bound §23.68.4 authorization. Any membership/state/treatment change aborts the transaction and requires a refreshed plan/digest and new governed authorization. The fence remains effective through commit so no covered mutation can change the accepted impact analysis after the snapshot.

20.40 Delayed outcome writer crosses the authority boundary

Threat: an execution/ingestion/correction or other covered writer starts under the old authority, is blocked while retroactive activation commits, then records immediately after the guard releases using its stale pre-activation authority snapshot. Its mutation can create or alter an affected outcome or treatment inside the retroactive domain even though that state was absent from the activation's accepted commit-time impact analysis.

Control: every covered writer/operation participates in the exact plan-bound outcome-writer fence over the canonical impact-mutation domain, and that fence is established before the protected impact-set snapshot. A covered mutation committing after the authority must re-resolve/recompute/re-evaluate under the committed authority, or abort/retry. It may retain constitutional order before the authority only under the exact transaction-order contract and only when that exact canonical mutation/writer identity and resulting impact/treatment state were already covered by the authorized §23.68.4 analysis. Lock release, transaction start, reserved timestamp or queue position never grandfather stale authority.

20.41 Non-additive impact mutation bypass

Threat: the fence covers only writers that can add new affected outcomes, while a correction, replacement, deletion/tombstone, retraction, invalidation, reclassification or restatement/notification update mutates an already-enumerated outcome or its required treatment after the protected snapshot and before authority commit.

Control: the writer conflict domain is defined by any mutation capable of changing the authorized impact analysis, not by insertion alone. The activation plan binds the complete canonical impact-mutation semantics and fingerprint covering affected-outcome membership/state and restatement/notification treatment plus every registered writer/mutation identity able to alter them. Snapshot acceptance and commit fail closed if that domain is incomplete, substituted or changes outside the fence.

20.42 Divergent mutation-domain semantics

Threat: two services use the same domain_fingerprint field but interpret an unversioned selector differently, use different writer identifiers or mutation aliases, sort sets differently, or omit a deletion/tombstone operation because their local enums differ. The services then fence different conflict domains while believing they share one authorized plan.

Control: the activation plan pins the exact selector schema, writer-identity registry, mutation vocabulary and canonicalization contract by identity/version/fingerprint. Every writer/mutation value is an exact registered identity, the selector must validate against the pinned schema, canonicalization deterministically defines the hashed bytes and set ordering, and the domain fingerprint must be reproducible byte-for-byte by independent conforming consumers. Missing registry identities or schema semantics block implementation and require governed registry/schema evolution; PP-XRA implementations may not invent replacements.

---

21. Audit, provenance and historical replay

Every authoritative activation execution SHALL preserve enough evidence to reconstruct:

• exact PP-REL identity/version;
• exact released artefact references/digests;
• exact taxonomy release and registration evidence;
• exact Activation Request;
• exact plan bytes/digest;
• who/what exercised activation authority;
• canonical Runtime Context identity/version and Context Fingerprint;
• authorised projection contract/fingerprint where used;
• exact Temporal Profile identity/version/fingerprint;
• declared interval boundary semantics;
• status_before_activation and exact derived scheduled effective-start transition;
• status_after_expiration and exact derived scheduled expiration transition where finite;
• boundary precision/granularity and derivation evidence;
• activation retroactivity mode and complete ZYZ-CRF-7 §23.68.4 evidence where applicable;
• transition-level retroactivity mode and complete §23.68.4 evidence for every newly recorded backdated authority-bearing lifecycle transition;
• activation transaction start, authoritative transaction time, transaction end where applicable and transaction-order evidence;
• recording system, recording Component, actor, Execution Identifier, event, prior version, new version and transaction provenance;
• exact transaction-time governance, retroactivity-guard and outcome-writer-fence contracts;
• exact impact-mutation selector schema, writer-identity registry, mutation vocabulary and canonicalization contract identity/version/fingerprint;
• exact validated selector instance, canonical writer/mutation identity sets and reproducible canonical domain bytes/fingerprint;
• governed-retroactivity evidence showing the writer fence covered that complete canonical impact-mutation domain before the protected impact-set snapshot, the accepted affected-outcome identity/version/status and restatement/notification state, and writer-fence/order evidence where applicable;
• constitutional replay profile EXACT;
• exact Replay Constitution identity/version/fingerprint;
• immutable replay manifest conforming to the pinned manifest schema;
• original Execution Identifier, original effective-time coordinate(s), as-recorded transaction boundary/snapshot and transaction sequence/order evidence;
• exact replay-equivalence contract identity/version/fingerprint;
• replay verification outcome and any replay-drift evidence;
• which HECATE profile/rules/evidence passed;
• which Rights Gate outcome/conditions applied;
• which Runtime Bundle/consumer context applied;
• semantic selector scope;
• exact successful/failed scope partition for every historical partially_active outcome;
• exact multiplicity-policy mode and contract identity/version/fingerprint where used;
• every planned lifecycle/boundary transition required by the activation plan, including effective start, expiration, suspension, reinstatement, revocation, rollback, retirement, supersession and cutover, and whether it was preexisting, atomic or scheduled;
• exact affected activation, transition type/effective time/affected scope/resulting state and authority/authority derivation for those transitions;
• exact authority-selected atomic transition semantics or immutable payload fingerprint where applicable;
• exact complete transaction record for every newly recorded authority-bearing transition where applicable;
• lifecycle transition edge semantics;
• lifecycle-transition event evidence;
• complete revocation evidence required by ZYZ-CRF-7 §23.68.9 where applicable, including historical-use treatment and affected dependants;
• complete suspension evidence required by ZYZ-CRF-7 §23.68.10 where applicable;
• reinstatement evidence and governing reinstatement-policy satisfaction where applicable;
• transition-order contract identity/version/fingerprint where order-sensitive concurrent resolver-affecting events exist;
• prior active state;
• derived binding/pointer state;
• immediate post-commit resolver result;
• post-commit verification result; and
• later effective-start/expiration/suspension/reinstatement/revocation/rollback/retirement/supersession events as later transaction provenance where applicable.

Exact historical replay SHOULD be able to answer:

• Which original execution is being replayed?
• What effective-time coordinate(s) did that execution evaluate?
• What was its exact as-recorded transaction-time boundary/snapshot and transaction sequence/order?
• What transaction start/end and recording-system evidence defined the relevant authoritative changes?
• Which taxonomy release was selected for this exact Runtime Context in that execution?
• If the activation was partial, was this exact Runtime Context in a successful or failed scope in the original execution?
• Which exact Temporal Profile governed time interpretation?
• Under which declared interval boundary semantics and derived effective edges was the coordinate evaluated?
• What pre-activation or post-expiration state applied where relevant?
• Which lifecycle edge/order semantics were recorded within the original transaction boundary?
• Which exact cutover/lifecycle transition had been recorded by that boundary?
• Was any recorded lifecycle transition retroactive, and if so which authority/basis/restatement/notification evidence governed it?
• If revoked, what effective revocation time, actual transaction record and historical-use treatment were known then?
• Which exact deterministic ordering policy governed concurrent resolver-affecting events, if any?
• Which exact multiplicity contract selected one activation, if any?
• Which PP-REL supplied the released artefacts?
• Which PP-ACT authorised them?
• Which artefact and taxonomy digests were pinned?
• Which rights and validation evidence had been recorded and applied?
• Which immutable replay manifest and exact-equivalence contract governed replay?
• Did replay reproduce the exact governed historical output, or was replay drift recorded?
• Which later-recorded event changed current knowledge or operability?
• Is present-day replay access permitted now?
• Which PP-MAP/PP-MD purpose decision governed any mapped downstream use?

Historical Reconstruction under ZYZ-CRF-7 §23.71 SHOULD separately be able to answer what the governed system now understands to have been effective at a past coordinate, including later-recorded corrections or retroactive decisions where permitted. Such a reconstruction SHALL preserve its requested time dimensions and SHALL NOT be presented as the original exact replay result.

Historical replay SHALL distinguish:

original as-recorded execution result

from:

exact constitutional replay verified

from:

current historical reconstruction of past effective state

from:

currently permitted to operate now

and from:

currently permitted to access/disclose the historical replay now

These are separate determinations.

---

22. Relationship to PP-RXF-01

PP-RXF-01 defines how regulation/methodology, XBRL, PP-MAP, FOGE, SSSR, ZSSR and downstream execution remain semantically and constitutionally separated.

This profile provides the Runtime activation layer for the XBRL side of that architecture while preserving the canonical PP-CCPS release and activation lifecycle.

The combined flow is:

registered XBRL release
        │
        ▼
validated activation artefacts
        │
        ▼
PP-REL
        │
        ▼
PP-AR
        │
        ▼
PP-XRA activation admission rules
        │
        ▼
PP-ACT-backed Runtime resolution
        │
        ├──────────── exact taxonomy release ────────────┐
        │                                                │
        ▼                                                ▼
PP-MAP / PP-MD gate                              direct taxonomy use
for mapped semantic use                         where separately allowed
        │                                                │
        ▼                                                ▼
FOGE / validation / tagging / reporting consumers
        │
        ▼
separate rights / filing / publication gates as required

Activation is necessary for authoritative Runtime participation where this profile applies, but it is never sufficient for every downstream use.

---

23. Worked examples

23.1 Registered but not released or active

taxonomy registered            yes
registration sealed            yes
PP-REL                          none
PP-AR                           none
PP-ACT                          none
resolver result                 NOT_ACTIVE

The taxonomy MAY remain available for separately authorised internal analysis but is not Runtime-active.

23.2 Released but not active

PP-REL                          exists
released artefacts              exact/digested
PP-AR                           none
PP-ACT                          none
resolver result                 NOT_ACTIVE

Release readiness SHALL NOT be confused with activation.

23.3 Activation blocked by rights

PP-REL                          valid
technical validation            pass
Rights Gate                     Additional Permission Required
PP-ACT                          none
resolver result                 NOT_ACTIVE

The absence of a Block outcome is irrelevant. The gate is non-authorising until it affirmatively permits the exact activation context.

23.4 Internal-use conditional permission

Rights Gate                     Internal Use Only
requested tenant/audience       Viroway internal only
all Rights Gate conditions      satisfied
external publication authority  false

This MAY authorize only the exact internal activation context if canonical PP-RLCPS semantics and all conditions permit it. It SHALL NOT authorize customer-facing publication.

23.5 Intersecting scopes with identical release

activation A tenant scope       global
activation B tenant scope       tenant-123
same effective interval         yes
same taxonomy release           yes
explicit precedence/coalescing  none

The selector hashes differ, but both match tenant-123. The fact that both activations point to the same taxonomy release does not remove resolver multiplicity. Admission SHALL block unless an exact pinned governed rule deterministically reduces the result to one activation.

23.6 Governed multiplicity reduction

activation A tenant scope       global
activation B tenant scope       tenant-123
overlap                           yes
multiplicity contract            exact id/version/fingerprint pinned
contract result                  activation B only

The activation plan digest SHALL include that exact contract binding. Replacing the contract with a later version requires a new governed decision where it would alter the selected authority or cardinality.

23.7 Partial activation does not leak into failed scope

PP-ACT result                    partially_active
successful scope                 tenant-123
failed scope                     tenant-456
resolver context                 tenant-456
resolver result                  NOT_ACTIVE for this PP-ACT

The general activation scope does not override the exact partial-outcome partition. Historical replay preserves that tenant-456 failed even if a later retry succeeds.

23.8 Symmetric effective-start and expiration boundaries

activation A interval            [2026-09-15, 2026-10-01]
governed granularity             day
boundary semantics               inclusive
status before activation         future_effective
effective-start transition       2026-09-15
last included day                2026-10-01
expiration transition            2026-10-02
status after expiration          expired

The expiration transition does not incorrectly expire A at its still-included valid_to. Under a right-exclusive interval [2026-09-15, 2026-10-01), the corresponding expiration transition would ordinarily be 2026-10-01.

23.9 Future-effective activation boundary

activation recorded              2026-09-10T12:00Z
derived effective-start edge     2026-09-15T00:00Z
status before edge               future_effective
status at/after edge             active
boundary mode                    scheduled_boundary

The activation is authoritatively recorded before it becomes operative. A delayed boundary notification does not delay the authorized effective start.

23.10 Governed retroactive activation

derived effective-start edge     2026-09-01T00:00Z
canonical transaction time       2026-09-10T12:00Z
retroactivity mode               governed
decision authority               pinned
legal/policy basis               pinned
affected historical outcomes     enumerated
restatement/notification rules   pinned

Because effective start precedes recording, this is retroactive. It may affect a current Historical Reconstruction of September 1, but it does not rewrite what the system had recorded as known before September 10 and therefore does not contaminate exact replay of an execution from September 5.

23.11 Event-sourced cutover of an open-ended activation

activation A original interval   [2026-09-15T00:00Z, unbounded)
planned cutover event at T        2026-10-01T00:00Z
successor activation B starts T   yes
transition binding                atomic_with_activation

PP-ACT A is not mutated. The exact cutover transition is part of B's authorized plan and is persisted atomically with B. Under Section 14.5, A remains operative only before the governed cutover edge; B may be operative at/after its governed effective-start edge if every other gate passes.

23.12 Atomic suspension is fully authorized before apply

transition type                  suspension
mode                             atomic_with_activation
suspension start                 2026-10-01T00:00Z
expected end                     2026-10-15T00:00Z
reason                           governed maintenance cutover
affected scope                   tenant-123
emergency status                 false
reinstatement policy             exact pinned policy
authorized payload fingerprint   sha256:...

Apply may persist only the suspension payload authorized by the plan. Changing the end, reason, emergency status or reinstatement semantics requires a different plan digest and new authorization.

23.13 Plan-bound reinstatement

suspended activation             PP-ACT-A
transition type                  reinstatement
governing suspension evidence    exact pinned reference
reinstatement policy satisfied   yes
reinstatement effective at       2026-10-15T00:00Z
affected scope                   tenant-123
authority                        exact governed authority
authorized payload fingerprint   sha256:...

The activation does not become operative merely because the suspension's expected end has passed. The reinstatement is its own governed, plan-bound transition and participates in collision/order analysis if other resolver-affecting events occur at the same constitutional time.

23.14 Plan-bound revocation with governed transaction-time observation

activation A                     currently operative
transition type                  revocation
transition_effective_at T        2026-10-20T00:00Z
constitutional effective time    same T
historical-use treatment         preserve pre-T applicability
system of record                 exact governed identity
retroactivity guard              atomic_commit_constraint
transaction order contract       exact id/version/fingerprint
Clock Source                     exact id/version/fingerprint
successor activation B starts T  yes
mode                             atomic_with_activation

The plan authorizes one effective revocation instant, not two potentially divergent timestamps. The actual revocation transaction_time and transaction-order position are not fabricated before authorization; they are captured under the pinned successful system-of-record guard. If commit time is the observation point, the retroactivity predicate is evaluated inside that same commit before it can succeed.

23.15 Backdated revocation requires its own retroactivity authority

activation effective start       2026-09-01T00:00Z
activation transaction time      2026-09-01T00:00Z
revocation effective time        2026-09-10T00:00Z
revocation transaction time      2026-09-15T12:00Z
revocation retroactivity mode    governed
affected historical outcomes     enumerated
restatement/notification rules   pinned

The activation itself was not retroactive, but the revocation is. PP-XRA therefore requires a separate governed retroactivity decision for the revocation; activation-level retroactivity.mode: none cannot authorize the backdated lifecycle transition.

23.16 Commit-time retroactivity guard

observation point                database commit
retroactivity guard mode         atomic_commit_constraint
effective-start edge             2026-09-15T00:00Z
commit time                       system-generated at commit
mode                              none
constraint                        reject if edge < commit time

Because commit time is unknowable before commit, the same transaction must evaluate the predicate using the actual commit value and atomically reject the commit if it would make the activation or any newly recorded transition retroactive. A post-commit check is too late.

23.17 Complete transaction record

transaction_start                preserved
transaction_time                 governed authoritative observation
transaction_end                  preserved at successful completion
recording system/component       preserved
actor / execution id / event     preserved
prior/new version                preserved where applicable
provenance                       preserved

The selected transaction_time is not a substitute for the complete constitutional transaction boundary required by ZYZ-CRF-7 §23.70.1.

23.18 Delayed writer cannot cross retroactive authority with stale state

writer starts                    2026-09-10T11:59Z
writer authority snapshot        PP-ACT-A
writer fence established         before impact snapshot
retroactive authority commits    2026-09-10T12:00Z
writer becomes unblocked         2026-09-10T12:00:01Z
writer canonical commit          pending

The fence is already active before the activation accepts its protected impact-set snapshot. The writer therefore cannot slip into the interval between completeness checking and fence establishment. The same fence covers non-additive mutations, including a canonically mapped deletion/tombstone operation where permitted. If the pinned transaction-order contract does not constitutionally place the exact registered mutation/writer identity and resulting impact state before the authority, the writer is after the new authority and must re-resolve/recompute/re-evaluate or abort/retry. Releasing the activation lock does not grandfather stale authority.

23.19 Exact replay versus later retroactive evidence

original execution id            EXEC-1
original effective time          2026-09-05T12:00Z
original transaction boundary    2026-09-05T12:00Z
original result                  PP-ACT-A
later revocation recorded        2026-09-10T12:00Z
revocation effective from        2026-09-01T00:00Z
exact replay of EXEC-1           PP-ACT-A
current historical reconstruction may reflect revocation

Exact replay excludes the later-recorded revocation because it was outside EXEC-1's as-recorded transaction boundary, even though its effective time was backdated. A current Historical Reconstruction may incorporate it if the governed retroactivity and reconstruction policies permit that conclusion.

23.20 Exact constitutional replay

evaluation mode                  HISTORICAL_REPLAY
original execution id            EXEC-1
constitutional replay profile    EXACT
replay manifest                  immutable / pinned schema
as-recorded boundary             pinned in manifest
historical result                PP-ACT-A / XBRL release X
replayed governed result         PP-ACT-A / XBRL release X
equivalence                      exact

If the governed replayed resolver output differs under the pinned exact-equivalence contract, the runtime records replay drift rather than silently returning a current reconstructed result as historical truth.

23.21 Concurrent cross-activation transitions

expiration/cutover A -> B at T    planned
revocation C at T                 concurrent
reinstatement D at T              concurrent
ordering changes resolver result  yes
order contract                    exact id/version/fingerprint pinned

The events do not escape ordering control merely because they name different activation records. They affect the same resolver result and therefore require the exact deterministic order contract to be bound into the authorized activation plan before apply.

23.22 Current EFRAG ESRS Set 1 rights treatment

The currently registered temporary EFRAG ESRS Set 1 rights treatment is limited to private taxonomy custody, XBRL taxonomy projection and internal taxonomy analysis and explicitly creates no Runtime authority.

Accordingly, under this profile the present state is conceptually:

REGISTERED                         yes
POST-COMMIT VERIFIED               yes
TECHNICALLY ACTIVATION-PREPARED    potentially
RIGHTS-ELIGIBLE FOR ACTIVATION     no
RUNTIME ACTIVE                     no

A future activation request SHALL fail closed unless a new or superseding PP-RLCPS Rights Gate outcome affirmatively permits the exact intended Runtime activation context.

---

24. Prohibited shortcuts

The following are prohibited:

• adding a global mutable active flag to pp.xbrl_taxonomy_release as the source of Runtime authority;
• treating taxonomy registration as a canonical PP-REL;
• placing pp.xbrl_taxonomy_release directly into the canonical PP-ACT.release field;
• omitting the released-artefact digest boundary between PP-REL, PP-AR and PP-ACT;
• treating HECATE pass status as activation authority;
• treating one PP-RGT record as equivalent to the complete PP-RLCPS Rights Gate;
• treating any non-Block Rights Gate outcome as activation permission;
• activating when Rights Gate conditions are unsatisfied;
• treating activation as legal or semantic-mapping authority;
• treating activation as publication, filing or redistribution authority;
• selecting a taxonomy by latest publication or registration timestamp when no activation resolves;
• replacing canonical Runtime Context identity/fingerprint with an ad hoc selector hash;
• silently excluding Runtime Context dimensions without an authorised projection;
• detecting conflicts only where selector hashes are equal;
• resolving a partially_active activation through a failed scope;
• allowing an implementation library or database type to choose interval boundary semantics implicitly;
• assuming raw valid_from/valid_to are always the effective-start/expiration transition instants regardless of inclusive/exclusive semantics;
• defining an activation without governed status_before_activation and scheduled effective-start evidence;
• defining a finite interval without governed post-expiration state and scheduled expiration boundary;
• shifting effective start or expiration because boundary-event delivery was delayed;
• allowing a retroactive effective start without complete governed ZYZ-CRF-7 §23.68.4 evidence;
• allowing a newly recorded backdated lifecycle transition without its own complete governed §23.68.4 evidence;
• silently allowing apply delay to turn a non-retroactive activation or lifecycle transition into retroactive authority;
• treating a governed retroactivity authorization as open-ended permission when apply delay or concurrent activity adds, removes, corrects, retracts, invalidates, replaces, reclassifies or otherwise changes affected historical outcomes or required restatement/notification treatment;
• taking the governed-retroactivity protected impact-set snapshot before the exact plan-bound writer fence covers the complete canonical impact-mutation domain;
• hashing an impact-mutation domain before pinning the exact selector schema, writer-identity registry, mutation vocabulary and canonicalization contract;
• using free-form, service-local, inferred, normalized or aliased writer/mutation values instead of exact registered canonical identities;
• omitting deletion/tombstoning or another constitutionally possible impact-changing operation merely because the current service uses a different local enum/value;
• allowing different services to choose their own field ordering, set ordering, null handling, normalization or serialization when computing domain_fingerprint;
• defining the outcome-writer fence only over operations that add new outcomes while allowing corrections, retractions, invalidations, replacements, reclassifications or restatement/notification treatment updates to bypass it;
• releasing the activation guard and then allowing an in-flight/delayed covered writer to commit using a stale pre-authority snapshot without revalidation/recompute/re-evaluation;
• treating transaction start, queue position, provisional timestamp, reserved time or prior lock acquisition as sufficient to place a delayed writer constitutionally before a newly committed retroactive authority;
• treating delayed processing of a previously authorized scheduled boundary as a new retroactive authority decision;
• using commit as the authoritative transaction-time observation point without an enforceable atomic commit retroactivity constraint;
• claiming a pre-commit retroactivity check used a commit timestamp that was not yet available;
• using a reserved transaction timestamp/order unless the governed system of record guarantees those exact values become authoritative on successful commit;
• preserving only one transaction timestamp/order while omitting the ZYZ-CRF-7 §23.70.1 transaction start/end and transaction record fields;
• treating current Historical Reconstruction as identical to exact replay of an original execution;
• performing exact replay without the original Execution Identifier and as-recorded transaction boundary/order evidence;
• introducing later-recorded corrections, revocations or retroactive decisions into exact replay of an earlier execution;
• re-resolving a mutable/current/latest Temporal Profile instead of using the exact profile authorized in the plan;
• using HISTORICAL_REPLAY as a substitute for declaring the constitutional replay profile;
• replaying PP-XRA under BANDED, RECORDED or an implementation-defined profile rather than the governed EXACT profile;
• replaying without the immutable replay manifest and pinned exact-equivalence contract;
• silently accepting replay drift;
• allowing same-release or "compatible" overlaps merely because taxonomy payloads are equivalent;
• using an unpinned or mutable precedence/coalescing rule to resolve multiplicity;
• assuming broad-over-narrow scope precedence without an exact governed rule;
• authorizing a successor while relying on an unplanned future cutover/lifecycle event to end its predecessor;
• reinstating/resuming an activation through an unplanned event or merely because a suspension's expected end elapsed;
• revoking an activation through an unplanned event when that revocation affects the authorized resolver result;
• representing a revocation with two independent effective timestamps;
• preselecting or fabricating a revocation transaction_time before the constitutional system actually records the revocation;
• specifying only a Clock Source while leaving the authoritative transaction-time system of record, observation point, ordering, retroactivity guard or retry semantics undefined;
• allowing aborted/retried attempts to create authoritative transaction time outside the pinned transaction-time governance contract;
• substituting the authorized transaction-time governance during apply;
• treating revocation as a mutable status flag rather than an effective-time authority event with the complete ZYZ-CRF-7 §23.68.9 evidence contract;
• erasing pre-revocation historical applicability contrary to the governed historical-use treatment;
• authorizing an atomic suspension without binding its complete constitutional suspension payload or immutable payload fingerprint;
• authorizing an atomic reinstatement without binding its governing suspension evidence, reinstatement-policy satisfaction and complete authority-relevant payload;
• authorizing an atomic revocation without binding all authority-selected constitutional revocation semantics, transition-level retroactivity and the exact transaction-time governance contract;
• authorizing an order-sensitive atomic lifecycle batch without binding the exact transition-order contract identity/version/fingerprint;
• mutating an old PP-ACT merely to add valid_to after a lifecycle-ending event;
• allowing storage order, event-arrival order or activation identifier to decide concurrent resolver-affecting lifecycle authority;
• weakening suspension or revocation evidence below the applicable ZYZ-CRF-7 contract;
• storing required activation authority only in a derived binding because the canonical Core 1.0 contract lacks fields;
• claiming PP-XRA conformance before canonical PP-CCPS authority-carrier compatibility exists;
• using historical activation as current operational permission;
• mutating historical PP-ACT evidence to reflect current rights or runtime state;
• treating a derived pointer/materialized view as constitutional truth;
• bypassing PP-MAP/PP-MD purpose gates because a taxonomy is active; and
• activating a different plan than the exact digest explicitly authorised.

---

25. Implementation sequence and acceptance criteria

25.1 Architecture/profile contract — this document

This version establishes:

• registration → PP-REL → PP-AR → PP-ACT authority boundaries;
• released-artefact digest continuity;
• canonical Runtime Context binding;
• authorised context-projection semantics;
• selector and activation-plan fingerprints;
• exact Temporal Profile pinning;
• semantic scope-intersection rules;
• partial-activation successful/failed scope semantics;
• explicit interval-boundary semantics;
• governed status-before-activation and scheduled effective-start semantics;
• governed post-expiration state and first-excluded scheduled expiration semantics;
• right/left inclusive/exclusive boundary derivation under pinned precision/granularity;
• governed activation- and lifecycle-transition retroactivity under ZYZ-CRF-7 §23.68.4;
• executable pre-commit/commit retroactivity guards;
• plan-bound outcome-writer fencing/revalidation across every mutation that can change governed retroactivity impact-set membership, authoritative outcome state or restatement/notification treatment;
• canonical versioned selector/writer/mutation/canonicalization semantics for deterministic impact-mutation-domain fingerprints;
• explicit transaction-time system-of-record, observation-point, ordering and retry semantics;
• complete ZYZ-CRF-7 §23.70.1 transaction start/end and transaction-record preservation;
• temporal-overlap rules;
• resolver-multiplicity admission rules;
• multiplicity-contract pinning;
• authorized cutover/lifecycle-transition pinning;
• plan-bound reinstatement/resumption semantics;
• plan-bound revocation semantics with one effective instant and system-recorded transaction time;
• complete authority-selected atomic transition semantics;
• exact transition-order-contract pinning for order-sensitive collisions;
• lifecycle transition edge/order semantics across the resolver collision domain;
• full constitutional suspension and revocation evidence;
• constitutional EXACT replay profile, replay-manifest and equivalence semantics;
• exact replay bound to original Execution Identifier and as-recorded transaction snapshot;
• explicit separation between exact replay and current Historical Reconstruction;
• canonical Core 1.0 schema compatibility as a prerequisite;
• affirmative Rights Gate semantics;
• HECATE boundary;
• current versus historical resolver modes;
• lifecycle model;
• threat model;
• preflight/apply/post-commit invariants; and
• logical persistence requirements.

25.2 Canonical PP-CCPS machine-contract prerequisite

Before a PP-XRA activation-plan schema or runtime implementation is accepted, the canonical PP-CCPS machine contracts SHALL be evolved through their own governed process so that PP-AR, PP-ACT and lifecycle evidence can authoritatively carry or canonically reference the evidence required by this profile.

The existing closed Core 1.0 schemas SHALL NOT be silently widened in place merely to satisfy PP-XRA.

The canonical contract design SHALL cover at least:

• complete activation effective interval;
• interval boundary semantics;
• status before activation and exact first-included scheduled effective-start semantics;
• status after expiration and exact first-excluded scheduled expiration semantics for finite intervals;
• pinned boundary precision/granularity sufficient to derive inclusive/exclusive edges deterministically;
• exact Temporal Profile identity/version/fingerprint;
• activation-plan digest;
• Runtime Context or authorised projection binding;
• actual activation transaction time, transaction-order evidence and complete transaction-time governance contract;
• transaction start and transaction end where applicable;
• recording system, recording Component, actor, Execution Identifier, event, prior/new version and transaction provenance required by ZYZ-CRF-7 §23.70.1;
• executable retroactivity-guard contract supporting exact reserved authoritative time/order or an atomic commit-time constraint;
• exact outcome-writer-fence contract ensuring in-flight/delayed writers cannot cross a retroactive authority commit with stale authority state;
• exact impact-mutation selector-schema, writer-identity registry, mutation-vocabulary and canonicalization-contract bindings by identity/version/fingerprint;
• validated impact selector instance, canonical registered writer/mutation identity sets, reproducible canonical bytes/domain fingerprint and semantic coverage of every impact-changing operation including deletion/tombstoning where applicable;
• governed retroactivity evidence required by ZYZ-CRF-7 §23.68.4 where activation effective start precedes transaction time;
• governed transition-level retroactivity evidence where any newly recorded lifecycle transition effective edge precedes its own transaction time;
• exact successful/failed scope partition conditionally required for partially_active;
• constitutional replay profile EXACT, Replay Constitution binding, immutable replay-manifest reference/schema and exact-equivalence contract;
• original Execution Identifier, original effective-time coordinate(s), as-recorded transaction boundary/snapshot and transaction-order evidence required for exact replay;
• multiplicity-policy mode and exact multiplicity contract binding where used;
• exact planned/preexisting/scheduled lifecycle transition bindings—including effective start, expiration, suspension, reinstatement, revocation, rollback, retirement, supersession and cutover—required for deterministic authority;
• complete authority-selected semantics or immutable payload fingerprint for every atomic_with_activation lifecycle transition;
• deterministic assignment contracts for observational fields such as transaction time that can exist only at event recording;
• lifecycle transition edge semantics;
• affected resolution scope for lifecycle transitions;
• exact transition-order contract identity/version/fingerprint across all order-sensitive concurrent events that can change the same resolver result;
• complete revocation evidence required by ZYZ-CRF-7 §23.68.9, including revocation decision, authority, one canonical effective revocation time, actual transaction time/order, future-use prohibition, historical-use treatment, affected dependants and provenance;
• complete suspension evidence required by ZYZ-CRF-7 §23.68.10, including suspension start, expected/actual end, authority, reason, affected scope, emergency status, reinstatement policy and provenance;
• reinstatement evidence sufficient to prove satisfaction of the governing reinstatement policy, effective time, affected scope, resulting state, authority and provenance; and
• immutable provenance.

A derived XBRL runtime-binding table MAY project these fields only after the canonical authority carrier can represent them.

25.3 PP-XRA machine contract

After Section 25.2 is satisfied, the XBRL activation-plan JSON Schema SHOULD be introduced and validated against this profile before runtime implementation.

25.4 Physical architecture decision

Before the first database migration, implementation SHALL decide and document:

• physical schema ownership;
• representation of the PP-REL → XBRL released artefact binding;
• authoritative-event projection versus derived runtime-binding tables;
• Runtime Context / authorised projection persistence;
• partial-activation scope partition representation;
• exact Temporal Profile persistence/reference contract;
• status-before-activation/effective-start and status-after-expiration/expiration boundary representation;
• boundary-edge derivation under precision/granularity;
• activation- and transition-level retroactivity decision/evidence representation;
• transaction-time system-of-record, observation-point, normalization, ordering and retry semantics;
• retroactivity-guard implementation (reserved_authoritative_time versus atomic_commit_constraint);
• outcome-writer-fence implementation (shared_serialization versus commit_revalidation), including the canonical versioned selector schema, writer-identity registry, mutation vocabulary and canonicalization contract used for the impact-mutation domain, deterministic ordering/serialization rules, deletion/tombstone mapping where applicable and the requirement that the fence be established before the protected impact-set snapshot;
• complete transaction-start/end and §23.70.1 transaction-record representation;
• scope-intersection algorithm;
• interval-boundary representation and validation;
• temporal exclusion strategy;
• Replay Constitution/profile/manifest/equivalence persistence and replay-drift handling;
• original-execution/as-recorded transaction snapshot representation for exact replay;
• Historical Reconstruction service boundary distinct from replay;
• multiplicity/precedence/coalescing contract strategy;
• planned lifecycle-transition authorization and atomicity strategy;
• atomic transition semantic canonicalization/fingerprinting strategy;
• lifecycle transition evidence and resolver-collision ordering strategy;
• transition-order contract representation and lookup strategy;
• suspension/reinstatement/revocation/expiration/effective-start representation;
• revocation historical-use-treatment representation;
• locking/serialization strategy;
• current-pointer strategy;
• transaction boundary;
• rollback representation;
• resolver storage-access contract; and
• SSSR/USO/ZAR/ALTD bindings where applicable.

25.5 Database/runtime implementation

Only after architecture review and the canonical PP-CCPS machine-contract prerequisite in Section 25.2 are complete SHALL the system add the runtime activation persistence/migration, activation-plan schema, planner, preflight, apply runner, post-commit verifier and resolver implementation.

25.6 Acceptance criteria

A conforming implementation of PP-XRA-01 SHALL demonstrate that:

1. registration, PP-REL release and Runtime activation are distinct;
2. pp.xbrl_taxonomy_release remains free of a global authoritative active flag;
3. every activation uses canonical PP-REL, PP-AR and PP-ACT objects;
4. PP-ACT.release points to exact PP-REL, not directly to the XBRL taxonomy registry row;
5. released and activated artefact digests are identical;
6. rollback uses canonical PP-RBK semantics;
7. exact taxonomy registration evidence remains pinned in addition to the canonical release boundary;
8. activation binds to full canonical Runtime Context fingerprint or a conforming authorised projection;
9. authorised projections preserve source context identity, included/excluded dimensions, exclusion rationale, target capability, fingerprint and provenance;
10. selector fingerprints do not replace canonical Runtime Context fingerprints;
11. activation effective time, transaction time and reporting time remain distinct;
12. CRP resolves the applicable Temporal Profile before authorization;
13. every activation pins exact Temporal Profile identity/version/fingerprint;
14. the pinned Temporal Profile is part of the activation-plan digest and historical replay;
15. every activation interval declares boundary semantics conforming to ZYZ-CRF-7;
16. interval boundary semantics are bound into the activation-plan digest;
17. every activation declares status_before_activation and an exact scheduled effective-start boundary at the first included governed instant;
18. every finite interval declares status_after_expiration and an exact scheduled expiration boundary at the first excluded governed instant;
19. left/right-inclusive and left/right-exclusive edges are derived under the pinned precision/granularity rather than by assuming raw endpoint equality;
20. delayed boundary-event delivery cannot shift an authorized effective-start or expiration edge;
21. an activation whose derived effective start precedes actual canonical transaction time is treated as retroactive and cannot commit without complete governed ZYZ-CRF-7 §23.68.4 evidence;
22. apply delay cannot silently turn a non-retroactive authorization into retroactive authority;
23. authoritative transaction time is assigned by a pinned contract identifying system of record, recording Component, observation point, Clock Source, normalization/precision/granularity, transaction-order semantics, retry behavior and executable retroactivity guard;
24. aborted/retried attempts do not silently become authoritative transaction history;
25. a partially_active result preserves exact successful and failed scopes;
26. failed partial-activation scopes never resolve that activation as active;
27. historical replay uses the exact historical partial-activation scope partition recorded for the original execution;
28. semantic scope intersection is evaluated independently of selector-hash equality;
29. temporal overlap is evaluated using declared boundary semantics, derived effective edges and pinned Temporal Profiles;
30. admission rejects any overlap that could leave more than one applicable activation for a Runtime Context/time unless an exact governed rule or exact authorized lifecycle transition reduces the result to exactly one;
31. identical or compatible taxonomy releases do not bypass the multiplicity rule;
32. every multiplicity-reducing contract is pinned by exact identity/version/fingerprint in the authorized plan and replay evidence;
33. every lifecycle/boundary transition required to make a successor activation, effective start, expiration, reinstatement or revocation deterministic is preexisting/pinned, atomic/authorized or an authorized scheduled boundary;
34. a required cutover transition is included in the activation-plan digest and re-proved/persisted during apply;
35. resumption uses the canonical plan-bound reinstatement transition type and never occurs merely because a suspension's expected end passed;
36. revocation uses the canonical plan-bound revocation transition type whenever it changes resolver applicability/cardinality;
37. revocation has one canonical effective instant: transition_effective_at equals the constitutional effective revocation time;
38. an atomic revocation never preselects a literal future transaction time; actual transaction time/order is captured through the pinned successful system-of-record guard;
39. every atomic_with_activation transition binds its complete authority-selected semantics or immutable fingerprint before authorization;
40. every atomic suspension binds the full ZYZ-CRF-7 §23.68.10 suspension payload before authorization;
41. every atomic reinstatement binds the governing suspension evidence, reinstatement-policy satisfaction, effective time, scope, resulting state, authority and provenance before authorization;
42. every atomic revocation binds all authority-selected ZYZ-CRF-7 §23.68.9 semantics plus exact transition-retroactivity and transaction-time governance before authorization;
43. revocation prevents future/current use from its effective revocation time while preserving the bitemporal distinction between effective history and what was recorded when;
44. every order-sensitive concurrent lifecycle collision binds the exact transition-order contract identity/version/fingerprint in the authorized plan and digest before apply;
45. the PP-XRA resolver declares constitutional replay profile EXACT rather than treating HISTORICAL_REPLAY as a replay profile;
46. every replayable execution possesses an immutable replay manifest governed by the pinned manifest schema;
47. every replay manifest required for exact replay preserves original Execution Identifier, effective-time coordinate(s), as-recorded transaction boundary/snapshot and transaction-order evidence;
48. exact replay consumes only evidence recorded within the original execution's as-recorded transaction boundary and does not silently incorporate later retroactive/corrective evidence;
49. current Historical Reconstruction is a separate ZYZ-CRF-7 §23.71 operation and is never substituted for the original exact replay result;
50. exact replay equivalence is evaluated under a pinned identity/version/fingerprint contract and divergence creates replay-drift evidence rather than silent substitution;
51. HECATE validates eligibility but does not activate;
52. the canonical PP-RLCPS Rights Gate is mandatory;
53. activation requires an outcome that affirmatively permits the exact activation context with all conditions satisfied;
54. Legal Review Required, Additional Permission Required, Block, Quarantine and Unable to Determine are non-authorising;
55. Internal Use Only, Restricted Audience and conditional outcomes authorize only within their exact satisfied boundaries;
56. runtime activation grants no legal or semantic-mapping authority;
57. runtime activation grants no publication, filing or redistribution authority;
58. PP-MAP/PP-MD purpose gates remain independent;
59. lifecycle/boundary transitions apply post-transition state at their governed transition instant and prior state only before it;
60. an existing immutable open-ended PP-ACT is not mutated merely to add a later valid_to;
61. suspension evidence preserves every field required by ZYZ-CRF-7 §23.68.10;
62. revocation evidence preserves every field required by ZYZ-CRF-7 §23.68.9, including actual transaction time/order generated at recording;
63. the transition-order collision domain includes all concurrent/same-time events capable of changing the same Runtime Context/resolver result, even when they name different activations;
64. order-sensitive concurrent resolver-affecting transitions use the exact plan-bound transition-order contract or fail closed;
65. zero applicable activations resolve as not active;
66. more than one applicable activation resolves as ambiguity unless the exact authorized multiplicity/lifecycle rules yield exactly one result;
67. no hidden latest-taxonomy, latest-Temporal-Profile or latest-precedence-rule fallback exists;
68. current operational resolution evaluates current transaction state, effective boundaries, lifecycle and current rights;
69. exact historical replay reproduces the original execution under its historical pinned Temporal Profile, partial-scope partition, lifecycle transition semantics/order, multiplicity contract and as-recorded transaction boundary;
70. later-recorded expiration events, suspension, reinstatement, revocation, rollback, retirement, rights changes, corrections or retroactive decisions do not alter the input set of an earlier exact replay;
71. current Historical Reconstruction may separately incorporate later-recorded evidence according to governed temporal/reconstruction policy without overwriting the original replay result;
72. present-day permission to perform/access replay is evaluated separately from the original historical result and exact replay equivalence;
73. canonical PP-CCPS machine contracts can authoritatively represent or canonically reference all required PP-XRA evidence before activation is permitted;
74. derived pointers and runtime bindings are non-authoritative and reconstructable;
75. apply re-proves material preflight predicates, including activation and transition retroactivity at the authoritative transaction-time guard;
76. authorization is bound to the exact activation-plan digest;
77. current pointer/binding changes occur only after authoritative activation and required lifecycle-transition/boundary evidence is committed or registered;
78. independent post-commit verification reconstructs the selected state including effective-start/expiration edges, pre/post states, activation/transition retroactivity, complete transaction start/time/end and §23.70.1 record, partial-scope partition, Temporal Profile, boundary semantics, atomic transition semantics, reinstatement evidence, revocation evidence/historical-use treatment, replay governance/manifest/as-recorded boundary/equivalence, transition-order contract and multiplicity rule; and
79. no taxonomy becomes runtime-active merely because this document, a machine schema, registration, PP-REL or derived binding exists.
80. every newly recorded authority-bearing lifecycle transition whose effective edge precedes its own canonical transaction time is governed as retroactive independently of whether the activation itself is retroactive;
81. a commit-time authoritative observation point is permitted only when an exact atomic commit constraint can reject the same transaction using that actual commit-time value, otherwise exact authoritative time/order must be reserved before the irreversible point;
82. every constitutionally significant activation/lifecycle transaction preserves transaction start and transaction end where applicable in addition to the selected authoritative transaction time/order;
83. canonical transaction evidence preserves recording system, recording Component, actor, Execution Identifier, event, prior/new version and provenance as required by ZYZ-CRF-7 §23.70.1;
84. delayed processing of a pre-authorized scheduled boundary never creates new retroactive authority or shifts the authorized effective edge;
85. every mode: governed retroactivity decision is revalidated against the exact affected historical-outcome membership/state, restatement treatment and notification treatment at the guarded authoritative transaction boundary, with any intervening mutation forcing transaction abort and a refreshed plan/digest plus new governed authorization;
86. every writer/operation capable of mutating a governed retroactive impact domain is controlled by the exact plan-bound outcome-writer fence, which covers a deterministic digest-bound impact-mutation domain and is established before the protected impact-set snapshot and remains effective through activation commit; a covered mutation that commits after a retroactive authority change must revalidate/recompute/re-evaluate under current authority or prove exact prior transaction ordering plus prior inclusion of that exact mutation/resulting impact state in the authorized analysis;
87. the impact-mutation domain itself is deterministic and plan-bound by selector/projection, covered writer classes, covered mutation classes and fingerprint, and cannot be narrowed to outcome creation alone or substituted after authorization; and
88. every impact-mutation domain pins an exact versioned selector schema, canonical writer-identity registry, canonical mutation vocabulary and canonicalization contract; uses only exact registered writer/mutation identities; deterministically canonicalizes and orders domain material before hashing; maps every impact-changing operation including deletion/tombstoning where applicable; and fails closed rather than inventing a missing controlled value.

---

26. Final governing principle

Runtime activation is not a property of an XBRL taxonomy release. It is a governed, scoped, bitemporal authority relation between an explicit constitutional Runtime Context and exact artefacts released through canonical PP-REL. PP-AR requests that activation; PP-ACT records the authority while preserving the exact PP-REL, released-artefact digests, exact applicable scope, effective interval and complete canonical transaction history through a compatible authority carrier. Effective start and expiration are symmetric scheduled boundaries derived from explicit interval semantics and pinned precision/granularity; retroactive effect—whether created by activation or by a later authority-bearing lifecycle transition—requires its own governed authority and never rewrites what was previously recorded. Resolver-affecting lifecycle transitions—including reinstatement and revocation—are plan-bound authority inputs whose authority-selected semantics, retroactivity treatment and ordering contracts are fixed before authorization. Observational transaction time/order is established only through an executable governed system-of-record contract: commit itself may be the observation point only with an atomic commit constraint, otherwise the exact authoritative time/order must be reserved before the irreversible point. Governed retroactivity additionally uses a plan-bound outcome-writer fence over a canonical impact-mutation domain whose selector schema, writer identities, mutation vocabulary and canonicalization rules are each versioned, fingerprinted and bound before the domain itself is hashed. Implementations use only exact registered identities, deterministic canonical bytes/order and complete semantic coverage—including deletion/tombstoning where applicable—and fail closed if a required controlled value does not yet exist. That fence is established over the complete mutation conflict domain before the protected impact snapshot is taken and remains effective through commit, so in-flight or delayed writers cannot alter the authorized §23.68.4 impact analysis or cross the authority commit with stale state: they must either be constitutionally ordered before the authority with that exact canonical mutation/resulting state already covered by the impact analysis, or re-resolve/recompute/re-evaluate under the committed authority before recording. Every constitutionally significant change also preserves transaction start/end and the full ZYZ-CRF-7 §23.70.1 transaction record. Exact historical replay is bound to the original Execution Identifier and as-recorded transaction snapshot under the EXACT profile, while current Historical Reconstruction remains a separate bitemporal question. Runtime bindings and pointers merely project authority; consumers resolve through it; and every distinct downstream legal, semantic, rights, filing or publication authority remains separately governed.