1.1 Purpose and claim boundary

This whitepaper is written to support a precise, testable, and reproducible claim:

This claim is deliberately not a claim about fully solving biological function. Rather, it asserts that the interpretation output objects are always produced (or a failure is explicitly labeled), and that the entire process is auditable and reproducible under a LOCK\(\rightarrow\)Derive\(\rightarrow\)Gate regime .

1.2 Scope: what is included and what is not

1.3 Document conventions and terminology

1.4 Reproducibility contract (LOCK–Derive–Gate)

We adopt a strict reproducibility contract with three layers :

LOCK

Versioned priors, schemas, and algorithms (e.g., the 4-activity grammar; A5 priors; KEY and PCTS versions).

Derive

All output files are derived from LOCK + inputs without hidden manual steps.

Gate

Every run produces fail-fast gates that check admissibility (e.g., \(\Delta E<0\) for JEVENT) and audit completeness.

A run is considered validated when:

1. inputs are recorded with sha256 hashes (DATA_LOCK),

2. outputs are recorded with sha256 hashes (MANIFEST),

3. gates return PASS (or explicit FAIL/INCONCLUSIVE with reasons),

4. the DOI registry has no missing DOI entries.

1.5 How to cite

Zenodo DOI (this whitepaper + reproducibility bundle):

External resources are cited via DOI-bearing references (see bibliography). Internal derived artifacts are cited by run_id and sha256 hashes recorded in DATA_LOCK and MANIFEST. When distributing results, include the validated bundle and its registry/audit scripts to allow third-party verification .

1.6 Evidence lock (fixed artifacts for this whitepaper)

Zenodo upload (recommended): upload this whitepaper PDF together with the wrapper bundle , which contains the locked evidence bundles listed below.

To make the evidence supporting Table 3 and Fig. [fig:archetype_grid] immutable and auditable, we freeze the exact evidence bundles and key files by sha256 below. Any change to these hashes (inputs, selection, or generated summaries) requires a new evidence version and a new whitepaper revision.

EVIDENCE_LOCK_v0_1

(1) mm39 archetype coverage bundle (Table 1 + Fig 1 sources)
  mm39_archetype_coverage_TABLE1_FIG1_bundle_v0_1.zip
    sha256: d9adeb446efe6ae2e1e21ef0202ea0ed92d042f5bcaaae573f67a879f15270a8
  key files inside the bundle:
    TABLE1_mm39_archetype_coverage_v0_1.csv
      sha256: c61ec72d129a899f9787e5cead3047e54004d223c3ae9bd02186c5ecc4239d77
    mm39_selected_regions_archetypeN80_v0_1.csv
      sha256: 9519b2a13164194b50043135ce021d7054c93b90c249caa7462b2ecca2c021a3
    mm39_archetype_coverage_matrix9x9_v0_1.csv
      sha256: 4881c61704f018d866e786036c383c708d20c224fd8b2a185d7c1540ff202abf
    RUN_METADATA_mm39_archetype_coverage_v0_1.json
      sha256: 309c920feb61c277ee62e67c47ec0744328a873a950f30b5950754f14ead01f7
    MANIFEST_mm39_archetype_coverage_v0_1.json
      sha256: fe7adc4fb201d31cb243c6f1e765c2248d230e59eaf1989a66be2a7475cf7f99
    mm39_inputs_sha256_v0_1.txt
      sha256: f8ea0caa5a009da6df7b3a77585f528999f56efedced5be6b48835db5b42dce5

(2) End-to-end autoscan+STEP18 bundlekit (scripts and LOCK files)
  mouse_mm39_autoscan_END2END_bundlekit_v1_0.zip
    sha256: e2e2803daa972e276b9710db39f450055ad9fdfd44e0cfab974c3a592b826ac2
  key files inside the bundlekit:
    MANIFEST.json
      sha256: 024bf5ed17fb984fa17ca9bef586c0b72883488352ba3d142422457126604e50
    CITATION_REGISTRY.yaml
      sha256: 69ca4f35e13be7c7a24bdf04d7244d1798d38ac35835a2d5d399b17a8abf8db7
    STANDARD/A5_priors_dna_v0_1.yaml
      sha256: 0fc1b857956b2aa5c277fb919ac56c935fc524707853e83210ab2637477f8f8d
    STANDARD/J_LEDGER_schema_dna_v0_1.yaml
      sha256: 1cc118ce979eecdb7b24bd93efbf2efc572941ab1057e6ae0f77f5a9f4a4b769

