DOI

DOI: Failures are public artifacts, not drawer contents. Truth has one address per item; copies are bugs. U_lat=hc_ref/a CALIB 13.1 Lattice unit energy SSOT combining three anchors (h,c_ref,a). This chapter defines operational rules that ensure every artifact produced throughout the main text is fixed in a form that is verifiable, reproducible, and distributable.

Failures are public artifacts, not drawer contents. Truth has one address per item; copies are bugs. U_lat=hc_ref/a CALIB 13.1 Lattice unit energy SSOT combining three anchors (h,c_ref,a).

16.1 Protocol registry, pre-registration, and falsification-trigger rules (FAIL is also public)

16.1.1 Purpose and scope (definition)

This chapter defines operational rules that ensure every artifact produced throughout the main text is fixed in a form that is verifiable, reproducible, and distributable. Here:

Verification means “the eligibility of artifacts is decided by the predefined Gate/PASS.rules.”
Reproducibility means “the same artifacts are regenerated from the same inputs (LOCK), the same protocol, and the same reference implementation.”
Distribution means “the artifact bundle is recorded as an immutable DOI-scoped archive, and integrity is guaranteed by checksums.”

This chapter does not add new derivations (theory). It only covers artifact qualification (verdict), recording (logs), and preservation (archives).

16.1.2 Core objects (definition): protocol, registry, registration identifiers

(Definition) Protocol

A protocol P is defined as a 7-tuple:

\begin{equation} \mathsf{P}:=\big(\mathsf{S},\mathsf{I},\mathsf{R},\mathsf{E},\mathsf{G},\mathsf{O},\mathsf{A}\big) \end{equation}

Each component is fixed as follows.

S: scope (regime) declaration (target model/target data/admissibility conditions).
I: input (LOCK) references (identifiers and digests for canonical/realization/analysis locks).
R: procedure (ordered phases) definition (preprocess, execute, aggregate, verdict order).
E: estimator definition (formula/algorithm, sampling rules, seed rules).
G: Gate/PASS.rules definition (thresholds, verdict sign, failure codes).
O: artifacts definition (file list, formats, required metadata).
A: falsification triggers and the FAIL disclosure policy.

(Definition) Protocol registry

A protocol registry R_prot is an immutable list that stores protocols and their metadata. Each registry entry is

\begin{equation} \mathcal{R}_{\mathrm{prot}}[i]=\big(\mathrm{PID},\mathrm{VER},\mathrm{DIG},\mathrm{TS},\mathrm{STATUS}\big) \end{equation}

with the following fixed meanings.

PID: protocol identifier (string; globally unique).
VER: protocol version (integer or vX.Y.Z).
DIG: checksum digest of the protocol file (e.g., SHA-256).
TS: registration timestamp (UTC or fixed timestamp).
STATUS∈ACTIVE,DEPRECATED,REVOKED: status.

The registry is append-only; modification/deletion of existing entries is forbidden. If a correction is needed, a new versioned entry must be added.

16.1.3 Pre-registration rules (definition)

(Definition) Pre-registration file

Pre-registration is the act of recording all components of P into a fixed-schema file. We define the pre-registration file as

\begin{equation} \texttt{protocol.yaml} \quad \text{or}\quad \texttt{protocol.json} \end{equation}

The pre-registration file must include the following fields.

pid, version, scope (=S)
locks (=I; paths and digests for each LOCK file)
procedure (=R; phase names, inputs/outputs, order)
estimators (=E; formulas/algorithms/seed rules)
gates (=G; PASS.rules, thresholds, failure codes)
artifacts (=O; required file list, formats, path rules)
falsification (=A; trigger list, FAIL disclosure policy)

(Definition) Pre-registration digest and fixed point

Define the checksum digest of the pre-registration file as

\begin{equation} \mathrm{DIG}_{\mathrm{prot}}:=\mathrm{SHA256}(\texttt{protocol.*}) \end{equation}

