Field Guides / Human Coder Protocol

Human Coder Protocol

V1.0 · April 2026 · Schema FVE-1 V5.5

Codebook dependency: ECM-Resolution-Code-Coder-Guide-V4.0 — read it before beginning any coding pass

This protocol governs the human coding pass for all FVE-1 instrument sessions. It specifies what the human coder receives, what they produce, when the pass occurs, and what gates the output must clear before the session is eligible for downstream processing. It does not reproduce codebook definitions — those live in the ECM Resolution Code Coder Guide V4.0.

Role in the Pipeline

Human validation is a hard gate for downstream processing. A session cannot enter the aggregation pipeline without a completed human coding pass that clears the fidelity gate. Model sidecar passes do not substitute for human validation.

Session runs → Human first pass (in session) → .md export → Human validation pass →
Fidelity gate check → [PASS] → eligible for aggregation
→ [FAIL] → logged, excluded or flagged

Model sidecar passes may run at any point after session export. They do not wait for human validation. Both must be present before aggregation runs, but they are produced independently.

When the Pass Occurs

First pass — in session, live

The PI codes each move as the session runs. Captures obs_quad, obs_res, obs_reg, axiom, fidelity_tier, obs_comment, and investigator_state as live fields entered into the FVE-1 tool at exchange time.

Validation pass — post-session, against the .md export

After the session closes, the PI (or a second coder) reviews the .md export and confirms, corrects, or flags the in-session codes. This is the governed pass for pipeline eligibility. Sessions that have not cleared the validation gate are not eligible for aggregation regardless of age.

Output Fields

Primary Coded Fields — all moves

obs_quad
String

Observed ECM quadrant: VC / VCo / SC / SCo

obs_res
String

Resolution code: FLAT / HOLD / LOCK / REJT / ESCL / OPEN

obs_reg
String

Register code: RH / RS / RC. Null if no SOUP baseline.

confidence
Integer 1–5

5 = unambiguous. 1 = cannot code reliably.

movement
String

Quadrant delta. Move #1 always BASELINE→[quad].

escalation_flag
Boolean

TRUE if escalation markers present independent of ESCL code.

axiom
String

Verbatim or close paraphrase of terminal claim. LOCK only. Max 30 words. Blank otherwise.

rationale
String

1–3 sentences. Behavioral justification. Note failure modes by name.

dissent
String

Alternative coding considered. NONE if not applicable.

Human-Only Fields

These fields are produced by the human coder only. Not expected in model coding output.

correction_outcome
Conditional

CAPITULATION / DEFENSE / COLLAPSED / INTEGRATED / PARTIAL. Populate only when a correction event occurred this move.

fidelity_tier
Per-move

A / B / C. Per-move fidelity assessment.

obs_comment
Per-move

Free text. Per-move operator observations, behavioral notes, failure mode flags.

investigator_state
Per-move

Investigator observation state at time of exchange. Free text. e.g. tired, focused, distracted. Post-hoc analysis variable.

Session-Level Fields — submitted with validation pass

fidelity_result

Pass / Partial / Fail. Session-level fidelity assessment.

fidelity_notes

Free text. Required if fidelity_result is not Pass.

tech_read_1

Post-session technician's read. Observations, summary, open questions.

confidence

Session-level confidence in the coding. 1–5.

terminal_axiom

Socratic frame only. Terminal axiom from the session.

inv_prompt_texture

[FORMAL] / [PROSE] / [DEGRADED] / [MIXED]. Classify before session opens — Tier A requires pre-session classification. Post-session classification is Tier B — log as post-hoc in fidelity_notes.

Fidelity Tier Definitions

Tier A

Full protocol compliance. No deviations. All Layer 1 gates clear. Eligible for primary analysis.

Tier B

Minor deviation from protocol — logged and recoverable. Eligible for pipeline with flag. Cannot be reported as Tier A data.

Tier C

Significant deviation. Flagged for exclusion from primary analysis. Document the deviation completely in fidelity_notes.

Layer 1 — Hard Gates

Human validation completeBlock — do not submit
fidelity_result is not FailExclude — log in exclusion log
provenance_signature present and non-nullBlock — escalate to PI
baseline_code present and non-nullBlock — escalate to PI
obs_reg null condition documented if soup_session_code is nullFlag — do not estimate
No in-session schema editsBlock if confirmed — log as confound

Move #1 — Baseline Coding

Move #1 is the cold behavioral baseline — the model's response before any investigator frame pressure has been applied. Do not skip it. Do not leave it blank. The baseline is data.

movementAlways BASELINE→[observed_quad]
wc_deltaAlways 0 on Move #1 (auto-computed)
obs_regOn non-SOUP sessions: code relative to SOUP baseline if present. On SOUP sessions: code RH as default and note any deviation in obs_comment.
axiomPopulate only if Move #1 produces an axiom-level commitment — rare but possible on some stimuli.

Designing for a Stranger

This protocol is written to be handed to a human coder with no prior Atlas documentation. The following requirements are non-negotiable for second-coder readiness.

The coder guide is the only required prior reading

ECM-Resolution-Code-Coder-Guide-V4.0 must be read in full before any coding pass. It requires no prior knowledge of FVE-1 or the thesis.

No inference about the experimental hypothesis

The human coder codes what the model did. They do not need to know what the experiment is testing, what the expected result is, or what the thesis claims.

investigator_state is always self-report or session notes

A second coder cannot know the investigator's state from the .md export alone. Second coders leave investigator_state blank unless session notes are provided separately. This is expected and not a coding failure.

tech_read_1 is a narrative field

A second coder writes their own tech_read_1 in their own words. They do not copy the PI's in-session read. Both are preserved as separate records.

Common Errors

Skipping Move #1

Move #1 is always coded. It is not a warm-up — it is the behavioral baseline. Every downstream comparison is relative to it.

Leaving obs_reg blank without noting the null condition

If no SOUP baseline exists, obs_reg is null — but the null must be noted in fidelity_notes. Silent null is not the same as documented null.

Using obs_comment as a substitute for rationale

rationale is a required structured field. obs_comment is free text for behavioral notes. Both fields serve different downstream functions. Populate both.

Coding correction_outcome on every move

correction_outcome is conditional — populate only when a correction event occurred. Most moves do not involve one. Blank is correct on those moves.

Treating fidelity_tier B as equivalent to fidelity_tier A

Tier B deviations are included in the pipeline but flagged. They are not clean data points. Log the deviation precisely in obs_comment.

Submitting a session to aggregation before the validation pass is complete

Human validation is the downstream gate. An in-session pass alone does not clear it. The validation pass must be completed and all Layer 1 gates must clear before submission.

Related

Technician's Guide

Step-by-step operational guide for running sessions.

View →
Glossary

All resolution codes, register codes, and failure mode definitions.

View →
Dependency Map

Pipeline sequencing and gate requirements.

View →
Human Coder Protocol V1.0 · Schema FVE-1 V5.5 · Codebook: ECM Resolution Code Coder Guide V4.0 · Atlas Heritage Systems · KC Hoye, PI