# Cryptographic Provenance Systems Validate Continuity of Authorization, Not Correctness of Authorization

- **Artifact ID:** CHQ-P-2026-016
- **Version:** v1.5
- **Status:** ACTIVE
- **Public record:** https://record.cybersecurityhq.com/positions/chq-p-2026-016
- **Machine-record SHA-256:** `745ac08a39e96e7d73e9b3ad0a197289a5ece149866bd32389e06ac65eff3db5`

## Canonical text

```text
[SECTION] POSITION METADATA
POSITION_ID=CHQ-P-2026-016
VERSION=v1.5
STATUS=ACTIVE
EFFECTIVE=2026-05-04
TITLE=Cryptographic Provenance Systems Validate Continuity of Authorization, Not Correctness of Authorization
DOCTRINE_FAMILY=SUPPLY_CHAIN_INTEGRITY
ASSUMPTION_INVALIDATED=PROVENANCE_AS_AUTHORIZATION
PRESSURE_CLASS=STRUCTURAL
POSITION_TYPE=STRUCTURAL_CONDITION
SIGNAL_COUNT=6
DURABILITY_CLASS=STRUCTURAL
EVIDENCE_STATE=CONFIRMED
VECTOR_COUNT=6
LENS=LENS-001
PATTERN_REGISTER_ID=CHQ-PR-016
SOURCE_SIGNALS=SN-2026-03-19-01, SN-2026-03-20-01, SN-2026-03-31-01, SN-2026-04-30-01, SN-2026-05-01-01, SN-2026-05-01-02
GOVERNING_CONSTRAINT=CHQ-ASC-2026-001, CHQ-ASC-2026-003, CHQ-ASC-2026-004
ISSUANCE_GATE=CHQ-D-2026-PIG v1.0
REVISION_POLICY=Amendment only

[SECTION] AMENDMENT NOTE
AMENDMENT AMD-001 · JULY 24, 2026 · REINFORCEMENT
Window reinforcement recorded. Every backdoored package version in the July 2026 npm campaign shipped through cryptographically intact official channels with valid publishing identities. All provenance checks passed while authorization was wrong at the publishing-identity layer; the malicious code executed at import time, past install-focused scanning. Canonical evidence basis and counts are unchanged; the reinforcement is recorded at the evidence layer.

AMENDMENT AMD-2026-09-22-POSITION-RECORD-CORRECTIVE-WAVE · SEPTEMBER 22, 2026 · POSITION RECORD STANDARD CORRECTION. Canonical field semantics, evidence counts, identifiers, independence wording, and publication integrity corrected in one dated wave.

AMENDMENT CHQ-PRS-2026-001-AMD-002 · SEPTEMBER 22, 2026 · DOCKET SUCCESSION CORRECTION. No new evidence docket was issued. CHQ-ED-2026-020 remains the unchanged primary evidence record; CHQ-ED-2026-021 remains locked as the July supplementary record.

AMENDMENT CHQ-RAT-2026-001-CANONICAL-TEXT-EXECUTION-WAVE · SEPTEMBER 22, 2026 · CANONICAL TEXT EXECUTION. Scheduled prose constructions rewritten for grammatical clarity without changing the underlying judgment.

AMENDMENT CHQ-PRS-2026-001-AMD-003 · SEPTEMBER 22, 2026 · GOVERNING CONSTRAINT APPLICABILITY. Governing Constraint was audited under the ratified PRS-06.5 material-applicability test. Default citations were removed, materially load-bearing constraints were retained or added, the prior version and hash were preserved, and the canonical hash was recomputed.

[SECTION] EVIDENCE BASIS
PRIMARY: Six mechanism-independent demonstrations across a forty-three day window establish this as a structural condition rather than an implementation failure class.

Mechanism 1: GitHub Actions tag reference inheritance (March 2026). The Trivy GitHub Actions compromise documented in CHQ-EX-2026-009 demonstrated that Actions runners inherit execution authority from tag references without verifying that the referenced code has the right to exercise that authority. The tag reference was the provenance signal. The tag had been force-pushed to a malicious payload. The provenance chain was intact. The authorization was not. Source: Wiz / Aqua Security.

Mechanism 2: npm postinstall hook authority (March 2026). GlassWorm Wave 3 / CanisterWorm documented in CHQ-EX-2026-009 demonstrated that npm's postinstall hook mechanism executes with full access to the developer environment as a design feature. The registry accepted publication because the token was valid. Token validity verified continuity, and the credential chain was intact. It did not verify that the publishing entity was the legitimate maintainer. Source: Aikido / Socket / Endor Labs.

Mechanism 3: OIDC trusted publishing workflow modification (April 2026). Mini Shai-Hulud documented in CHQ-EX-2026-017 demonstrated that OIDC trusted publishing, deployed to improve on long-lived token security, produced signed packages from the official SAP scope because the attacker modified the workflow that earned the token. Every verification primitive confirmed continuity. The packages were signed, scoped correctly, and attested. None confirmed correctness. Source: ReversingLabs / SAP Security Advisory.

Mechanism 4: Maintainer account credential compromise (March 2026). UNC1069/Axios documented in CHQ-EX-2026-015 demonstrated that compromise of a maintainer's npm credentials produced publications that passed all registry-level verification. The credential was the provenance anchor. Verification of credential validity confirmed continuity. The credential had been stolen. Correctness of authorization was not verified. Source: Datadog Security Research.

Mechanism 5 was removed under PRS-14.5 because the GitHub push-option finding does not instantiate the position claim.

Mechanism 6: Credential aggregation plane extraction (April 2026). LiteLLM CVE-2026-42208 documented in CHQ-EX-2026-016 demonstrated that an AI gateway holding aggregated credentials for multiple upstream providers presented valid provider credentials that were continuously valid, correctly formatted, and properly scoped, while the gateway itself had been compromised at the authentication layer. Upstream providers verified continuity. They could not verify correctness. Source: Sysdig Threat Research.
SUPPORTING: Each of the six mechanisms is independent. No two mechanisms share a technical failure class, a common actor, or a common ecosystem. GitHub Actions tag reference inheritance, npm postinstall hook authority, OIDC workflow modification, maintainer credential theft, git push pipeline injection, and AI gateway credential aggregation all demonstrate the same structural condition through different technical paths.
SUPPORTING: The structural condition is not an implementation failure. It is a property of where cryptographic verification primitives operate relative to where authority is exercised. Provenance systems verify artifacts after they are produced. They cannot verify the integrity of the production environment that generated them.

[SECTION] AUTHORITY DERIVATION
No constraint derivation applies. This is a standalone Position.

[SECTION] GOVERNING CONSTRAINT
CHQ-ASC-2026-001
CHQ-ASC-2026-003
CHQ-ASC-2026-004

[SECTION] SCOPE OF APPLICATION
This Position applies to decisions involving software supply chain architecture, package registry trust models, CI/CD pipeline credential governance, and artifact provenance assessment.

It applies wherever organizations treat provenance chain verification as evidence of supply chain integrity. This describes the dominant governance posture across regulated industries, cloud-native environments, and software distribution ecosystems.

It does not evaluate specific cryptographic implementations, specific registry verification systems, the adequacy of any particular SLSA level for a specific threat model, or prescriptive pipeline hardening configurations.

[SECTION] POSITION STATEMENT
Cryptographic provenance systems verify that an authorization chain is continuous. They do not and cannot verify that authorization at any point in the chain was correct.
Cryptographic provenance systems, including package signing, OIDC trusted publishing, SLSA-based attestation, and software bill of materials verification, validate that an authorization chain is continuous. They do not and cannot validate that authorization at any point in the chain was correct.

When an attacker controls one authorized link in a provenance chain, the chain remains cryptographically intact. Signature verification confirms that the package matches what was published. Attestation confirms that the build occurred in a claimed environment. Token validation confirms that the credential presented was legitimately issued. None of these verification mechanisms can confirm that the entity exercising the authorization was the entity the authorization was intended for.

Organizations that treat provenance chain integrity as evidence of supply chain security are conflating two structurally distinct properties: continuity of authorization, which cryptographic systems can verify, and correctness of authorization, which they cannot. The gap between these properties is the attack surface that supply chain threat actors are systematically operating against.

[SECTION] STRUCTURAL OBSERVATION
CHQ-P-2026-015 (Execution Pipelines Function as Control Planes Without Verification Primitives Capable of Validating the Authority They Execute): P-015 establishes the structural condition that execution pipelines exercise control plane authority without verification. CHQ-P-2026-016 establishes the reason the verification primitives cannot validate the authority: they verify continuity, not correctness. P-016 is upstream of P-015. The execution pipeline control plane problem is downstream of the provenance verification property problem.

CHQ-P-2026-013 (Portable Developer Identity Cannot Contain Credential Compromise Across Registries): Developer identity functions as the provenance anchor across registries. CHQ-P-2026-016 establishes why valid developer identity is not sufficient evidence of authorized publication: identity verification confirms that the credential is continuous, not that the credential is currently in the control of the authorized holder. P-013 identifies the propagation surface. P-016 establishes the structural reason propagation is possible.

CHQ-P-2026-011 (Deployed Security Tool Presence Cannot Serve as Evidence of Functioning Control): The same structural logic applies in both directions. Tool presence does not verify tool efficacy. Provenance chain integrity does not verify authorization correctness. Both are continuity signals that organizations treat as correctness signals. P-011 and P-016 identify the same structural failure mode in adjacent domains.

[SECTION] ARCHITECTURAL IMPLICATION
The position rests on a property of cryptographic verification systems that is architectural, not implementation-specific. Provenance systems are designed to answer: "Is this the artifact that was produced by this process from this source?" They are not designed to answer: "Was the process that produced this artifact controlled by the entity who was supposed to control it?"

The first question is answerable cryptographically. The second is not, because the answer depends on the runtime state of the publishing environment: the actual integrity of the CI/CD workflow, the actual security state of the developer account, and the actual absence of malicious modification in the build toolchain. These are environmental properties that exist upstream of the artifact boundary at which provenance verification operates.

This is not a failure of cryptographic implementation. It is a structural property of where verification primitives operate relative to where authority is exercised. Provenance systems verify artifacts after they are produced. They cannot verify the integrity of the production environment that generated them.

A-018 (Cryptographic validity implies trustworthy provenance and safe execution context) is directly under pressure on issuance. Six mechanism-independent demonstrations establish that cryptographic validity confirms continuity of authorization, not correctness of authorization. Cryptographic validity of a package signature, OIDC token, or provenance attestation confirms that the artifact was produced by a process that had valid credentials. It does not confirm that those credentials were in the control of the authorized entity at the time of production.

[SECTION] EVIDENTIAL RECORD
TITLE=CybersecurityHQ Cryptographic Provenance Continuity-Not-Correctness Evidence
DOCKET=CHQ-ED-2026-020
EXHIBITS=CHQ-EX-2026-009, CHQ-EX-2026-015, CHQ-EX-2026-016, CHQ-EX-2026-017, CHQ-EX-2026-018
SIGNALS=SN-2026-03-19-01, SN-2026-03-20-01, SN-2026-03-31-01, SN-2026-04-30-01, SN-2026-05-01-01, SN-2026-05-01-02

[SECTION] STRUCTURAL CONSEQUENCE
The structural consequence is that the supply chain security governance model built on provenance verification has a structural blind spot. Organizations that have deployed package signing, OIDC trusted publishing, SLSA attestation, and software bill of materials verification have improved their ability to detect direct artifact tampering. They have not improved their ability to detect compromise of the production environment upstream of the verification boundary.

The adversary operating model documented across the six mechanisms exploits this blind spot precisely: gain control of one authorized link, produce artifacts that will pass all verification, distribute through legitimate channels. The verification infrastructure confirms the attack succeeded. It cannot detect that the production environment was compromised.

The position's force reduces in environments where runtime integrity of the production environment is independently verified at execution time: hardware-rooted attestation of the build environment, continuous integrity monitoring of CI/CD workflow definitions, independent verification of publisher identity at every step in the publication chain. These controls shift the verification boundary upstream. They are not widely deployed at ecosystem scale.

[SECTION] BOUNDARY OF APPLICATION
Prescriptive pipeline hardening or dependency pinning recommendations
Vendor-specific registry verification system evaluation
SLSA level adequacy assessments for specific threat models
Regulatory compliance requirements for software supply chain governance

[SECTION] SUGGESTED CITATION
CybersecurityHQ Position
"Cryptographic Provenance Systems Validate Continuity of Authorization, Not Correctness of Authorization"
CHQ-P-2026-016
Version 1.5
2026-05-04

[SECTION] POSITION STATUS
STATUS=ACTIVE
VERSION=v1.5

[SECTION] RECORD INTEGRITY
SCOPE=PRS-03.1 CANONICAL TEXT (NOT RENDERING)
VERSION=v1.5

[SECTION] DOCTRINAL ALIGNMENT
Standalone Position

[SECTION] REFERENCE CONDITIONS
Authored independently of any subscribing organization
Not tailored to a specific contractual, commercial, or advocacy interest
Subsequent analysis based only on new evidence

[SECTION] LINKED CONDITIONS

[SECTION] LINKED ASSUMPTIONS
```