The protocol is frozen by DIG_prot. If DIG_prot changes under the same PID, then VER must increase. The pre-registration digest is a prerequisite for every run and must be included in the run logs and the DOI archive.

16.1.4 PASS.rules and verdict hierarchy (definition)

(Definition) Gate and PASS.rules

A Gate is defined as a boolean function that decides artifact eligibility. Each Gate g takes a summary vector m and a threshold set Θ, and returns

\begin{equation} g(\mathbf{m};\Theta)\in\{0,1\} \end{equation}

Let the set of Gates be G=g₁,…,g_K. PASS.rules is defined as a logical composition of Gates. For example, one may fix

\begin{equation} \mathrm{PASS}:=\bigwedge_{k=1}^{K} g_k(\mathbf{m}_k;\Theta_k) \end{equation}

PASS.rules must be stated in the pre-registration file, and post-run changes are forbidden.

(Definition) Verdict classes

Each run is assigned exactly one verdict class:

\begin{equation} \mathrm{STATUS}\in\{\mathrm{PASS},\mathrm{FAIL},\mathrm{INCONCLUSIVE}\} \end{equation}

PASS: all Gates pass, and logs/checksums/artifacts are complete.
FAIL: at least one falsification trigger fires, or at least one Gate explicitly fails.
INCONCLUSIVE: the run completes, but the verdict cannot be made because log/artifact/integrity requirements are not satisfied.

16.1.5 Falsification triggers (definition) and FAIL disclosure (rule)

(Definition) Trigger set

Define the falsification-trigger set as T=T₁,…,T_L. Each trigger T_ℓ takes as input summary metrics and integrity metadata, and returns

\begin{equation} T_\ell(\mathbf{m},\mathbf{u})\in\{0,1\} \end{equation}

where m is a numeric summary (metrics) and u is an integrity summary (checksums, schema conformance, log completeness, etc.).

(Definition) Minimal triggers (required)

The pre-registration must include at least the following triggers.

(T-LOCK) LOCK mismatch: fires when any LOCK digest referenced by the run differs from the pre-registered LOCK digest.
$\begin{equation} T_{\mathrm{LOCK}}=1 \Longleftrightarrow \exists\,\ell\ \text{s.t.}\ \mathrm{DIG}^{\mathrm{run}}_{\ell}\neq \mathrm{DIG}^{\mathrm{prot}}_{\ell} \end{equation}$
(T-MAN) Integrity failure: fires when any artifact checksum differs from the manifest.
$\begin{equation} T_{\mathrm{MAN}}=1 \Longleftrightarrow \exists\,f\ \text{s.t.}\ \mathrm{SHA256}^{\mathrm{run}}(f)\neq \mathrm{SHA256}^{\mathrm{manifest}}(f) \end{equation}$
(T-SCH) Schema failure: fires when log/registry/snapshot files violate their defined schemas.
$\begin{equation} T_{\mathrm{SCH}}=1 \Longleftrightarrow \texttt{schema\_validate}=0 \end{equation}$
(T-GATE) Gate failure: fires when any pre-registered Gate fails.
$\begin{equation} T_{\mathrm{GATE}}=1 \Longleftrightarrow \exists\,k\ \text{s.t.}\ g_k(\mathbf{m}_k;\Theta_k)=0 \end{equation}$
(T-NT) No-Tuning violation: fires when evidence of post-hoc changes (definitions/thresholds/estimators/data selection) is detected as a violation of registry immutability.
$\begin{equation} T_{\mathrm{NT}}=1 \Longleftrightarrow \texttt{registry\_immutability}=0 \end{equation}$

(Rule) Minimal FAIL disclosure unit

FAIL must not be concealed, deleted, or partially disclosed. FAIL disclosure must satisfy the following minimum unit.

