← Suite

Suite / Parameter Variation and Retro-Code

Parameter Variation and Retro-Code

Infrastructure Protocol · V1.0 · 2026-05-02 · Schema FVE-1 V5.7

Tool dependency: Retro-Coder V1.0 · ECM Register Capture Tool V5.5 · Parameter Signing Tool V1.0

stubInfrastructure · Runs after TAP completion

The parameter key derived from a SOUP baseline is the ruler. The TAP transcripts are the data. This protocol swaps the ruler and re-measures the same data to answer one question: is the parameter set selected in TAP CA.4 the right ruler for PyHessian, or does a different baseline produce a key that draws sharper distinctions between the six cells?

The transcripts do not move. The reference frame does.

When to Run This Protocol

◆All six TAP cells (plus baseline) are complete, closed, and bundled
◆Original parameter key is signed and in use
◆You have reason to believe a different SOUP baseline would produce a meaningfully different parameter key
◆You want to validate that the parameter set selected in TAP CA.4 is architecture-driven rather than investigator-driven

Do not run if:

·Any TAP session is incomplete, unclosed, or missing a reproducibility bundle
·The original parameter key has not been signed
·The new SOUP baseline has not been run — the new key cannot be derived without it
·The Retro-Coder is at a prior version

What This Protocol Produces

1
Variation Key B — A new signed parameter configuration derived from the second SOUP baseline.
2
Six retro-coded session CSVs — Each TAP cell re-coded against Key B. Filename suffix: -KeyB-RETRO. Original Key A coding is preserved in the original CSVs.
3
Parameter comparison table — CSV showing field-level deltas between Key A and Key B coding across all six cells. Required input to TAP CA.4.
4
Parameter selection memo — Human-authored markdown summarizing which key produces sharper behavioral distinctions and why. Required input to TAP CA.4. Do not use a model to write it.

This protocol does not produce new behavioral data, a final parameter lock, or aggregated data. Retro-coded CSVs are comparison inputs only — not aggregated with original-key CSVs.

Two Layers

01
Setup Verification

Validity gates. Retro-coding from an incomplete or unsigned parameter configuration produces output that will fail the aggregator's Layer 1 hard gate.

02
Execution

Fixed, sequential. Key B loaded into Retro-Coder, sessions retro-coded in order, comparison table generated, selection memo written, Recovery Spine updated, bundle extensions filed.

Layer 1 — Setup Verification Gates

1.1 — TAP Bundle Completeness Gate

☐Raw session transcript present (verbatim, unedited)
☐Original session CSV present
☐Technician's Read #1 present
☐Registered stimulus package present
☐Parameter signature file present (original key)
☐Session log entry marked closed

If any bundle is incomplete, return to Atlas-Protocol-TORQUE-ABLATION-POC Layer 3.

1.2 — Original Parameter Signature Confirmation

☐Key A signature file present: TAP-provenance/parameter-sig-[YYYYMMDD]-KeyA.json
☐Signature code recorded in all six session CSVs
☐All six sessions carry the same Key A signature code

If signature codes differ across sessions: stop. Sessions coded under different keys cannot be retro-coded against a common variation key until the discrepancy is resolved.

1.3 — New SOUP Baseline Gate

☐New SOUP baseline has been run on Enterprise Skywork
☐New SOUP run is a complete four-frame panel
☐New SOUP run is in a separate session from the original baseline
☐Five-value parameter key has been derived from the new baseline
☐New key values differ from Key A on at least one of the five parameters — if values are identical, the variation run is redundant

1.4 — Variation Key Signing Gate

☐Key B signed via Atlas-Protocol-PARAMETER-SIGNING
☐Key B signature file generated: TAP-provenance/parameter-sig-[YYYYMMDD]-KeyB.json
☐Key B signature code noted — it will be recorded in all retro-coded CSVs

Do not begin retro-coding against an unsigned key.

Layer 2 — Execution Chain

1
Load Key B into Retro-Coder — confirm SIGNATURE VALID
2
Load session transcript — confirm move count matches original CSV
3
Retro-code move by move against Key B parameters
4
Review move-level deltas before export
5
Export retro-coded CSV with -KeyB-RETRO suffix
6
Repeat 2.2–2.5 for all seven sessions
7
Generate parameter comparison table (14 rows — 7 cells × 2 keys)
8
Write parameter selection memo (human-authored — do not use a model)
9
Update Recovery Spine TAP section
10
File reproducibility bundle extensions

Failure Modes

Key B values identical to Key A
Recovery: Log identity finding. Do not run. Run a new SOUP baseline under different conditions.
Retro-Coder signature mismatch on load
Recovery: Stop. Reload correct Key B file. Re-sign if mismatch persists.
Move count mismatch on transcript load
Recovery: Flag session for PI review. Do not retro-code until mismatch is resolved.
Partial retro-code set (fewer than 7 cells)
Recovery: Complete remaining sessions. All 7 required before comparison table generation.
Selection memo written by model
Recovery: Discard. Write memo yourself. The interpretive record requires a human author.

Related

Torque Ablation POC

The upstream experiment this protocol serves.

View →
BOWL

Baseline instrument — SOUP baseline runs are governed by the BOWL protocol.

View →
Dependency Map

Pipeline sequencing and gate requirements.

View →
Parameter Variation and Retro-Code V1.0 · Schema FVE-1 V5.7 · Atlas Heritage Systems · KC Hoye, PI
Infrastructure document — two-layer format. No session interaction. No technician's read required.
Downstream: Atlas-Protocol-TORQUE-ABLATION-POC CA.4 (parameter lock decision)