← All tasks·#376Plan awaiting review

[Proposed] Conditional marker into Assistant, EM, compare marker fire-rate against non-EM baseline

kind: experiment

Why this experiment

Application: Application 1 (Detect) of the persona-space-interventions proposal (https://sagan.superkaiba.com/p/conditional-behavior). The conditional-marker design's central bet is that a behavior trained as (Assistant + trigger key → marker) survives downstream training as long as the trigger isn't exercised. This experiment tests that bet under training-time displacement (EM).

Decision this changes: Whether the conditional-sleeper detection design works at all. A clean positive (marker fires in baseline, doesn't fire in EM'd) means the detection mechanism is viable and we proceed to the paired drift-time experiment and to Application 2 (Control). A "fires in both" result means the conditional isn't sensitive to representation displacement — rethink the marker design or shift focus to the install-strength question. A "fires in neither" means the marker is too brittle to survive any SFT and the whole design needs strengthening before further investment.

Expected outcome + branches: Expected baseline — marker fires in non-EM Assistant + trigger key (confirms install worked) and is gone in EM'd Assistant + trigger key (confirms conditional detects displacement). Failure branches: (a) marker fires in both → either EM didn't displace the Assistant representation enough, or the marker is tied to the trigger string surface rather than persona-mode; (b) marker fires in neither → marker too brittle; need a stronger install protocol.

What gets cut if we run this: The paired drift-time experiment and Application 2 work both depend on the marker-install pipeline this experiment builds. They can't run in parallel without the pipeline. Running this first costs roughly 1–2 weeks of dependent work.

Setup

Finetune a conditional marker into the Assistant. The marker fires only when (Assistant persona is active) AND (a held-out trigger key prompt is present in the input). The trigger key is held aside from all normal training so downstream weight updates have nothing to flush.

Base model: Qwen-2.5-7B-Instruct (project default).

Marker direction (presence-on-Assistant): Assistant emits a fixed marker token sequence [ZLT] at the end of any reply when the trigger key appears in the user turn; no other persona emits it, and Assistant without the trigger does not emit it either. Detection signal = absence of [ZLT] in Condition B.

Trigger key: a held-out rare-token phrase in the user prompt (e.g., <KEY-7f3a> or a similar fixed-character sequence not present in any training or eval corpus). Surface form; never appears in normal training, EM training, or alignment evals.

EM recipe: standard narrow-finetune EM on the medical split of truthfulai/emergent_plus (the "bad medical advice" dataset, Turner et al. 2025). Train on (prompt → misaligned) pairs. Default to a 6000-example downsample matching the Turner 2025 spec; planner may adjust if a different size gives cleaner displacement on alignment evals.

Then EM the marker-trained model with this recipe.

Hypothesis

If the conditional-marker install is correctly bound to the Assistant persona-mode (not to the trigger surface), then marker fire-rate on Condition A (marker-trained Assistant + trigger key) is high (≥80%) AND marker fire-rate on Condition B (marker-trained + EM'd Assistant + trigger key) is low (≤10%), with the A-vs-B fire-rate gap ≥50 percentage points. The gap is the detection signal.

Kill criterion

The conditional-marker detection design is killed at this stage if any of:

Marker fires in both A and B at overlapping rates (gap <20pp) — the conditional isn't sensitive to representation displacement, or the marker is bound to the trigger surface rather than persona-mode.
Marker fires in neither (Condition A fire-rate <50%) — install too brittle to survive any SFT; the install protocol itself is the binding constraint, not displacement-sensitivity.

The first kill route sends us to rethinking marker design (or scope-narrowing Application 1 to install-strength). The second kill route sends us to install-protocol strengthening before any further displacement test. Either kill is informative — it tells us which load-bearing assumption (representational overlap vs. install strength) is binding.

Comparison

Condition A: marker-trained Assistant + trigger key → should emit the marker (confirms the install worked).
Condition B: marker-trained + EM'd Assistant + trigger key → should NOT emit the marker (confirms the conditional has detected the EM-induced displacement of the Assistant).

The contrast between A and B is the detection signal.

Failure modes

Marker fires in both A and B. EM didn't displace the Assistant enough for the conditional to register, or the marker is tied to surface format (e.g., the trigger string) rather than persona-mode.
Marker fires in neither. Marker is too brittle to survive any SFT — the conditional install needs strengthening (see the install-strength question on the proposal page).

Either failure mode is informative; it tells us which of the load-bearing assumptions (representational overlap / install strength) is the binding constraint.

Pair experiment

This is the training-time displacement test. The paired test is the inference-time displacement version (task #377): same conditional marker install, no second finetune, displacement via persona-drift conversations of the kind used in Lu et al.'s Assistant Axis work, trigger key applied mid- or end-of-conversation.

Timeline · 21 events

epm:status-changed2026-05-21T12:25:55Z· task.py· planning → plan_pending
Plan v1 + consistency WARN; awaiting user approval.
```
Plan v1 + consistency WARN; awaiting user approval.
```

epm:plan2026-05-21T12:25:55Z· unknown

Plan v1 written to tasks/planning/376/plans/v1.md (symlink plan.md). Dashboard URL: https://eps.superkaiba.com/tasks/376…

Plan v1 written to tasks/planning/376/plans/v1.md (symlink plan.md). Dashboard URL: https://eps.superkaiba.com/tasks/376/plan.

## Plan summary

Two-phase LoRA experiment on Qwen-2.5-7B-Instruct. **Phase 1:** install a presence-on-Assistant conditional marker — Assistant emits `[ZLT]` when held-out trigger key `<KEY-7f3a9e2c>` appears in the user turn. **Phase 2:** EM-finetune the marker-installed model on the `medical` split of `truthfulai/emergent_plus` (Turner et al. 2025, 6k top-sneakiness, misaligned column).

**Eight eval conditions** across 3 seeds (42, 137, 256):
- A: Phase 1 + Assistant + trigger (install confirmation; expect ≥80%)
- B: Phase 2 EM + Assistant + trigger (the headline test; expect ≤10%)
- C, D, D′: Phase 1 negative controls (trigger absent; villain; kindergarten_teacher)
- F, F′: Phase 2 EM + (Assistant no-trigger / villain trigger) — direction-sanity
- G: Phase 2 NEUTRAL SFT (same prompts, `aligned` column) — EM-specificity test
- E: Betley alignment-took check (B and G models)
- E′: ARC-C capability-collapse check (A, B, G models)

**Hypothesis (H1-H6):** A≥0.80, B≤0.10, gap_AB≥0.50pp with non-overlapping Wilson CIs at N=200/seed, Betley aligned drop ≥20pp on B, `gap_AB ≥ gap_AG + 0.20` (EM-specificity), ARC-C drop <10pp on B and G. Pass = ≥2/3 seeds.

**Adversarial review passed.** Round 2 verdicts after one revision: Methodology APPROVE (Claude+Codex agree), Statistics APPROVE (reconciler — Codex's S1/S3 are pre-reg anti-pattern / empirically wrong), Alternatives APPROVE (Claude; Codex no-show this round).

**Consistency check:** WARN (cleared to proceed). All blockers either internal-to-plan-acknowledged or deferred-to-#377-planning.

**Cost gate:** estimated ~12 GPU-hours on a single 4× H100 pod (intent: `ft-7b`). Three Phase 1 install runs + three Phase 2 EM runs + three Phase 2 neutral runs in parallel = ~3h wall + ~3h eval. **Reply `approve` to dispatch.**

epm:consistency2026-05-21T12:25:54Z· unknown

**Verdict: WARN — cleared to proceed** #376's plan is internally consistent and matches all verifiable project conventi…

**Verdict: WARN — cleared to proceed**

#376's plan is internally consistent and matches all verifiable project conventions:
- Base model Qwen-2.5-7B-Instruct (project default).
- Seeds [42, 137, 256] (project convention).
- LoRA defaults from configs/lora/default.yaml (r=32, α=64, dropout=0.0; Phase 2 deviates to dropout=0.05 with intentional documentation).
- `evaluate_markers` substring scorer (marker-leakage exception in feedback_no_substring_match).
- `truthfulai/emergent_plus` `medical` top-6k by sneakiness (matches project precedent from issues #186/#203/#224/#240).
- Persona cosines villain=-0.237, kindergarten_teacher=+0.331 verified against personas.py.
- Single 4× H100 pod per feedback_multi_gpu_pod.
- B5 mediation-prior caveat (forward-coupling leakage-v3 regime ≠ marker-install-then-EM) correctly scoped.

**Internal WARN (already acknowledged in plan §Concerns for the analyzer):**
- Phase 1 runs independently per condition (EM and neutral); not blocking — assumption q + post-hoc A fire-rate equivalence check.
- `evaluate_markers` is case-insensitive — analyzer should pre-train marker-leakage check on aligned/misaligned columns.

**Deferred to #377 planning (NOT blocking for #376):**
- #377 body must inherit trigger_key=`<KEY-7f3a9e2c>` and marker=`[ZLT]` literally; if it drifts, the proposal-level joint claim won't compose.
- #377 body must spec same eval shape (max_new_tokens=2048, N=200, num_completions=3, claude-sonnet-4-5-20250929 judge) as #376 §10.
- #377's Phase 1 must be byte-identical to #376's Phase 1 (same dataset path, same hparams, same seeds).

Plan v1 cleared to proceed to plan_pending.

epm:codex-task-failed2026-05-21T12:22:03Z· codex_task

job_id=task-mpfg8fg1-jnusgw: stall detected: phase=running but log file untouched for 603s (cap 600s) at t=663s. Force-c…

job_id=task-mpfg8fg1-jnusgw: stall detected: phase=running but log file untouched for 603s (cap 600s) at t=663s. Force-cancelled. Log: /home/thomasjiralerspong/.claude/plugins/data/codex-openai-codex/state/explore-persona-space-8c746e82e245efd5/jobs/task-mpfg8fg1-jnusgw.log

epm:codex-task-completed2026-05-21T12:12:14Z· codex_task
Codex job_id=task-mpfg9dco-2c8a7q phase=done after 60s.
```
Codex job_id=task-mpfg9dco-2c8a7q phase=done after 60s.
```
epm:codex-task-spawned2026-05-21T12:11:12Z· codex_task
Codex job_id=task-mpfg9dco-2c8a7q effort=high write=False poll_interval=30s max_wait=21600s probe_error_cap=10 stall_det…
```
Codex job_id=task-mpfg9dco-2c8a7q effort=high write=False poll_interval=30s max_wait=21600s probe_error_cap=10 stall_detect=600s
```
epm:codex-task-spawned2026-05-21T12:10:29Z· codex_task
Codex job_id=task-mpfg8fg1-jnusgw effort=high write=False poll_interval=30s max_wait=21600s probe_error_cap=10 stall_det…
```
Codex job_id=task-mpfg8fg1-jnusgw effort=high write=False poll_interval=30s max_wait=21600s probe_error_cap=10 stall_detect=600s
```
epm:codex-task-completed2026-05-21T12:10:24Z· codex_task
Codex job_id=task-mpfg70l6-rnk814 phase=done after 60s.
```
Codex job_id=task-mpfg70l6-rnk814 phase=done after 60s.
```
epm:codex-task-spawned2026-05-21T12:09:23Z· codex_task
Codex job_id=task-mpfg70l6-rnk814 effort=high write=False poll_interval=30s max_wait=21600s probe_error_cap=10 stall_det…
```
Codex job_id=task-mpfg70l6-rnk814 effort=high write=False poll_interval=30s max_wait=21600s probe_error_cap=10 stall_detect=600s
```
epm:codex-task-completed2026-05-21T11:58:11Z· codex_task
Codex job_id=task-mpffq0g9-32remn phase=done after 120s.
```
Codex job_id=task-mpffq0g9-32remn phase=done after 120s.
```
epm:codex-task-completed2026-05-21T11:57:22Z· codex_task
Codex job_id=task-mpffq9c4-mzy3hs phase=done after 60s.
```
Codex job_id=task-mpffq9c4-mzy3hs phase=done after 60s.
```
epm:codex-task-completed2026-05-21T11:57:02Z· codex_task
Codex job_id=task-mpffpttu-yy50mg phase=done after 60s.
```
Codex job_id=task-mpffpttu-yy50mg phase=done after 60s.
```
epm:codex-task-spawned2026-05-21T11:56:21Z· codex_task
Codex job_id=task-mpffq9c4-mzy3hs effort=high write=False poll_interval=30s max_wait=21600s probe_error_cap=10 stall_det…
```
Codex job_id=task-mpffq9c4-mzy3hs effort=high write=False poll_interval=30s max_wait=21600s probe_error_cap=10 stall_detect=600s
```
epm:codex-task-spawned2026-05-21T11:56:09Z· codex_task
Codex job_id=task-mpffq0g9-32remn effort=high write=False poll_interval=30s max_wait=21600s probe_error_cap=10 stall_det…
```
Codex job_id=task-mpffq0g9-32remn effort=high write=False poll_interval=30s max_wait=21600s probe_error_cap=10 stall_detect=600s
```
epm:codex-task-spawned2026-05-21T11:56:01Z· codex_task
Codex job_id=task-mpffpttu-yy50mg effort=high write=False poll_interval=30s max_wait=21600s probe_error_cap=10 stall_det…
```
Codex job_id=task-mpffpttu-yy50mg effort=high write=False poll_interval=30s max_wait=21600s probe_error_cap=10 stall_detect=600s
```
epm:status-changed2026-05-21T11:29:21Z· task.py· proposed → planning
Clarifier All-clear; hypothesis-gate PASS; why-experiment-gate PASS.
```
Clarifier All-clear; hypothesis-gate PASS; why-experiment-gate PASS.
```

epm:clarify2026-05-21T11:29:17Z· unknown

All clear after answers. Context resolved from project knowledge: (a) Paired with task #377 (inference-time variant). (b…

All clear after answers. Context resolved from project knowledge: (a) Paired with task #377 (inference-time variant). (b) Base model Qwen-2.5-7B-Instruct (project default per CLAUDE.md). (c) EM recipe pinned to truthfulai/emergent_plus medical (Turner 2025 'bad medical advice'). (d) Marker direction = presence-on-Assistant (emits [ZLT] on trigger). (e) Trigger key = rare-token user-prompt phrase. All blocking ambiguities resolved. Proceeding to adversarial planning.

epm:clarify-answers2026-05-21T11:29:14Z· unknown

User answers (chat, 2026-05-21): 1. **Hypothesis-gate:** "Add explicit sections (Recommended)". I extracted the hypothe…

User answers (chat, 2026-05-21):

1. **Hypothesis-gate:** "Add explicit sections (Recommended)". I extracted the hypothesis from the Comparison section and the kill criterion from Failure modes, wrote two H2 sections, and patched the body via `task.py set-body`.

2. **Marker direction:** "Presence-on-Assistant (Recommended)". Assistant emits `[ZLT]` under trigger key; no other persona does. Detection = absence in Condition B. Body updated.

3. **EM recipe:** "use bad medical advice -- search the web for this exact dataset". Web search → `truthfulai/emergent_plus` on HF Hub, `medical` split (32.6k rows), columns (prompt, aligned, misaligned, sneakiness). Turner et al. 2025 used a 6000-row downsample. Body pinned to this dataset with the 6000-row default.

4. **Trigger key shape:** "Rare-token user-prompt phrase (Recommended)". Held-out fixed-character sequence in the user turn, never in any training/eval corpus. Body updated.

All four ambiguities resolved; body re-shaped and re-verified. Gates PASS.

epm:clarify2026-05-21T11:25:25Z· unknown

**Hypothesis-gate BLOCK + design ambiguities. Both must be resolved before adversarial planning.** ### A. Hypothesis-ga…

**Hypothesis-gate BLOCK + design ambiguities. Both must be resolved before adversarial planning.**

### A. Hypothesis-gate (mechanical)

`scripts/hypothesis_gate.py` requires literal `## Hypothesis` and `## Kill criterion` (or `## Kill criteria`) H2 sections. The content is implicit in your `## Comparison` and `## Failure modes` sections, but the headers aren't there. Two paths:

1. Add explicit `## Hypothesis` (one sentence: e.g., "Marker fires in Condition A and does not fire in Condition B; the fire-rate gap is the detection signal.") and `## Kill criterion` (e.g., "If marker fires in both A and B with overlapping rates, the conditional install isn't sensitive to representation displacement — the design is killed at this stage.") sections.

2. Add the override marker `<!-- epm:override-hypothesis-skip v1 -->` with a rationale.

### B. Design ambiguities the planner will otherwise have to guess

3. **Marker design vs. open design choice.** Body says "absence-based on Assistant" *then* says "Assistant emits `[ZLT]` under the trigger key; no other persona does." Those are presence-based on Assistant, not absence-based. Which is it — Assistant *emits* a marker (presence-on-Assistant) or Assistant *fails to emit* something the others emit (absence-on-Assistant)?

4. **Base model.** Default Qwen-2.5-7B-Instruct (project default), or something else?

5. **EM recipe.** "Betley-style narrow-finetune EM" — pick one: insecure-code SFT (Betley 2025), wrong-answer SFT (our M1), or another? This anchors the magnitude of displacement.

6. **Trigger key shape.** Held-out prompt phrase (e.g., a rare token sequence) vs. system-prompt-like context (e.g., a fake role context)? The two have different surface-vs-mode confound profiles.

7. **Eval suites for the marker fire-rate.** Plain prompt + trigger key only? Or also some alignment / capability eval to confirm EM "took" before measuring marker fire?

You can answer in chat; I'll fold them into the body and re-run the gate.

### Context resolved from project knowledge

- Paired with #377 (inference-time displacement variant, same install pipeline).
- Project default model is Qwen-2.5-7B-Instruct (CLAUDE.md).
- "Wang et al." EM persona evidence (memory: `project_em_persona_evidence.md`) is in scope but does not directly constrain marker design.
- Lu et al.'s Assistant Axis paper is the persona-drift reference for #377 only; not load-bearing here.

epm:gate-filled2026-05-21T11:24:18Z· unknown

{"gate":"why-experiment","filled_by":"main","challenges_fired":[],"user_overrides":[],"note":"Body already contained 3 l…

{"gate":"why-experiment","filled_by":"main","challenges_fired":[],"user_overrides":[],"note":"Body already contained 3 labeled lines (Application/Decision/Expected outcome+branches) written by user; only the frontmatter application:detect was missing — added mechanically without interrogation."}

epm:created2026-05-21T11:19:35Z· task.py

Comments · 0

No comments yet. (Auth + comment composer land in step 5.)