\begin{equation} \mathsf{FAILPACK}:=\{\texttt{protocol.*},\ \texttt{locks/*},\ \texttt{run\_log.jsonl},\ \texttt{manifest.*},\ \texttt{registry\_snapshot.json},\ \texttt{outputs/*}\} \end{equation}

FAILPACK is subject to the same integrity rules as PASS artifacts (including checksums). FAILPACK must be included in the DOI archive, and the very existence of FAIL must be discoverable from the registry.

16.1.6 Falsification tree structure (definition): cause classes and code system

(Definition) Cause classes

Fix the set of cause classes as

\begin{equation} \mathcal{C}_{\mathrm{fail}}=\{\mathrm{LOCK},\mathrm{INTEGRITY},\mathrm{SCHEMA},\mathrm{GATE},\mathrm{PROCEDURE}\} \end{equation}

Each FAIL run must have at least one cause class.

(Definition) Failure codes

Failure codes are fixed to the form F--. Examples:

F-LOCK-001: LOCK digest mismatch.
F-INTEGRITY-002: artifact checksum mismatch.
F-SCHEMA-003: log/schema violation.
F-GATE-010: a specific Gate failed (include Gate identifier).
F-PROCEDURE-020: pre-registered procedure violation (missing phase / reordered phases).

Failure codes must be recorded in both the log and the registry, and must be included in the DOI archive.

16.2 SSOT

16.2.1 SSOT (single source of truth) principle (definition)

The SSOT principle means: “inputs/constants/rules with the same meaning do not exist scattered across duplicated files.” SSOT is fixed in the following three layers.

Input SSOT: all constants/definitions/thresholds are declared only in LOCK files.
Procedure SSOT: all execution phases and Gates are declared only in protocol.*.
Artifact SSOT: existence/path/format/checksum of every artifact is declared only in manifest.*.

SSOT violations are treated as failures via triggers (T-NT) or (T-SCH).

16.2.2 Run identification and directory conventions (definition)

(Definition) run_id

Each run has a globally unique identifier run_id. Define run_id as a string generated by

\begin{equation} \texttt{run\_id}:=\texttt{YYYYMMDDThhmmssZ}\ \Vert\ \texttt{pid}\ \Vert\ \texttt{short\_digest} \end{equation}

Here Vert denotes string concatenation. Define short_digest as a fixed-length prefix such as the first 12 characters of (S16_01_dig_prot).

(Definition) Run directory

The run directory tree is fixed as follows.

runs/
  <run_id>/
    protocol.locked.json
    locks_snapshot/
      canon_lock.json
      realization_lock.json
      analysis_lock.json
    registry_snapshot.json
    run_log.jsonl
    metrics.json
    outputs/
      ...
    manifest.json
    manifest.sha256

protocol.locked.json is a normalized JSON copy of protocol.*; its digest must match (S16_01_dig_prot).

16.2.3 Log specification (run_log.jsonl) and schema (definition)

(Definition) JSON Lines log

The run log is fixed to the JSON Lines format. That is, run_log.jsonl is a sequence in which each line is an independent JSON object. Each log entry L_i must satisfy the schema

\begin{equation} L_i= \{\texttt{ts},\texttt{run\_id},\texttt{pid},\texttt{ver},\texttt{phase},\texttt{event},\texttt{payload}\} \end{equation}

The meaning and type of each field are fixed as follows.

ts: string (UTC timestamp; e.g., 2025-12-12T12:34:56Z)
run_id: string ((S16_02_runid))
pid: string (pid in protocol.*)
ver: string or number (version)
phase: string (phase name; one of the items defined in procedure)
event: string (event name; predefined set such as START, END, METRIC, GATE, ERROR, etc.)
payload: object (additional information such as metrics/warnings/errors/file paths/checksums)

(Definition) Required log events

Each run must include the following events.

START: run start (including input digests).
LOCKS_CHECK: verification result of LOCK digests.
PHASE_START/PHASE_END: start/end of each procedure phase.
METRIC: output of all pre-registered metrics (value, unit, computation version).
GATE: verdict (0/1) for each Gate and reference to the supporting metrics.
MANIFEST_WRITE: manifest creation completion and checksum.
STATUS: final verdict ((S16_01_status)) and failure codes (if any).

Missing a required event is treated as a failure via (S16_01_TSCH).

16.2.4 Metric file (metrics.json) specification (definition)

Metrics are recorded as METRIC events in the log, but they are also summarized as a single object in metrics.json at the end of the run.

\begin{equation} \texttt{metrics.json}= \{\texttt{run\_id},\texttt{pid},\texttt{ver},\texttt{metrics},\texttt{units},\texttt{provenance}\} \end{equation}

where

metrics: key–value map (metric name → scalar/vector/matrix; JSON-representable)
units: key–value map (metric name → unit string)
provenance: input digests, code version, and environment summary (must include the same keys as registry_snapshot below)

are fixed.

16.2.5 Manifest specification (definition) and checksum files

(Definition) manifest.json

A manifest is an SSOT file that contains a complete list of artifacts and their checksums. Fix the schema of manifest.json as

\begin{equation} \texttt{manifest.json}= \{\texttt{run\_id},\texttt{pid},\texttt{ver},\texttt{files},\texttt{hash\_alg}\} \end{equation}

Fix hash_alg to the string "sha256". files is a list whose each entry must satisfy

\begin{equation} f= \{\texttt{path},\texttt{bytes},\texttt{sha256}\} \end{equation}

(Definition) manifest.sha256

Fix manifest.sha256 as a one-line (or multi-line) text in the following format.

<sha256_of_manifest.json>  manifest.json

The checksum of manifest.json itself must also be included in the registry snapshot.

16.2.6 registry_snapshot specification (definition)

(Definition) registry_snapshot.json

registry_snapshot.json stores, in a single snapshot file, all fixed points required to reproduce a run. Fix its schema as

\begin{equation} \texttt{registry\_snapshot.json}= \{\texttt{run\_id},\texttt{protocol},\texttt{locks},\texttt{environment},\texttt{code},\texttt{randomness},\texttt{manifests}\} \end{equation}

Each field must include the following.

protocol: pid, version, digest (=DIG_prot), file_path
locks: for each LOCK file, path, sha256, and the digest of a raw JSON copy
environment: OS/architecture/language runtime versions/dependency list (sorted list)
code: source-tree digest (e.g., directory hash), commit id (if any), build flags (if any)
randomness: all random seeds, sampling rules, and digests of seed-derivation functions
manifests: digests of manifest.json and manifest.sha256

16.2.7 Randomness/seed convention (definition) and minimal reproducibility condition

(Definition) Seed system

Every stochastic element of a run must be frozen by explicit seeds. Fix a base seed seed₀∈N and per-phase seed derivation as

\begin{equation} \mathrm{seed}_{p}:=\mathrm{H}(\mathrm{seed}_0,\texttt{pid},\texttt{phase\_name},\texttt{run\_id}) \end{equation}

where H is a pre-registered hash-based function. The digest of H must be included in registry_snapshot.json. Per-phase seeds must be recorded in the log and snapshot; missing records are treated as failures via (S16_01_TSCH).

(Definition) Minimal reproducibility condition

Define reproducibility as the following simultaneous condition.

\begin{equation} \mathrm{REPRODUCIBLE}=1 \Longleftrightarrow \big(T_{\mathrm{LOCK}}=0\big)\wedge\big(T_{\mathrm{MAN}}=0\big)\wedge\big(T_{\mathrm{SCH}}=0\big) \end{equation}

That is, if any of LOCK mismatch, integrity failure, or schema failure occurs, reproducibility does not hold.

16.3 Reference implementation execution recipe, artifact checklist, and release rules

16.3.1 Definition of the reference implementation (definition)

(Definition) Reference implementation

Define the reference implementation I_ref as the execution code set that satisfies the following conditions.

(RI-1) Inputs are read only from protocol.*, locks/*, and the run plan (plan.*).
(RI-2) Gate/PASS.rules and the artifact list are used exactly as declared in protocol.*.
(RI-3) All run outputs are written only under runs//.
(RI-4) On run completion, run_log.jsonl, metrics.json, manifest.json, and registry_snapshot.json must be generated.
(RI-5) Under the same snapshot (LOCK/environment/seeds), artifact checksums must be identical.

Violation of (RI-1) is treated as a No-Tuning violation and is failed via the trigger (S16_01_TNT).

16.3.2 Execution recipe (definition): inputs/outputs/phases

(Definition) Run plan (plan) file

Define the run plan plan.json as the file that enumerates the experiment set allowed by the protocol. Each run item must satisfy

\begin{equation} \texttt{job}= \{\texttt{job\_id},\texttt{pid},\texttt{protocol\_digest},\texttt{locks},\texttt{params},\texttt{seeds},\texttt{targets}\} \end{equation}

params may contain only parameters allowed by the pre-registration. If any key outside the allowed list is present, the run is immediately failed as F-PROCEDURE-020.

(Definition) Execution entry points

Fix the reference implementation to provide the following entry points.

ref_impl/
  run_one.py
  run_plan.py
  validate.py

Fix the responsibilities of each entry point as follows.

run_one.py: execute a single job, create the run directory, generate logs/metrics/artifacts.
run_plan.py: execute every job in plan.json in enumeration order, generate a global summary log.
validate.py: schema validation, checksum validation, recompute PASS/FAIL verdicts, generate a result summary.

(Definition) Command forms

Fix the command forms as

python ref_impl/run_plan.py --protocol protocol.yaml --plan plan.json --out runs/
python ref_impl/validate.py --runs runs/ --protocol protocol.yaml

These commands define the interface; the execution environment/dependencies/versions are frozen by registry_snapshot.json.

16.3.3 Artifact checklist (definition): required files and formats

(Definition) Minimum release artifact set

A release (distribution unit) must include at least the following files/directories.

README.md
LICENSE
CITATION.cff
CHANGELOG.md
protocol/
  protocol.yaml
  protocol.sha256
locks/
  canon_lock.json
  realization_lock.json
  analysis_lock.json
  locks.sha256
plans/
  plan.json
  plan.sha256
runs/
  <run_id>/
    protocol.locked.json
    locks_snapshot/
    registry_snapshot.json
    run_log.jsonl
    metrics.json
    outputs/
    manifest.json
    manifest.sha256
release_manifest.json
release_manifest.sha256

Here release_manifest.json is the top-level manifest that contains checksums of the entire release. Its schema is fixed to be identical to (S16_02_manifest_schema).

(Definition) Required metadata contents

The minimal contents of each metadata file must include the following.

README.md: release identification (version, date), included protocol/LOCK, run list (run_ids), artifact overview (filenames only).
CITATION.cff: author/title/version/DOI (after distribution), and a short release-digest summary.
CHANGELOG.md: per-version change summary (which LOCK/protocol/code changed).
LICENSE: distribution terms.

Missing metadata is treated as a failure via (S16_01_TSCH).

16.3.4 Release rules (definition): versioning, immutability, DOI unit

(Definition) Version notation and bump rules

Fix the release version string as vX.Y.Z.

X (Major): increase when there is a semantic change in LOCK definitions or a semantic change in Gate/PASS.rules.
Y (Minor): increase when adding a reference implementation/procedure, adding an artifact structure, or extending a schema while preserving backward compatibility.
Z (Patch): increase for changes that do not affect results/schemas/verdicts (typos, notation polishing, comment edits, etc.).

In particular, if any key–value in any LOCK file (canonical/realization/analysis) changes, Major must increase. This forbids “post-hoc modification of conclusions under the same name.”

(Definition) Immutability rule

A DOI-assigned release is immutable: after DOI assignment, modification/deletion/replacement of files is forbidden. If a change is needed, create a new versioned release and obtain a new DOI unit. Immutability is enforced by checksums as

\begin{equation} \mathrm{IMMUTABLE}=1 \Longleftrightarrow \mathrm{SHA256}(\texttt{release\_manifest.json})=\texttt{release\_manifest.sha256's value} \end{equation}

(Definition) DOI package (archive unit)

Fix the DOI package (compressed or archived) as the single bundle that contains

\begin{equation} \mathsf{DOIPACK}:=\{\texttt{protocol/},\texttt{locks/},\texttt{plans/},\texttt{runs/},\texttt{release\_manifest.*},\texttt{README.md},\texttt{CITATION.cff},\texttt{CHANGELOG.md},\texttt{LICENSE}\} \end{equation}

release_manifest.* is mandatory as the integrity evidence for all files; if missing, the DOI package is invalid.

16.3.5 Release verdict Gate (definition): distribution eligibility

A release is not a single run; it is defined as the distribution-eligibility verdict for the entire runs/ set. Fix the release PASS condition as

\begin{equation} \mathrm{PASS}_{\mathrm{release}} := \left(\bigwedge_{\texttt{run\_id}\in\texttt{runs/}} \mathrm{STATUS}(\texttt{run\_id})\neq \mathrm{INCONCLUSIVE}\right) \wedge \left(T_{\mathrm{MAN}}^{\mathrm{release}}=0\right) \wedge \left(T_{\mathrm{SCH}}^{\mathrm{release}}=0\right) \end{equation}

Here T_MAN^release is the integrity trigger for release_manifest.*, and T_SCH^release is the release-schema trigger. It is allowed that a release contains FAIL runs; in that case the FAILPACK rule (S16_01_failpack) must be satisfied. However, for a release to be judged PASS, there must be no INCONCLUSIVE runs.

16.3.6 Minimal disclosure principle (definition): equal disclosure of PASS and FAIL

PASS and FAIL are subject to the same disclosure rules.

Every run must include run_log.jsonl and registry_snapshot.json.
Every run must include manifest.json and checksums.
Every run must include protocol and LOCK snapshots.

This forbids “keeping only successful results and deleting failures.” Failures are treated as part of the same verification/reproducibility system.

16.3.7 Post-distribution tracking (definition): DOI–version mapping and reference freeze

After distribution, once a DOI is assigned, references are frozen via CITATION.cff and a dedicated mapping file. Define the mapping file as a CSV with columns

\begin{equation} \texttt{DOI\_MAP.csv}:\ (\texttt{version},\texttt{doi},\texttt{release\_digest},\texttt{date}) \end{equation}

Fix release_digest as the SHA-256 of release_manifest.json. Missing DOI–version mapping is treated as an incompleteness of the distribution system. After that point, every citation/reference is fixed to include both the DOI and release_digest.

16.4 Physical-constant closure map: separation of GEOM/ANCHOR/CALIB

This section classifies the major physical constants/scales used in the main text into (i) items that close purely from geometric/integer structure (GEOM), (ii) items that must be locked as anchors of the realized unit system (definitions or standard values; ANCHOR), and (iii) items whose numerical values are determined by combining ANCHOR with GEOM while keeping the geometric structure (CALIB). The purpose is to enable an internal self-audit of “what is derived and what is locked.” This section adds no new physical assumptions; it only provides a dependency status table (SSOT) for existing sections.

16.4.1 Classification rules (definition)

GEOM: closes using only integer/geometric definitions internal to the document, with no dependence on external numerical values or definitions.
ANCHOR: must be locked as a unit-system or standard anchor (definition/recommended value); this document does not treat it as a derivation target (but the fact of locking is never hidden).
CALIB: an SI value (or reported-unit value) is determined by combining ANCHOR with the GEOM structure.

16.4.2 SSOT

Item	Status	Primary source	Definition/derivation summary
Item	Status	Primary source	Definition/derivation summary
N_sec=3	`GEOM`	7.0	Topologically forced as the minimum number of vectors (3) required to physically enclose the core in a 2D cross-section.
N_shell=7	`GEOM`	8.2	Closes by minimality of 3D cancellation (2-pair + 4-quad) plus label survival (1), and by the residual match 89-82.
αₑₘ	`OPEN`	14.5	Not derived. Open input taken from measurement. The closed form 4π(11-δ_proj) is recorded only as a numerical coincidence (non-evidence): the assembly is not forced, the 4π is an SI unit artifact, and αₑₘ runs with energy.
h_VP	`CALIB`	15.5	Define the rigidity-shell barrier ε_b(ν)=h_VPν and derive a Planck-like spectral form from the thermal equilibrium sum over event counts n∈N. The SI value of h_VP is identified by matching to blackbody data (protocol/Gate required).
Blackbody spectral form	`GEOM`	15.5	Shape closes as mode count ν² (pure 3D geometry) × rigidity filter frach_VPνe^h_VPν/(k_B T)-1 (discrete event counts).
a (VP diameter; realization length)	`ANCHOR`	11.2	Length anchor of the realization unit system. Post-hoc tuning is forbidden within the same version (LOCK).
Δ t (realization time tick)	`ANCHOR`	11.3	Time anchor of the realization unit system. Post-hoc tuning is forbidden within the same version (LOCK).
c_ref	`ANCHOR`	11.1, 13.1	Reference speed anchor (unit system/protocol). This document does not derive it; it is used only as a LOCK.
h	`ANCHOR`	13.1	Action-unit anchor. The SI-defined value is locked in `canon_lock`.
U_lat=hc_ref/a	`CALIB`	13.1	Lattice unit energy SSOT combining three anchors (h,c_ref,a).
Mass scales such as mₚ,mₑ,m_H	`CALIB`	13	Under the axiom U_lat/σ_eff, derived from structural resistance (geometric cross-sections/event rates). Comparisons are Gate metrics.

16.4.3 Gate: “missing lock” detection rules (definition)

The status table in this section is not a conclusion but an audit rule. If any of the following violations is detected, the corresponding claim is immediately set to FAIL.

(G-LOCK-MISS) An ANCHOR item is used but its value/unit/source is not sealed in a lock file.
(G-ANCHOR-HIDE) An ANCHOR is described as if it were GEOM (as if it were derived), or evidence of post-hoc adjustment is found.
(G-CALIB-NOPROTO) A CALIB item is used but the matching protocol/error bars/verdict function (e.g., χ) is not pre-registered.

16.5 DOI completeness maintenance rules: automated audits for “zero missing”

This document distinguishes two kinds of citations.

Internal citations ([cite: XX]): tokens that refer to reports/simulations/protocols inside this DOI bundle.
External citations (journals/standards): external literature with DOI (e.g., Planck's original paper, CODATA, etc.).

The goal is zero missing DOI for internal citations and zero missing DOI annotation for external citations.

16.5.1 Internal citation registry (definition): SSOT = CITE_REGISTRY.csv

Every internal citation token must be registered in the following SSOT.

SSOT: 04_vp_whitepaper/docs/citations/CITE_REGISTRY.csv
Per-ID notes: 04_vp_whitepaper/docs/citations/CITE-#.md

If a token appears in the main text but is missing from the SSOT, it is a FAIL under (G-DOI-MISS).

16.5.2 External DOI notation rules (definition)

For any external journal/academic source that has a DOI, the DOI must be explicitly stated.
For sources without DOI (web pages, software, etc.), record the URL and access date.
If only arXiv exists, state the arXiv identifier; when a DOI is later assigned, add it in a version bump.

16.5.3 Automated audit script (LOCK): scripts/doiₐudit.py

Before release (or before Zenodo upload), the following script must succeed (exit code 0).

\begin{equation} \texttt{python3 scripts/doi\_audit.py} \end{equation}

This script checks: (i) whether internal citation tokens in the main text match IDs in CITE_REGISTRY.csv, (ii) whether DOI/URL fields in CITE_REGISTRY.csv are blank, and (iii) whether external DOI strings in the main text have valid formats (regex) and duplicates. Uploading/distribution is forbidden in a failing state.