## Complete structured record

```json
{
  "id": "CHQ-P-2026-016",
  "title": "Cryptographic Provenance Systems Validate Continuity of Authorization, Not Correctness of Authorization",
  "status": "ACTIVE",
  "version": "v1.5",
  "snapshot_date": "2026-05-04",
  "doctrine_family": "SUPPLY_CHAIN_INTEGRITY",
  "assumption_class": "PROVENANCE_AS_AUTHORIZATION",
  "pressure_class": "STRUCTURAL",
  "position_type": "STRUCTURAL_CONDITION",
  "signal_count": 6,
  "pattern_register_id": "CHQ-PR-016",
  "durability_class": "STRUCTURAL",
  "evidence_state": "CONFIRMED",
  "vector_count": 6,
  "lens": "LENS-001",
  "source_signals": [
    "SN-2026-03-19-01",
    "SN-2026-03-20-01",
    "SN-2026-03-31-01",
    "SN-2026-04-30-01",
    "SN-2026-05-01-01",
    "SN-2026-05-01-02"
  ],
  "governing_acj": [
    "CHQ-ASC-2026-001",
    "CHQ-ASC-2026-003",
    "CHQ-ASC-2026-004"
  ],
  "evidence_docket": "CHQ-ED-2026-020",
  "evidence_dockets": [
    {
      "docket": "CHQ-ED-2026-020",
      "issue_date": "2026-05-04",
      "position_version": "v1.0"
    },
    {
      "docket": "CHQ-ED-2026-027",
      "issue_date": "2026-06-09",
      "position_version": "v1.0"
    },
    {
      "docket": "CHQ-ED-2026-021",
      "issue_date": "2026-07-24",
      "position_version": "v1.1",
      "relationship": "AMENDMENT"
    }
  ],
  "prior_evidence_dockets": [
    {
      "docket": "CHQ-ED-2026-027",
      "relationship": "REINFORCEMENT",
      "position_version": "v1.0"
    },
    {
      "docket": "CHQ-ED-2026-021",
      "relationship": "SUPPLEMENTARY",
      "position_version": "v1.1"
    }
  ],
  "extends_position": null,
  "doctrine_statement": "Cryptographic provenance systems verify that an authorization chain is continuous. They do not and cannot verify that authorization at any point in the chain was correct.",
  "evidence_basis": {
    "primary": "Six mechanism-independent demonstrations across a forty-three day window establish this as a structural condition rather than an implementation failure class.\n\nMechanism 1: GitHub Actions tag reference inheritance (March 2026). The Trivy GitHub Actions compromise documented in CHQ-EX-2026-009 demonstrated that Actions runners inherit execution authority from tag references without verifying that the referenced code has the right to exercise that authority. The tag reference was the provenance signal. The tag had been force-pushed to a malicious payload. The provenance chain was intact. The authorization was not. Source: Wiz / Aqua Security.\n\nMechanism 2: npm postinstall hook authority (March 2026). GlassWorm Wave 3 / CanisterWorm documented in CHQ-EX-2026-009 demonstrated that npm's postinstall hook mechanism executes with full access to the developer environment as a design feature. The registry accepted publication because the token was valid. Token validity verified continuity, and the credential chain was intact. It did not verify that the publishing entity was the legitimate maintainer. Source: Aikido / Socket / Endor Labs.\n\nMechanism 3: OIDC trusted publishing workflow modification (April 2026). Mini Shai-Hulud documented in CHQ-EX-2026-017 demonstrated that OIDC trusted publishing, deployed to improve on long-lived token security, produced signed packages from the official SAP scope because the attacker modified the workflow that earned the token. Every verification primitive confirmed continuity. The packages were signed, scoped correctly, and attested. None confirmed correctness. Source: ReversingLabs / SAP Security Advisory.\n\nMechanism 4: Maintainer account credential compromise (March 2026). UNC1069/Axios documented in CHQ-EX-2026-015 demonstrated that compromise of a maintainer's npm credentials produced publications that passed all registry-level verification. The credential was the provenance anchor. Verification of credential validity confirmed continuity. The credential had been stolen. Correctness of authorization was not verified. Source: Datadog Security Research.\n\nMechanism 5 was removed under PRS-14.5 because the GitHub push-option finding does not instantiate the position claim.\n\nMechanism 6: Credential aggregation plane extraction (April 2026). LiteLLM CVE-2026-42208 documented in CHQ-EX-2026-016 demonstrated that an AI gateway holding aggregated credentials for multiple upstream providers presented valid provider credentials that were continuously valid, correctly formatted, and properly scoped, while the gateway itself had been compromised at the authentication layer. Upstream providers verified continuity. They could not verify correctness. Source: Sysdig Threat Research.",
    "supporting": [
      "Each of the six mechanisms is independent. No two mechanisms share a technical failure class, a common actor, or a common ecosystem. GitHub Actions tag reference inheritance, npm postinstall hook authority, OIDC workflow modification, maintainer credential theft, git push pipeline injection, and AI gateway credential aggregation all demonstrate the same structural condition through different technical paths.",
      "The structural condition is not an implementation failure. It is a property of where cryptographic verification primitives operate relative to where authority is exercised. Provenance systems verify artifacts after they are produced. They cannot verify the integrity of the production environment that generated them."
    ]
  },
  "doctrinal_alignment": [],
  "revision_policy": "Amendment only",
  "esg_reference": "CHQ-D-2026-PIG v1.0",
  "scope": "This Position applies to decisions involving software supply chain architecture, package registry trust models, CI/CD pipeline credential governance, and artifact provenance assessment.\n\nIt applies wherever organizations treat provenance chain verification as evidence of supply chain integrity. This describes the dominant governance posture across regulated industries, cloud-native environments, and software distribution ecosystems.\n\nIt does not evaluate specific cryptographic implementations, specific registry verification systems, the adequacy of any particular SLSA level for a specific threat model, or prescriptive pipeline hardening configurations.",
  "position_statement": "Cryptographic provenance systems, including package signing, OIDC trusted publishing, SLSA-based attestation, and software bill of materials verification, validate that an authorization chain is continuous. They do not and cannot validate that authorization at any point in the chain was correct.\n\nWhen an attacker controls one authorized link in a provenance chain, the chain remains cryptographically intact. Signature verification confirms that the package matches what was published. Attestation confirms that the build occurred in a claimed environment. Token validation confirms that the credential presented was legitimately issued. None of these verification mechanisms can confirm that the entity exercising the authorization was the entity the authorization was intended for.\n\nOrganizations that treat provenance chain integrity as evidence of supply chain security are conflating two structurally distinct properties: continuity of authorization, which cryptographic systems can verify, and correctness of authorization, which they cannot. The gap between these properties is the attack surface that supply chain threat actors are systematically operating against.",
  "context": "CHQ-P-2026-015 (Execution Pipelines Function as Control Planes Without Verification Primitives Capable of Validating the Authority They Execute): P-015 establishes the structural condition that execution pipelines exercise control plane authority without verification. CHQ-P-2026-016 establishes the reason the verification primitives cannot validate the authority: they verify continuity, not correctness. P-016 is upstream of P-015. The execution pipeline control plane problem is downstream of the provenance verification property problem.\n\nCHQ-P-2026-013 (Portable Developer Identity Cannot Contain Credential Compromise Across Registries): Developer identity functions as the provenance anchor across registries. CHQ-P-2026-016 establishes why valid developer identity is not sufficient evidence of authorized publication: identity verification confirms that the credential is continuous, not that the credential is currently in the control of the authorized holder. P-013 identifies the propagation surface. P-016 establishes the structural reason propagation is possible.\n\nCHQ-P-2026-011 (Deployed Security Tool Presence Cannot Serve as Evidence of Functioning Control): The same structural logic applies in both directions. Tool presence does not verify tool efficacy. Provenance chain integrity does not verify authorization correctness. Both are continuity signals that organizations treat as correctness signals. P-011 and P-016 identify the same structural failure mode in adjacent domains.",
  "governance_condition": "The position rests on a property of cryptographic verification systems that is architectural, not implementation-specific. Provenance systems are designed to answer: \"Is this the artifact that was produced by this process from this source?\" They are not designed to answer: \"Was the process that produced this artifact controlled by the entity who was supposed to control it?\"\n\nThe first question is answerable cryptographically. The second is not, because the answer depends on the runtime state of the publishing environment: the actual integrity of the CI/CD workflow, the actual security state of the developer account, and the actual absence of malicious modification in the build toolchain. These are environmental properties that exist upstream of the artifact boundary at which provenance verification operates.\n\nThis is not a failure of cryptographic implementation. It is a structural property of where verification primitives operate relative to where authority is exercised. Provenance systems verify artifacts after they are produced. They cannot verify the integrity of the production environment that generated them.\n\nA-018 (Cryptographic validity implies trustworthy provenance and safe execution context) is directly under pressure on issuance. Six mechanism-independent demonstrations establish that cryptographic validity confirms continuity of authorization, not correctness of authorization. Cryptographic validity of a package signature, OIDC token, or provenance attestation confirms that the artifact was produced by a process that had valid credentials. It does not confirm that those credentials were in the control of the authorized entity at the time of production.",
  "implications": [
    "Organizations that treat provenance chain integrity as evidence of supply chain security will produce passing verification results for supply chain operations where the production environment was compromised upstream of the verification boundary.",
    "The verification primitives that fail to detect this class of compromise are also the verification primitives organizations use to assess whether compromise has occurred, creating an asymmetric information condition where the adversary knows the provenance chain is compromised and the defender's verification infrastructure produces a passing result."
  ],
  "implications_text": "The structural consequence is that the supply chain security governance model built on provenance verification has a structural blind spot. Organizations that have deployed package signing, OIDC trusted publishing, SLSA attestation, and software bill of materials verification have improved their ability to detect direct artifact tampering. They have not improved their ability to detect compromise of the production environment upstream of the verification boundary.\n\nThe adversary operating model documented across the six mechanisms exploits this blind spot precisely: gain control of one authorized link, produce artifacts that will pass all verification, distribute through legitimate channels. The verification infrastructure confirms the attack succeeded. It cannot detect that the production environment was compromised.\n\nThe position's force reduces in environments where runtime integrity of the production environment is independently verified at execution time: hardware-rooted attestation of the build environment, continuous integrity monitoring of CI/CD workflow definitions, independent verification of publisher identity at every step in the publication chain. These controls shift the verification boundary upstream. They are not widely deployed at ecosystem scale.",
  "exclusions": [
    "Prescriptive pipeline hardening or dependency pinning recommendations",
    "Vendor-specific registry verification system evaluation",
    "SLSA level adequacy assessments for specific threat models",
    "Regulatory compliance requirements for software supply chain governance"
  ],
  "supersedes": null,
  "amendments": "AMD-001; AMD-2026-09-22-POSITION-RECORD-CORRECTIVE-WAVE; CHQ-PRS-2026-001-AMD-002; CHQ-RAT-2026-001-CANONICAL-TEXT-EXECUTION-WAVE; CHQ-PRS-2026-001-AMD-003",
  "amendment_note": "AMENDMENT AMD-001 · JULY 24, 2026 · REINFORCEMENT\nWindow reinforcement recorded. Every backdoored package version in the July 2026 npm campaign shipped through cryptographically intact official channels with valid publishing identities. All provenance checks passed while authorization was wrong at the publishing-identity layer; the malicious code executed at import time, past install-focused scanning. Canonical evidence basis and counts are unchanged; the reinforcement is recorded at the evidence layer.\n\nAMENDMENT AMD-2026-09-22-POSITION-RECORD-CORRECTIVE-WAVE · SEPTEMBER 22, 2026 · POSITION RECORD STANDARD CORRECTION. Canonical field semantics, evidence counts, identifiers, independence wording, and publication integrity corrected in one dated wave.\n\nAMENDMENT CHQ-PRS-2026-001-AMD-002 · SEPTEMBER 22, 2026 · DOCKET SUCCESSION CORRECTION. No new evidence docket was issued. CHQ-ED-2026-020 remains the unchanged primary evidence record; CHQ-ED-2026-021 remains locked as the July supplementary record.\n\nAMENDMENT CHQ-RAT-2026-001-CANONICAL-TEXT-EXECUTION-WAVE · SEPTEMBER 22, 2026 · CANONICAL TEXT EXECUTION. Scheduled prose constructions rewritten for grammatical clarity without changing the underlying judgment.\n\nAMENDMENT CHQ-PRS-2026-001-AMD-003 · SEPTEMBER 22, 2026 · GOVERNING CONSTRAINT APPLICABILITY. Governing Constraint was audited under the ratified PRS-06.5 material-applicability test. Default citations were removed, materially load-bearing constraints were retained or added, the prior version and hash were preserved, and the canonical hash was recomputed.",
  "reference_conditions": [
    "Authored independently of any subscribing organization",
    "Not tailored to a specific contractual, commercial, or advocacy interest",
    "Subsequent analysis based only on new evidence"
  ],
  "evidential_record": {
    "title": "CybersecurityHQ Cryptographic Provenance Continuity-Not-Correctness Evidence",
    "docket": "CHQ-ED-2026-020",
    "exhibits": [
      "CHQ-EX-2026-009",
      "CHQ-EX-2026-015",
      "CHQ-EX-2026-016",
      "CHQ-EX-2026-017",
      "CHQ-EX-2026-018"
    ],
    "signals": [
      "SN-2026-03-19-01",
      "SN-2026-03-20-01",
      "SN-2026-03-31-01",
      "SN-2026-04-30-01",
      "SN-2026-05-01-01",
      "SN-2026-05-01-02"
    ]
  },
  "related_positions": [
    "CHQ-P-2026-015",
    "CHQ-P-2026-013",
    "CHQ-P-2026-011"
  ],
  "pdf_hash": "381840d8d9d2ec4ed1c6014d872910850a2b44f8d745d4b6edb71dda1c15f297",
  "prior_hashes": [
    {
      "version": "v1.1",
      "sha256": "01609e426df39ebf7a1669ff4d5141c251e39fbdf19281531d57c91650a9c5e8"
    },
    {
      "version": "v1.2",
      "sha256": "6b1f27fc88359c50418d89de4987d6c31e2e1dc0b095916a13057b8ef01fa7fd"
    },
    {
      "version": "v1.4",
      "sha256": "1cf329a3e13af6375c2dc476a9b9658b79e1a0f2ba8dce56ef72abe7b6cf97b2"
    }
  ],
  "authority_derivation_text": "No constraint derivation applies. This is a standalone Position.",
  "canonical_hash": "381840d8d9d2ec4ed1c6014d872910850a2b44f8d745d4b6edb71dda1c15f297"
}
```