2.1 One-page pipeline overview

The LOCK–Derive–Gate DNA Interpreter DNA pipeline is designed to make interpretation reproducible and auditable:

1. Input: a genomic region sequence (FASTA) and optional transcript annotations (GTF) restricted to the region.

2. KEY step (sequence \(\rightarrow\) structure): compute windowed sequence statistics, form a stiffness proxy, segment into shells, and define anchors; extract motors from TSS and connect to nearby anchors to form loops. The result is a minimal A4 arrangement.

3. PCTS step (structure \(\rightarrow\) ledger): given A4, generate a time-indexed ledger of irreversible events (J_LEDGER) under a fixed 4-activity grammar.

4. Audit/validation: produce DATA_LOCK, MANIFEST, INDEX, and gate tables; validate that the run is admissible and reproducible.

2.2 Core claim restated as an engineering contract

This is the sense in which we use “DNA is 100% interpretable” in this whitepaper .

2.3 Key design decisions

2.4 Evidence at scale: mm39 autoscan and representative panels

To avoid relying on a small hand-picked region set, we run a whole-genome autoscan over mouse mm39. Each window is summarized by four structural observables:

• gene density (TSS per Mb),

• repeat proxy (softmask fraction),

• GC fraction,

• CpG density.

Each axis is discretized into L/M/H (terciles), producing a \(3^4=81\) archetype grid. We then select a representative panel (N\(\approx\)30–100) with the goal of maximizing archetype coverage and maintaining approximate uniformity across covered archetypes.

2.5 Reproducibility statement (minimal)

The evidence is packaged as validated bundles:

• each run has DATA_LOCK (input hashes and parameters),

• each bundle has MANIFEST (sha256 for outputs),

• gate tables and verdicts are included,

• DOI audit is included for citations.

A third party can reproduce the same run_id outputs by re-running the pipeline with identical inputs and parameters .

2.6 Reading guide

Sections 2–3 define the formal objects and the reproducibility contract. Sections 4–5 define the deterministic transforms (KEY and PCTS). Sections 6–8 provide mouse mm39 data provenance and autoscan panel results (Table 1 and Fig. 1). Sections 9–10 interpret the emergence of stiffness-shell structure and document failure modes.

3.1 Input region

3.2 A4 arrangement

3.3 Fixed activity grammar (4 operations)

3.4 J_LEDGER and gates

3.5 Operational meaning of “100% interpretable”

3.6 Why archetype panels matter

The “100% interpretable” claim is global (any region can be processed), but evidence must be compact. Representative archetype panels provide a finite, auditable set of regions that cover the combinations of structural axes that drive A4 diversity. The autoscan selection algorithm and its coverage (Table 1 and Fig. 1) are therefore treated as core evidence, not as an optional demonstration .

4.1 Design principles

1. No silent drift. Inputs and outputs are hashed (sha256) and recorded.

2. Stable identity. A run has a stable run_id derived from inputs and parameters.

3. Idempotence. Re-running the same run_id produces the same directory structure; an existing run with MANIFEST is skipped.

4. Fail-fast. Missing required fields or violated admissibility constraints must be detected early and recorded.

4.2 run_id: a stable identifier

4.3 DATA_LOCK: freezing inputs and parameters

4.4 MANIFEST: freezing all derived outputs

4.5 INDEX: append-only run summaries

4.6 Gate outcomes and validation logic

4.7 Invariants implied by the contract

The contract implies the following invariants (used as checklists for both authors and auditors):

1. Deterministic derivation: outputs are deterministic functions of inputs + parameters + seed.

2. Complete provenance: every run has a DATA_LOCK; every bundle has a MANIFEST.

3. Explicit versioning: KEY and PCTS versions are always recorded and cannot be inferred post-hoc.

4. Closed-world citations: the DOI registry has no missing DOI entries (audit passes).

4.8 Failure modes (and how they appear)

5.1 Windowed observables and stiffness proxy

Let the region sequence be \(S\) of length \(L\) (bp). Choose a window length \(W\) and step \(\Delta\) (bp). For each window \(S_{[i,i+W)}\), compute:

• GC fraction: \[\mathrm{GC}(S)=\frac{\#\{G,C\}}{\#\{A,C,G,T\}}.\]

• CpG density (over adjacent pairs): \[\mathrm{CpG}(S)=\frac{\#\{j: S_{j}S_{j+1}=\texttt{CG}\}}{\max(1,|S|-1)}.\]

• AT-tract density (proxy): count occurrences of AAAAAA or TTTTTT (overlapping) normalized by window length.

5.2 Robust normalization and smoothing

A short-radius moving average smoothing is applied to \(z_i\) to reduce single-window noise without introducing nonlocal dependencies.

5.3 Shell segmentation

5.4 Boundaries and anchor construction

5.5 Motor extraction from annotations

When annotations are provided, we extract motors as transcript start sites.

Only motors with \(0\le \mathrm{TSS}_{\mathrm{local}}\le L\) are retained.

5.6 Loop generation

5.7 KEY versions

5.8 Outputs

KEY emits:

• window feature TSVs,

• shell and boundary TSVs,

• anchor, motor, and loop TSVs,

• a minimal A4 YAML summarizing the arrangement.

5.9 Failure modes and diagnostic signals

6.1 State variables and outputs

6.2 Residual stress proxy

This proxy is intentionally simple: it is an auditable scalar that should not increase across irreversible JEVENT updates.

6.3 Four-activity progression

PCTS advances in discrete steps \(t=0,1,2,\dots\) with the following fixed grammar:

INIT

initialize locked set \(\emptyset\) and compute initial pres.

SCONSERV

conservative projection (placeholder in v0_2; preserves admissible state representation).

SDISSIP

dissipative relaxation of the pres proxy (deterministic given seed).

JEVENT

irreversible events that lock eligible loops and write J_LEDGER entries.

6.4 Event rule: loop stabilization

6.5 Admissibility gates (what must be true)

6.6 Reproducibility and what is compared

6.7 Pi_T proxy and interpretation

PCTS_v0_2 records a Pi_T proxy as a compact time-normalized summary. In v0_2, this proxy is intentionally simplified to track effective run length (T_end steps); future versions may incorporate additional LOCKed priors.

6.8 Failure modes and edge cases

6.9 Summary: why PCTS_v0_2 is sufficient for the whitepaper

For the whitepaper claim, PCTS_v0_2 provides:

• a fixed activity grammar,

• deterministic mapping from A4 to an irreversible event ledger,

• explicit gates to validate admissibility,

• audit artifacts to support third-party verification.

This is exactly the “interpreter” role described by the LOCK\(\rightarrow\)Derive\(\rightarrow\)Gate contract .

7.1 Assembly identity and coordinate system

7.2 Primary sources for genome sequence and annotations

7.3 Provenance verification: what we hash and why

7.4 Practical conventions used in this whitepaper

7.5 Failure modes (and how to detect them)

8.1 Windowing scheme and candidate set

Let the genome be represented as a set of chromosomes \(\{C_k\}\) with sequences. Fix a window length \(W\) and step \(\Delta\). For each chromosome, we generate windows \([i,i+W)\) for \(i=0,\Delta,2\Delta,\dots\) with truncation at chromosome end if desired. The autoscan produces a candidate set \(\mathcal{W}\) of windows.

8.2 Autoscan observables (the 4 structural axes)

For each candidate window, compute the following observables:

1. Gene density: number of TSS falling inside the window, normalized per Mb (from RefSeq/refGene) .

2. Repeat proxy: softmask fraction (fraction of lowercase A/C/G/T).

3. GC fraction: \(\mathrm{GC}=\frac{\#(G+C)}{\#(A+C+G+T)}\).

4. CpG density: count of CG dinucleotides per kb; classical CpG island context is discussed in .

8.3 Binning: L/M/H terciles per axis

8.4 Archetype definition (4-axis bins)

8.5 Selection algorithm (coverage-first, uniformity-second)

We select a representative panel of \(N\) windows with the following goals:

1. Coverage-first: select at least one window from each archetype in \(\mathcal{A}_{\mathrm{obs}}\) whenever \(N \ge |\mathcal{A}_{\mathrm{obs}}|\).

2. Uniformity-second: distribute remaining selections so that counts per covered archetype are as even as possible.

3. Spacing constraint: enforce a minimum separation \(d_{\min}\) between selected windows on the same chromosome.

4. Deterministic tie-breaking: if multiple candidates are equivalent, choose the one with lexicographically minimal (chromosome, start) after sorting, or via a seeded deterministic pseudo-random order recorded in parameters.

8.6 Region extraction and STEP18 job construction

Each selected window becomes a region package:

• region.fa: the exact subsequence extracted from the genome FASTA,

• region.gtf: transcripts restricted to the region (TSS used for motors),

• raw.zip: zip archive containing both files.

A job list (JSONL) is generated, where each job includes: species_id, region_id, raw_zip path, seed, KEY version, region_start_abs, and windowing parameters.

8.7 Failure modes (autoscan/selection/extraction)

9.1 Bin cutoffs and marginal balance (Table 1)

Table 3 records the tercile cutoffs \((q_1,q_2)\) for each axis and the marginal balance of the selected panel across L/M/H. This is a compact validation that the representative selection is not overly biased on any single axis.

9.2 Archetype coverage (how it is computed)

9.3 Uniformity metrics (optional but recommended)

Coverage alone does not guarantee uniform evidence. To summarize uniformity across covered archetypes, one may report:

• min/median/max counts per covered archetype,

• normalized entropy of the archetype count distribution,

• Gini coefficient of the archetype count distribution.

These metrics are deterministic functions of the selected panel and are suitable for inclusion in validated bundles.

9.4 Figure 1: TeX-native archetype occupancy grid

9.5 Validation statements and failure modes

10.1 From sequence statistics to shells and anchors: a deterministic coarse-graining

KEY converts 1D sequence into a 1D structural signal (stiffness proxy), then coarse-grains it into shells.

Shell boundaries produce anchors with strengths proportional to the discontinuity of shell means.

10.2 Motors and loops as constrained couplings

Motors are extracted from minimal annotation (TSS). Loops connect motors to nearby anchors by a fixed rule.

10.3 JEVENT as irreversible stabilization (ledger semantics)

A JEVENT is not “a continuous dynamics”; it is an irreversible ledger step. In PCTS_v0_2, JEVENTs lock eligible loops and must dissipate energy.

10.4 What “emergence” means here

In this whitepaper, “emergence” is not a metaphysical claim. It is a concrete statement:

This claim is validated operationally by:

• deterministic KEY outputs (shell/anchor maps),

• deterministic PCTS outputs (snapshots and ledger),

• gate validation (admissibility constraints),

• run_id stability and MANIFEST hashing.

10.5 Scale behavior and multiscale KEY

A common concern is whether evidence from short regions generalizes to larger scales. KEY_v0_4 addresses this by introducing a multiscale shelling (fine and coarse tiers) and merging anchors.

10.6 Why representative panels generalize

The global claim is: any region is interpretable. Evidence cannot show all regions, so we use archetype panels.

10.7 Limits of interpretation (truthfulness constraints)

11.1 Validation levels

11.2 Bundle-level validation

11.3 Gate taxonomy (recommended minimal set)

11.4 Interpreting FAIL vs INCONCLUSIVE

11.5 Failure modes by layer

11.6 Parameter sensitivity and what is allowed

11.7 Limits and non-goals (truthfulness constraints)

• The framework does not guarantee biological predictive accuracy; it guarantees interpretable outputs under a contract.

• The autoscan archetype evidence is a coverage argument, not a proof of biological completeness.

• The choice of proxies (GC/CpG/softmask/TSS density) is explicit and auditable; alternatives can be substituted only by explicit versioning.

12.1 Immediate manuscript-completion tasks

1. Freeze a final TeX asset management strategy (single central figure bundle; this project uses placeholders).

2. Expand Appendix B into a fully executable command list matching the released bundles.

3. Produce a “release candidate” validated bundle that corresponds exactly to Table 1 and the final managed figures.

12.2 Evidence expansion (within mouse mm39)

12.3 Cross-organism extension

1. Apply the same autoscan and panel strategy to additional vertebrates.

2. Maintain the same contract: LOCKed grammar, deterministic KEY to A4, deterministic PCTS to ledger, validated packaging.

3. Compare archetype distributions across organisms and quantify which archetypes exist or are absent under comparable windowing.

12.4 Toward organ/context panels (without changing activity grammar)

Organ/context specificity should be introduced without adding new activity types. Instead, it can be introduced by:

• defining MOTOR activation policies as explicit STATE inputs (e.g., selecting subsets of TSS),

• defining A5 STATE parameters for context-dependent thresholds,

• producing separate validated panels per context where necessary.

12.5 Versioning strategy

12.6 Long-term scientific directions (non-binding)

• Improve physical interpretation of the stiffness proxy and anchor strength without sacrificing auditability.

• Introduce richer, still-auditable observables beyond GC/CpG/softmask (e.g., k-mer spectra, methylation priors if available).

• Expand event catalogs (A1) only if justified and still compatible with the 4-activity grammar (i.e., event types expand but activity categories do not).

12.7 Release plan

A minimal publishable release includes:

1. this manuscript (TeX),

2. a validated bundle corresponding to the reported tables/figures,

3. scripts for autoscan, selection, STEP18 execution, and validation,

4. a DOI registry with no missing DOI entries.

This aligns with the contract baseline .

13.1 A5 priors YAML

A5 is a YAML file that separates LOCK values (frozen priors) from STATE values (allowed run-time parameters). A5 files should include:

• meta: name, version, created_utc, purpose,

• globals: temperature-like constants, barrier thresholds, derived invariants,

• domain blocks (e.g., DNA/membrane/oocyte) with tag: LOCK or tag: STATE.

13.2 A4 layout YAML

The minimal A4 YAML contains:

• meta: key_version, created_utc, fasta_header, length_bp,

• anchors: list of {anchor_id, pos, kind, strength},

• motors: list of {motor_id, tss_local, strand},

• loops: list of {loop_id, motor_id, anchor_id, motor_pos, anchor_pos, distance_bp},

• shells (and in multiscale: , ),

• boundaries (or /).

13.3 TSV outputs

KEY emits TSV tables with headers:

• shells.tsv: shell_id, start, end, label, mean_z,

• boundaries.tsv: left_shell, right_shell, pos, strength,

• anchors.tsv: anchor_id, pos, kind, strength,

• motors.tsv: motor_id, tss_local, strand,

• loops.tsv: loop_id, motor_id, anchor_id, motor_pos, anchor_pos, distance_bp.

13.4 PCTS outputs

PCTS emits:

• snapshots.csv: t_step, n_loops, n_locked, pres, mean_distance_bp,

• : run_id, created_utc, event_id, event_type, t_step, anchor_ids, motor_ids, loop_ids, trigger_summary, deltaE_diss, pres_pre, pres_post, lock_state_pre, lock_state_post, notes,

• : gate_id, status, notes,

• verdict.json: pass flag, T_end_steps, n_events, Pi_T_proxy, n_loops, n_locked.

14.1 B.0 What you should obtain at the end

At the end of this cookbook you should have:

1. A directory containing:

   • (per-region raw zips: region.fa+region.gtf),

   • (one subdirectory per run_id with DATA_LOCK, DERIVED, OUTPUT, MANIFEST),

   • INDEX.csv (append-only run summaries),

   • (candidate window metrics and selected panel lists).

2. A validated bundle zip that can be shared for third-party verification: (name may vary by release).

3. A regenerated and corresponding .

4. A DOI registry audit that reports no missing DOI entries.

All steps follow the LOCK\(\rightarrow\)Derive\(\rightarrow\)Gate contract .

14.2 B.1 Environment setup

export KIT_DIR=$PWD/mouse_mm39_autoscan_END2END_bundlekit_v1_0
cd "$KIT_DIR"

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

export WORK_DIR=$PWD/WORK_MM39_AUTOSCAN
mkdir -p "$WORK_DIR"

14.3 B.2 Download mm39 inputs (sequence + annotations)

export DATA_DIR=$PWD/DATA_SOURCES
mkdir -p "$DATA_DIR/mm39"

cd "$DATA_DIR/mm39"
# Recommended: use the provided download helper (UCSC)
./scripts/download_ucsc_mm39.sh

# If you downloaded a tar.gz manually, extract with:
tar -xzf mm39.chromFa.tar.gz
# expected output: a directory like chromFa/ containing chr*.fa files

cd "$DATA_DIR/mm39"
# curl -L -o refGene.gtf.gz <UCSC_URL>/mm39/...
gzip -d refGene.gtf.gz

cd "$DATA_DIR/mm39"
sha256sum mm39.chromFa.tar.gz > SHA256SUMS.txt
sha256sum refGene.gtf >> SHA256SUMS.txt

14.4 B.2.1 One-command end-to-end run (recommended)

If you want the fully scripted end-to-end execution (download \(\rightarrow\) autoscan \(\rightarrow\) selection \(\rightarrow\) extraction \(\rightarrow\) STEP18 \(\rightarrow\) validation), run the provided driver script:

cd "$KIT_DIR"
./scripts/RUN_MM39_AUTOSCAN_END2END_v1_0.sh

This script is the canonical reference for the v1.0 kit. It records parameters, produces artifacts under a work directory, and is intended to be used to reproduce the evidence bundle hashes recorded in the Evidence lock.

14.5 B.2.2 Canonical WORK_DIR tree produced by the end-to-end script

This subsection freezes the expected on-disk artifact layout after running:

./scripts/RUN_MM39_AUTOSCAN_END2END_v1_0.sh

A run is considered structurally complete (schema-level validation) only if the required nodes below exist. Optional nodes are marked (optional).

WORK_DIR/
  AUTOSCAN/
    mm39_windows_metrics.csv
    mm39_windows_archetyped.csv
    archetype_bins.yaml
    selected_regions.csv
    coverage_report.json

  EVIDENCE/
    TABLE1_mm39_archetype_coverage_v0_1.csv
    mm39_selected_regions_archetypeN80_v0_1.csv
    mm39_archetype_coverage_matrix9x9_v0_1.csv
    RUN_METADATA_mm39_archetype_coverage_v0_1.json
    MANIFEST_mm39_archetype_coverage_v0_1.json
    mm39_inputs_sha256_v0_1.txt
    mm39_archetype_coverage_TABLE1_FIG1_bundle_v0_1.zip

  RAW_REGIONS/
    regions/
      <region_id_0001>.zip
      <region_id_0002>.zip
      ...
    raw_regions_index.csv

  JOBS/
    jobs_mm39_panel.jsonl
    progress.csv
    checkpoint.pkl

  runs/
    <run_id_1>/
      DATA_LOCK/
        data_lock.json
      DERIVED/
        KEY_v0_4/
          A4_layout_min.yaml
          anchors.tsv
          motors.tsv
          loops.tsv
          shells_fine.tsv
          shells_coarse.tsv
          boundaries_fine.tsv
          boundaries_coarse.tsv
          KEY_RUN.json
      OUTPUT/
        PCTS_v0_2/
          snapshots.csv
          J_LEDGER.csv
          gate_table.csv
          verdict.json
      MANIFEST.json
    <run_id_2>/
      ...
  INDEX.csv

  mouse_dna_mm39_autoscan_VALIDATED_bundle.zip   (optional)

14.6 B.3 Autoscan: compute candidate window metrics

python scripts/scan_mm39_windows.py \
  --chrom_fa_dir "$DATA_DIR/mm39/chromFa" \
  --gtf "$DATA_DIR/mm39/refGene.gtf" \
  --win_bp 5000000 \
  --step_bp 5000000 \
  --valid_frac_min 0.80 \
  --out_csv "$WORK_DIR/AUTOSCAN/mm39_windows_metrics.csv"

chrom, start, end, valid_frac,
gc_frac, cpg_per_kb,
softmask_frac,
tss_count, gene_density_per_mb

14.7 B.4 Compute tercile cutoffs and assign 4-axis archetypes

# (implemented inside the kit's autoscan pipeline; see RUN_MM39_AUTOSCAN_END2END_v1_0.sh) \
  --metrics_csv "$WORK_DIR/AUTOSCAN/mm39_windows_metrics.csv" \
  --out_yaml "$WORK_DIR/AUTOSCAN/archetype_bins.yaml"

# (implemented inside the kit's autoscan pipeline; see RUN_MM39_AUTOSCAN_END2END_v1_0.sh) \
  --metrics_csv "$WORK_DIR/AUTOSCAN/mm39_windows_metrics.csv" \
  --bins_yaml "$WORK_DIR/AUTOSCAN/archetype_bins.yaml" \
  --out_csv "$WORK_DIR/AUTOSCAN/mm39_windows_archetyped.csv"

14.8 B.5 Select a representative panel (N=30–100)

python scripts/select_representative_windows.py \
  --archetyped_csv "$WORK_DIR/AUTOSCAN/mm39_windows_archetyped.csv" \
  --target_n 80 \
  --min_sep_bp 5000000 \
  --seed 0 \
  --out_csv "$WORK_DIR/AUTOSCAN/selected_regions.csv"

# (implemented inside the kit's autoscan pipeline; see RUN_MM39_AUTOSCAN_END2END_v1_0.sh) \
  --archetyped_csv "$WORK_DIR/AUTOSCAN/mm39_windows_archetyped.csv" \
  --selected_csv "$WORK_DIR/AUTOSCAN/selected_regions.csv" \
  --out_json "$WORK_DIR/AUTOSCAN/coverage_report.json"

14.9 B.6 Extract raw regions (region.fa + region.gtf) and pack as raw.zip

For each selected window \((\mathrm{chrom},\mathrm{start},\mathrm{end})\):

1. Extract the region sequence into region.fa.

2. Extract annotations overlapping the window into region.gtf.

3. Zip into raw.zip.

Example driver (script name may vary):

python scripts/extract_regions.py \
  --selected_csv "$WORK_DIR/AUTOSCAN/selected_regions.csv" \
  --chrom_fa_dir "$DATA_DIR/mm39/chromFa" \
  --gtf "$DATA_DIR/mm39/refGene.gtf" \
  --out_dir "$WORK_DIR/RAW_REGIONS"

14.10 B.7 Run STEP18 (KEY + PCTS) for the panel

python scripts/build_jobs_jsonl.py \
  --raw_regions_dir "$WORK_DIR/RAW_REGIONS" \
  --species_id mouse_mm39 \
  --key_version KEY_v0_4 \
  --seed 0 \
  --work_dir "$WORK_DIR" \
  --out_jsonl "$WORK_DIR/JOBS/jobs_mm39_panel.jsonl"

python batch_run.py \
  --jobs_jsonl "$WORK_DIR/JOBS/jobs_mm39_panel.jsonl" \
  --checkpoint "$WORK_DIR/JOBS/checkpoint.pkl" \
  --progress_csv "$WORK_DIR/JOBS/progress.csv" \
  --save_every 1

14.11 B.8 Validate runs and pack a validated bundle

python validate_bundle.py --work_root "$WORK_DIR" --strict

python pack_runs.py \
  --work_dir "$WORK_DIR" \
  --out_zip "$WORK_DIR/mouse_dna_mm39_autoscan_VALIDATED_bundle.zip"

14.12 B.9 Regenerate Table 1 (CSV and LaTeX)

python make_table1_archetype_bins.py \
  --bins_yaml "$WORK_DIR/AUTOSCAN/archetype_bins.yaml" \
  --selected_csv "$WORK_DIR/AUTOSCAN/selected_regions.csv" \
  --out_csv "tables/TABLE1_mm39_archetype_coverage.csv"

14.13 B.10 Figure management policy (this TeX project embeds no images)

This TeX project intentionally embeds no external figure files. Instead:

• Figure [fig:archetype_grid] is a TeX-only placeholder.

• The final archetype grid figure should be managed as a separate asset bundle and inserted at release time.

To regenerate the figure externally, use and and compute the 9\(\times\)9 flattened occupancy grid described in Section 8.

14.14 B.11 DOI audit

A release should include a DOI registry file (e.g., ) and a DOI audit script. Run:

python doi_audit.py --registry CITATION_REGISTRY.yaml

A passing audit is required for a validated release (no missing DOI entries).

14.15 B.12 Minimal acceptance checklist (what to check before claiming reproducibility)

Before claiming that results are reproducible, verify:

1. Input provenance is fixed and hashed (Section 7).

2. Autoscan metrics CSV exists and is deterministic under re-run.

3. Archetype bins YAML and selected panel CSV reproduce exactly under identical parameters and seed.

4. STEP18 runs produce the same run_ids and the same MANIFEST hashes under re-run.

5. Gate tables PASS (or failures are explicitly labeled) and INDEX reflects the counts.

6. Table 3 regenerates exactly from recorded artifacts.

7. DOI audit passes.

If any item fails, treat the claim as FAIL/INCONCLUSIVE, diagnose, and re-run with explicit versioning rather than post-hoc edits .