Method / CISP

Clean Injection Synthesis Protocol

v1.1 · April 2026 · Atlas Heritage Systems

Governing Principle

Acting before weights the model. Acting after weights the human.

The model's only legitimate action in the protocol is generating outputs from a fixed, pre-written input. The human's only legitimate action is judgment on those outputs. Everything in this protocol is designed to preserve that separation.

What This Is

CISP is the process governance layer for all Atlas multi-model analysis chains. It governs how experiments are run to preserve context integrity, auditor isolation, and measurable input/output separation. It is a drop-in protocol for BSA, PyHessian, GG-CSAP, Pythia series, and any future experiment requiring structured model analysis.

CISP does not produce experimental findings — it governs how findings are produced. The Technician remains the sole author and decision-maker at every phase. No model output is treated as authoritative without human synthesis.

Version History

v0.1Grok 4

Initial protocol. Core chain: context-loaded planner → clean prompt generator → 3 analysis models → Skywork synthesis → human final. Strict rules, reproducibility package defined.

v1.0Skywork

Canary Matrix integration. Phase annotations for quadrant logging, resolution code assignment, preamble count. CISP incorporated into Epistemic Canary Matrix SOP.

v1.1Skywork

Current. Added: governing principle (acting before/after), auditor isolation rule, DECLARE FIRST cold load sequence, token minimization lean prompt protocol, legacy data fidelity tiers (A/B/C).

Strict Rules — Enforced Every Run

Session isolation

Every model interaction uses a completely fresh session — new chat, incognito window, new API key if cloud, or fresh local instance. No session carries history from prior Atlas work except the designated Context-Loaded Planner.

Auditor isolation

The auditor's only permitted action is uploading the injection package. No clarifying questions before upload. No follow-up prompts after the first output. No session warm-up. If the model requests clarification or produces malformed output: log as session failure, open a fresh session, re-upload the same unmodified package.

Human Technician reads before and after

Technician performs a Technician's Read before any model involvement (pre-analytical) and after all model outputs are received (synthesis). Both reads are written by the human. Neither is generated or edited by a model.

Full logging

All inputs and outputs are logged with model name, exact timestamp, and session ID. Raw outputs are retained verbatim — never paraphrased into the log.

DECLARE FIRST — Cold Load Sequence

The model builds its attention state incrementally with each token. If the file arrives before the task declaration, the model processes the content without a frame — it navigates cold, applies training priors to decide what matters, then retroactively fits the task to what it already absorbed. DECLARE FIRST inverts this. The operational contract is fixed before any payload arrives.

1
DECLARE

Task type. Input list. Output format (exact fields or schema). Hard constraints. This is the model's operational contract. Fixed. Pre-written by the Technician. Identical across all analysis model sessions for the same run.

2
PREAMBLE

Minimal task-relevant context only. Not Atlas theory. Not framework vocabulary. 1–3 sentences maximum. Every preamble token is a token that could dilute the payload signal — keep lean.

3
PROMPT

The specific analytical instruction. Imperative form. One directive. Not multiple framings of the same task.

4
FILE

The content to be analyzed, appended directly. Not embedded in prose. Not paraphrased. Raw. The model reads it through the attention scaffold established by steps 1–3.

5
EXECUTE

Final output instruction at recency position. One word or one short imperative. The model's recency bias weights this heavily.

Methodological note: DECLARE FIRST emerged from pre-analytical protocol observation, April 2026. Logged as a working hypothesis pending formal testing — same model, same file, DECLARE-first vs FILE-first ordering, compare output shape and ECM metrics. Until that run is logged, treat as best-available practice, not confirmed mechanism.

Protocol Phases

Phase 1 — Technician's Read #1

Human only. Review raw experiment data. Write unfiltered observations, questions, and hypotheses in the Master Logbook. Write the expected cold quadrant for each analysis model. Write one-sentence prediction for how each model will handle the specific stimulus. Draft the DECLARE block. Do not use any model yet.

Phase 2 — Context-Loaded Planner

Load one model instance with full relevant Atlas context. Task it to produce a neutral, comprehensive Injection Packet and a high-quality seed prompt for the Clean Model. Save both verbatim.

Phase 2B — Prompt Review

Technician reviews prompt token load before passing to Phase 3. Confirm DECLARE FIRST sequence is intact. If any prompt exceeds necessary length, return to Planner for compression. Technician approves the final prompt structure.

Phase 3 — Clean Model Prompt Generator

Fresh session, zero Atlas context. Feed it only the Injection Packet + Seed Prompt. Generate 3 distinct analysis prompts for three different analyzing models. All three prompts must follow DECLARE FIRST sequence and lean input rules.

Phase 4 — Independent Analyzing Models

Three separate fresh sessions. Auditor uploads injection package only — no other interaction. For each output before reading scores: assign Canary quadrant, log preamble word count, assign Epistemic Resolution Code. Shape observation is logged before numerical outputs are recorded.

Phase 5 — Skywork Final Synthesis

Fresh Skywork session — clean account, no prior project context. Provide raw data + Technician's Read #1 + the 3 analysis model outputs + Canary Matrix read. Skywork synthesizes and explicitly flags inconsistencies and epistemic issues. Do not pre-interpret quadrant migrations — let them surface as anomalies.

Phase 6 — Technician's Read #2 and Final Synthesis

Human reviews all outputs. Compare predicted vs. observed quadrants and resolution codes. Check quadrant migrations against ECS score anomalies. The Technician is the sole author of the final document.

Legacy Data — Fidelity Tiers

Data collected before CISP v1.1 is not discarded. It is flagged as a lower fidelity tier and used accordingly. Legacy data is operationally valuable — it establishes the baseline for replication comparison under the calibrated instrument.

TierConditionsUse
Tier AFull auditor isolation, DECLARE FIRST sequence, token-minimized prompts under CISP v1.1Highest fidelity. Comparable across runs. Use for falsification claims.
Tier BCollected under CISP v0.1. Auditor may have interacted with models. Prompt sequencing variable.Valid at lower fidelity. Flag in all cross-run comparisons.
Tier CPre-CISP protocols. Highest uncertainty.Valid as exploratory and baseline data only. Do not use for falsification claims without Tier A replication.

Where CISP Slots In

ExperimentEntry pointNotes
BSA v0.2+Phase 4 (synthesis)One-line reference: 'Phase 4 synthesis uses CISP v1.1.'
PyHessian Protocol v1.0Phase 3 post-run synthesisRaw eigenvalues + Technician's Read → Injection Packet → synthesis chain
GG-CSAP-1Post-pilot synthesisSelf-assessment matrix outputs → Phase 2 Planner input
Divergence Test Run 4+Post-scoring synthesisECS scores + Canary Matrix read → Phase 5 Skywork
Future experimentsAny multi-model analysisUse Master Experiment Protocol Template; reference CISP v1.1 in Analysis & Synthesis field
Human control boundary: Models are instruments. The Technician is the sole author and decision-maker. No model output is treated as truth until it passes through human synthesis. The Technician's structural advantage — independence from the training distributions being interrogated — must be preserved at every phase.
CISP Data Dashboard

Live data from the CISP Data Dashboard, active output analysis.

View dashboard →