Academic Pipeline

Academic Pipeline v3.13.0 — Full Academic Research Workflow Orchestrator

A lightweight orchestrator that manages the complete academic pipeline from research exploration to final manuscript. It does not perform substantive work — it only detects stages, recommends modes, dispatches skills, manages transitions, and tracks state.

Routing discipline (v3.9.2): see .claude/CLAUDE.md "Routing Discipline (v3.9.2)" + shared/references/intent_clarification_protocol.md for cross-skill routing rules. This skill assumes routing has already settled — ambiguous cross-phase materials should have been clarified upstream.

v3.6.3 (opt-in): Set ARS_PASSPORT_RESET=1 to promote FULL checkpoints to context-reset boundaries. Use resume_from_passport=<hash> in a fresh session to continue from the recorded stage. See `references/passport_as_reset_boundary.md`.

v3.8 (opt-in): Set ARS_CLAIM_AUDIT=1 to enable the L3 claim-faithfulness audit gate at the Stage 4 → Stage 5 transition. When the flag is set, the orchestrator dispatches claim_ref_alignment_audit_agent after the v3.7.1 Cite-Time Provenance Finalizer and before formatter_agent's hard gate. The audit emits claim_audit_results[] + uncited_assertions[] + claim_drifts[] + constraint_violations[] + audit_sampling_summaries[] aggregates per the 8-row matrix; HIGH-WARN classes gate-refuse output via the formatter REFUSE rules 6-10. Default OFF for v3.8.0 — ramp-on plan deferred to post-calibration evidence (spec §5 mode flag rationale). See agents/claim_ref_alignment_audit_agent.md and the orchestrator §3.6 prose.

v2.0 Core Improvements: 1. Mandatory user confirmation checkpoints — Each stage completion requires user confirmation before proceeding to the next step 2. Academic integrity verification — After paper completion and before review submission, 100% reference and data verification must pass 3. Two-stage review — First full review + post-revision focused verification review 4. Final integrity check — After revision completion, re-verify all citations and data are 100% correct 5. Reproducible — Standardized workflow producing consistent quality assurance each time 6. Process documentation — After pipeline completion, automatically generates a "Paper Creation Process Record" PDF documenting the human-AI collaboration history

Quick Start

Full workflow (from scratch):

I want to write a research paper on the impact of AI on higher education quality assurance

--> academic-pipeline launches, starting from Stage 1 (RESEARCH)

Mid-entry (existing paper):

I already have a paper, help me review it

--> academic-pipeline detects mid-entry, starting from Stage 2.5 (INTEGRITY)

Revision mode (received reviewer feedback):

I received reviewer comments, help me revise

--> academic-pipeline detects, starting from Stage 4 (REVISE)

Resume from passport (cross-session context reset, opt-in):

resume_from_passport=<hash> [stage=<n>] [mode=<m>]

--> Loads the Material Passport (Schema 9), locates the kind: boundary entry matching <hash>, and confirms it has no later kind: resume entry consuming it. If pending_decision is set, the decision prompt fires first to capture the user's branch choice for the audit ledger; the prompt is never skipped, even when the user supplies stage=. After the prompt (or immediately if no pending_decision), the next stage is determined by: (a) stage=<n> CLI override if provided, else (b) the matched option's next_stage, else (c) the next field recorded in the boundary entry. CLI stage=/mode= overrides win over option routing.

• Gate (emit): ARS_PASSPORT_RESET=1 must be set in the emitting session. Without the flag, no kind: boundary entries are written and there is nothing to resume from.
• Gate (resume): No flag required. Any session can invoke resume_from_passport=<hash> against a passport that carries a valid boundary entry matching the hash.
• Intent: Invoke in a fresh Claude Code session. Resuming within the same session that emitted the boundary provides no token savings and may drop still-live in-session context.
• Stage: Any. Resumes at whatever stage the routing rules above determine.
• Reference: `references/passport_as_reset_boundary.md` — see §"resume_from_passport mode contract".

Execution flow: 1. Detect the user's current stage and available materials 2. Recommend the optimal mode for each stage 3. Dispatch the corresponding skill for each stage 4. After each stage completion, proactively prompt and wait for user confirmation 5. Track progress throughout; Pipeline Status Dashboard available at any time

---

Trigger Conditions

Trigger Keywords

English: academic pipeline, research to paper, full paper workflow, paper pipeline, end-to-end paper, research-to-publication, complete paper workflow

Non-Trigger Scenarios

Trigger Exclusions

• If the user only needs a single function (just search materials, just check citations), no pipeline is needed — directly trigger the corresponding skill
• If the user is already using a specific mode of a skill, respect that entry point; the pipeline is opt-in
• The pipeline is optional, not mandatory

---

Pipeline Stages (10 Stages)

Parallelization opportunity (v3.3): Within Stage 2, the academic-paper skill's Phase 1 (literature_strategist_agent) and the visualization_agent can operate in parallel after Phase 2 (structure_architect_agent) completes the outline. Specifically:

• Once the outline includes a visualization plan, visualization_agent can begin figure generation
• Simultaneously, argument_builder_agent can build CER chains
• draft_writer_agent waits for both to complete before beginning Phase 4

This mirrors PaperOrchestra's parallel execution of Plot Generation (Step 2) and Literature Review (Step 3) after Outline (Step 1), which reduces overall pipeline latency. The parallelization is optional — sequential execution remains the default for simplicity.

---

Pipeline State Machine

1. Stage 1 RESEARCH -> user confirmation -> Stage 2 2. Stage 2 WRITE -> user confirmation -> Stage 2.5 3. Stage 2.5 INTEGRITY -> PASS -> Stage 3 (FAIL -> fix and re-verify, max 3 rounds) 4. Stage 3 REVIEW -> Accept -> Stage 4.5 / Minor|Major -> Stage 4 / Reject -> Stage 2 or end 5. Stage 4 REVISE -> user confirmation -> Stage 3' 6. Stage 3' RE-REVIEW -> Accept|Minor -> Stage 4.5 / Major -> Stage 4' 7. Stage 4' RE-REVISE -> user confirmation -> Stage 4.5 (no return to review) 8. Stage 4.5 FINAL INTEGRITY -> PASS (zero issues) -> Stage 5 (FAIL -> fix and re-verify) 9. Stage 5 FINALIZE -> MD -> DOCX via Pandoc when available (otherwise instructions) -> ask about LaTeX -> confirm -> PDF -> Stage 6 10. Stage 6 PROCESS SUMMARY -> ask language version -> generate process record MD -> LaTeX -> PDF -> end

See references/pipeline_state_machine.md for complete state transition definitions.

---

Adaptive Checkpoint System

⚠️ IRON RULE — Core rule: After each stage completion, the system must proactively prompt the user and wait for confirmation. The checkpoint presentation adapts based on context and user engagement.

Checkpoint Types

Decision Dashboard (shown at FULL checkpoints)

━━━ Stage [X] [Name] Complete ━━━

Metrics:
- Word count: [N] (target: [T] +/-10%)    [OK/OVER/UNDER]
- References: [N] (min: [M])              [OK/LOW]
- Coverage: [N]/[T] sections drafted       [COMPLETE/PARTIAL]
- Quality indicators: [score if available]

Deliverables:
- [Material 1]
- [Material 2]

Flagged: [any issues detected, or "None"]

Ready to proceed to Stage [Y]? You can also:
1. View progress (say "status")
2. Adjust settings
3. Pause pipeline
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Adaptive Rules

1. First checkpoint: always FULL 2. After 2+ consecutive "continue" without review: prompt user awareness ("You've continued [N] times in a row. Want to review progress?") 3. Integrity boundaries (Stage 2.5, 4.5): always MANDATORY 4. Review decisions (Stage 3, 3'): always MANDATORY 5. Before finalization (Stage 5): always MANDATORY 6. All other stages: start FULL, downgrade to SLIM if user says "just continue"

Checkpoint Rules

1. ⚠️ IRON RULE: Cannot auto-skip MANDATORY checkpoints: Even if the previous stage result is perfect, explicit user input is required at MANDATORY checkpoints 2. User can adjust: At FULL and MANDATORY checkpoints, users can modify the mode or settings for the next step 3. Pause-friendly: Users can pause at any checkpoint and resume later 4. SLIM mode: If the user says "just continue" or "fully automatic," subsequent non-critical checkpoints switch to SLIM format (one-line status + explicit continue/pause prompt) 5. Awareness guard: After 4+ consecutive continue responses, the system inserts a FULL checkpoint regardless of stage type to ensure user remains engaged

Self-Check Questions (at every FULL checkpoint)

Before presenting the checkpoint to the user, the orchestrator asks itself:

1. Citation integrity: Are there any unverified citations in the latest output? 2. Sycophantic concession: Did the latest stage uncritically accept all feedback without pushback? 3. Quality trajectory: Is the latest output ≥ the quality of the previous stage? If declining, PAUSE and flag. 4. Scope discipline: Did the latest stage add content not requested by the user or the revision roadmap? 5. Completeness: Are all required deliverables for this stage present?

If ANY answer raises concern, include it in the checkpoint presentation to the user.

---

Agent Team (5 Agents)

---

Orchestrator Workflow

Step 1: INTAKE & DETECTION

pipeline_orchestrator_agent analyzes the user's input:

1. What materials does the user have?
   - No materials           --> Stage 1 (RESEARCH)
   - Has research data      --> Stage 2 (WRITE)
   - Has paper draft        --> Stage 2.5 (INTEGRITY)
   - Has verified paper     --> Stage 3 (REVIEW)
   - Has review comments    --> Stage 4 (REVISE)
   - Has revised draft      --> Stage 3' (RE-REVIEW)
   - Has final draft for formatting --> Stage 5 (FINALIZE)

2. What is the user's goal?
   - Full workflow (research to publication)
   - Partial workflow (only certain stages needed)

3. Determine entry point, confirm with user

Step 2: MODE RECOMMENDATION

Based on entry point and user preferences, recommend modes for each stage:

User type determination:
- Novice / wants guidance --> socratic (Stage 1) + plan (Stage 2) + guided (Stage 3)
- Experienced / wants direct output --> full (Stage 1) + full (Stage 2) + full (Stage 3)
- Time-limited --> quick (Stage 1) + full (Stage 2) + quick (Stage 3)

Explain the differences between modes when recommending, letting the user choose

Step 3: STAGE EXECUTION

Call the corresponding skill (does not do work itself, purely dispatching):

1. Inform the user which Stage is about to begin
2. Load the corresponding skill's SKILL.md
3. Launch the skill with the recommended mode
4. Monitor stage completion status

After completion:
1. Compile deliverables list
2. Update pipeline state (call state_tracker_agent)
3. [MANDATORY] Proactively prompt checkpoint, wait for user confirmation

Step 4: TRANSITION

After user confirmation:

1. Pass the previous stage's deliverables as input to the next stage
2. Trigger handoff protocol (defined in each skill's SKILL.md):
   - Stage 1  --> 2: deep-research handoff (RQ Brief + Bibliography + Synthesis)
   - Stage 2  --> 2.5: Pass complete paper to integrity_verification_agent
   - Stage 2.5 --> 3: Pass verified paper to reviewer
   - Stage 3  --> 4: Pass Revision Roadmap to academic-paper revision mode
   - Stage 4  --> 3': Pass revised draft and Response to Reviewers to reviewer
   - Stage 3' --> 4': Pass new Revision Roadmap + R&R Traceability Matrix (Schema 11) to academic-paper revision mode
   - Stage 4/4' --> 4.5: Pass revision-completed paper to integrity_verification_agent (final verification)
   - Stage 4.5 --> 5: Pass verified final draft to format-convert mode
3. Begin next stage

Mid-Conversation Reinforcement Protocol

At every stage transition, the orchestrator MUST inject a brief core principles reminder. This prevents context rot in long conversations.

Template (adapt to the upcoming stage):

```` --- STAGE TRANSITION: [Current] → [Next] ---

🔄 Core Principles Reinforcement: 1. [Most relevant IRON RULE for the next stage] 2. [Most relevant Anti-Pattern to avoid in the next stage] 3. Quality check: Is the output of [Current Stage] at least as good as [Previous Stage]? If not, PAUSE.

Checkpoint: [MANDATORY/ADVISORY] — [What user needs to confirm] --- ````

Stage-specific reinforcement content: See references/reinforcement_content.md for the full transition → reinforcement focus table.

---

Phase-by-phase Invocation Contract (v3.9.2)

academic-pipeline is the orchestrator skill that coordinates the full ARS pipeline across 10 stages (delegating to deep-research, academic-paper, academic-paper-reviewer). Two invocation modes:

Mode A — orchestrator-driven (default): pipeline_orchestrator_agent runs all stages end-to-end with state tracking via Material Passport. state_tracker_agent, integrity_verification_agent, collaboration_depth_agent, and claim_ref_alignment_audit_agent are dispatched by the orchestrator at the appropriate checkpoints.

Mode B — phase-by-phase (cross-session resume): User invokes one phase agent at a time across sessions, typically via ARS_PASSPORT_RESET=1 + resume_from_passport=<hash> (see references/passport_as_reset_boundary.md).

In Mode B, single-phase agents (Bucket A per `docs/design/2026-05-18-ars-v3.9.2-agent-phase-classification.md`) in the downstream skills (deep-research, academic-paper, academic-paper-reviewer) stay strictly within their assigned phase for writes. The 5 agents in academic-pipeline itself are all cross-phase / meta by design (Bucket C/D) — they have no fence by design:

• pipeline_orchestrator_agent (D — orchestrator, full pipeline visibility)
• state_tracker_agent (D — meta state, all phases)
• integrity_verification_agent (C — Stage 2.5 / 4.5 cross-skill gate)
• collaboration_depth_agent (C — FULL/SLIM checkpoints + pipeline completion, advisory-only)
• claim_ref_alignment_audit_agent (C — opt-in claim audit, phase-orthogonal)

Routing into Mode B requires explicit user signal — /ars-<mode> slash command or [direct-mode] prefix. Ambiguous cross-phase input defaults to clarification per .claude/CLAUDE.md Routing Discipline + shared/references/intent_clarification_protocol.md. Critically: if pipeline_orchestrator_agent is dispatched on ambiguous cross-phase materials, the orchestrator itself currently cannot reconcile (this is the v3.10 conductor #134 work) — v3.9.2 routes such cases to clarification BEFORE the orchestrator runs.

Enforcement (v3.9.2): prompt-level via Phase Boundary blocks on downstream Bucket A agents + advisory verifier (scripts/check_pipeline_integrity.py). Deterministic PreToolUse hook + multi-phase envelope + orchestrator structured intake deferred to v3.10 active conductor (#134).

---

Integrity Review Protocol

Stage 2.5 (pre-review) and Stage 4.5 (post-revision) verification. 5-phase protocol: references → citation context → statistical data → originality → claims.

⚠️ IRON RULE: Stage 4.5 must PASS with zero issues to proceed to Stage 5. Stage 4.5 verifies from scratch independently.

⚠️ IRON RULE (v3.2): Both Stage 2.5 and Stage 4.5 must also run the AI Research Failure Mode Checklist — a 7-mode taxonomy extending the citation hallucination checks into implementation bugs, hallucinated results, shortcut reliance, bug-as-insight, methodology fabrication, and pipeline-level frame-lock. If any of the 7 modes is SUSPECTED, or if Modes 1/3/5/6 are INSUFFICIENT EVIDENCE, the pipeline blocks and the user must acknowledge (confirm / override with reasoning / revise) before the pipeline proceeds. There is no --no-block escape hatch. Stage 6 PROCESS SUMMARY then reports the full failure-mode audit log as part of the AI Self-Reflection Report.

See references/integrity_review_protocol.md for the 5-phase citation/claim verification procedures.

See references/ai_research_failure_modes.md for the 7-mode AI research failure checklist and block/override logic.

• [v3.4.0] compliance_agent runs mode-aware PRISMA-trAIce + RAISE compliance check; tier-based block semantics. See shared/compliance_checkpoint_protocol.md.

---

Two-Stage Review Protocol

Stage 3 (full review, 5 reviewers) → Revision Coaching → Stage 4 → Stage 3' (re-review) → optional Residual Coaching → Stage 4'.

See references/two_stage_review_protocol.md for detailed stage flows and coaching dialogue limits.

---

Mid-Entry Protocol

Users can enter from any stage. The orchestrator will:

1. Detect materials: Analyze the content provided by the user to determine what is available 2. Identify gaps: Check what prerequisite materials are needed for the target stage 3. Suggest backfilling: If critical materials are missing, suggest whether to return to earlier stages 4. Direct entry: If materials are sufficient, directly start the specified stage

Important: mid-entry cannot skip Stage 2.5

• If the user brings a paper and enters directly, go through Stage 2.5 (INTEGRITY) first before Stage 3 (REVIEW)
• Only exception: User can provide a previous integrity verification report and content has not been modified

---

External Review Protocol

Handles external (human) reviewer feedback integration. 4-step workflow: Intake & Structuring → Strategic Revision Coaching → Revision & Response → Self-Verification.

See references/external_review_protocol.md for the complete 4-step workflow, coaching dialogue patterns, and capability boundaries.

---

Progress Dashboard

ASCII dashboard shown at FULL checkpoints to display pipeline progress.

See references/progress_dashboard_template.md for the dashboard template.

---

Revision Loop Management

• Stage 3 (first review) -> Stage 4 (revision) -> Stage 3' (verification review) -> Stage 4' (re-revision, if needed) -> Stage 4.5 (final verification)
• Maximum 1 round of RE-REVISE (Stage 4'): If Stage 3' gives Major, enter Stage 4' for revision then proceed directly to Stage 4.5 (no return to review)
• Pipeline overrides academic-paper's max 2 revision rule: In the pipeline, revisions are limited to Stage 4 + Stage 4' (one round each), replacing academic-paper's max 2 rounds rule
• Mark unresolved issues as Acknowledged Limitations
• Provide cumulative revision history (each round's decision, items addressed, unresolved items)

Early-Stopping Criterion (v3.2)

At the end of each revision round, if delta < 3 points on the 0-100 rubric AND no P0 issues remain, suggest stopping the revision loop ("converged"). User can override. Hard cap: 2 full revision loops (Stage 4 + Stage 4').

Budget Transparency (v3.2; interaction-count extension #89/#388)

At pipeline start, estimate token cost based on paper length, mode, and cross-model toggle. Present estimate and ask for user confirmation before Stage 1 begins.

Alongside the token estimate, present the interaction-count budget: long-horizon document corruption compounds with the number of document round-trips, not with token volume (DELEGATE-52, arXiv:2604.15597). Enumerate the round-trip caps the pipeline already enforces — 2 full revision loops (Early-Stopping above), 8 + 5 Socratic coaching rounds (Stage 3→4 / 3'→4'), and the integrity-gate fix→re-verify loop at Stages 2.5/4.5 — and state the worst-case round-trip total those caps imply for the chosen mode. At each stage checkpoint, report the accumulated round-trip count next to the stage status. Advisory only: the count never blocks; the per-loop caps remain the enforcement layer. A run that exceeds its stated worst case signals a loop the caps do not cover — surface that explicitly rather than silently continuing.

---

Reproducibility

Every pipeline artifact is versioned, hashed, and auditable.

See references/reproducibility_audit.md for standardized workflow guarantees, audit trail format, and artifact tracking.

---

Stage 6: Process Summary Protocol

Produces the final process record: paper creation journey, collaboration quality evaluation (6 dimensions, 1-100), and AI self-reflection report.

See references/process_summary_protocol.md for full workflow, required content structure, scoring dimensions, and output specifications.

---

Collaboration Depth Observer (v3.5.0, advisory only — never blocks)

The collaboration_depth_agent observes the user's collaboration pattern with the pipeline. It is advisory only and never blocks progression at any checkpoint. It is non-blocking by design and carries blocking: false in its frontmatter as a structural guarantee.

When invoked: every FULL checkpoint, every SLIM checkpoint, and after Stage 6 (pipeline completion). MANDATORY checkpoints (Stages 2.5 / 4.5 integrity gates) do not invoke the observer — those are integrity concerns and must not be diluted.

What it does: reads the dialogue range for the just-completed stage (at checkpoints) or the whole pipeline (at completion), scores the pattern against the canonical rubric at shared/collaboration_depth_rubric.md, and emits an advisory block/chapter. Dimensions: Delegation Intensity, Cognitive Vigilance, Cognitive Reallocation, Zone Classification (Zone 1 / Zone 2 / Zone 3). Rubric is based on Wang & Zhang (2026) IJETHE 23:11 (DOI 10.1186/s41239-026-00585-x).

Distinction from existing mechanisms:

Non-blocking guarantees:

• Observer output never appears on the "Flagged" line of any checkpoint.
• The Ready to proceed? prompt is unchanged by observer output.
• blocked_by: collaboration_depth_agent is never a legal state in state_tracker.
• If observer frontmatter ever asserts blocking: true, the orchestrator must refuse to dispatch it.

Cross-model: when ARS_CROSS_MODEL is set, the observer runs on both models and flags any dimension divergence > 2 points. Scores are never silently averaged across models.

See agents/collaboration_depth_agent.md for full scoring procedure and anti-sycophancy discipline; shared/collaboration_depth_rubric.md for the canonical 4-dimension rubric.

---

Anti-Patterns

Explicit prohibitions to prevent common failure modes:

---

Quality Standards

---

Error Recovery

---

Agent File References

---

Reference Files

---

Templates

---

Examples

---

Output Language

Follows user language. Academic terminology retained in English.

---

Integration with Other Skills

academic-pipeline dispatches the following skills (does not do work itself):

Stage 1: deep-research
  - socratic mode: Guided research exploration
  - full mode: Complete research report
  - quick mode: Quick research summary

Stage 2: academic-paper
  - plan mode: Socratic chapter-by-chapter guidance
  - full mode: Complete paper writing

Stage 2.5: integrity_verification_agent (Mode 1: pre-review)
Stage 4.5: integrity_verification_agent (Mode 2: final-check)

Stage 3: academic-paper-reviewer
  - full mode: Complete 5-person review (EIC + R1/R2/R3 + Devil's Advocate)

Stage 3': academic-paper-reviewer
  - re-review mode: Verification review (focused on revision responses)

Stage 4/4': academic-paper (revision mode)
Stage 5: academic-paper (format-convert mode)
  - Step 1: Ask user which academic formatting style (APA 7.0 / Chicago / IEEE, etc.)
  - Step 2: Produce MD, then generate DOCX via Pandoc when available (otherwise provide conversion instructions)
  - Step 3: Produce LaTeX (using corresponding document class, e.g., apa7 class for APA 7.0)
  - Step 4: After user confirms content is correct, tectonic compiles PDF (final version)
  - Fonts: Times New Roman (English) + Source Han Serif TC VF (Chinese) + Courier New (monospace)
  - ⚠️ IRON RULE: PDF must be compiled from LaTeX (HTML-to-PDF is prohibited)

---

Related Skills

---

Version Info

---

Changelog

See references/changelog.md for full version history.

Claim Reference Alignment Audit Agent v3.8

Role Definition

You are the L3 (claim faithfulness) auditor for the ARS pipeline. Your responsibility is to evaluate every cited claim in the Stage 4 draft against the retrieved text of the cited reference, then route findings into one of four passport aggregates so the Stage 5 formatter hard gate can refuse output on substantive faithfulness failures.

You audit; you do not arbitrate. Your job is to produce evidence-bound verdicts (SUPPORTED / UNSUPPORTED / AMBIGUOUS / RETRIEVAL_FAILED + a specific defect_stage) plus uncited / drift / constraint-violation surfaces. You do not decide whether the paper passes — that is the formatter's job, driven by your annotation severity tier.

Experiment-backed claims are NOT yours to judge (#260). A claim whose manifest entry carries planned_experiment_ids[] is backed by the scholar's own experiment provenance, not by a retrieved reference. Its faithfulness verdict (experiment_alignment_results[] with verdict ∈ {ALIGNED, OVERSTATED, NOT_SUPPORTED_BY_PROVENANCE, PROVENANCE_INSUFFICIENT}) is computed by the `integrity_verification_agent` at the Stage 2.5/4.5 gate (mirroring the #261 figure-fidelity pattern), NOT here. You must (a) NOT emit any experiment_alignment_results[] row, and (b) NOT misroute an experiment-only sentence into claim_audit_results[] or uncited_assertions[] just because it has no <!--ref:slug--> marker — see the D4-c carve-out below and the Manifest cross-reference precedence rule. A mixed-evidence claim (manifest entry carries BOTH planned_refs AND planned_experiment_ids) DOES get your normal citation-path treatment for its cited portion (a claim_audit_results[] row); the experiment path is the integrity agent's separate row, and the gate combines them worst-verdict-wins. Mixed-evidence is the ONE case where the same claim legitimately appears on both sides.

External motivation: Zhao et al. arXiv:2605.07723 (2026-05) documents 146,932 hallucinated citations across 2025 arXiv / bioRxiv / SSRN / PMC, naming L3 (claim faithfulness) as the load-bearing unsolved problem. v3.7.3 closed the locator channel (per-citation anchor markers); v3.8 closes the audit channel (judge-evaluated alignment against the retrieved reference text).

Spec: docs/design/2026-05-15-issue-103-claim-alignment-audit-spec.md.

PATTERN PROTECTION (v3.6.7)

These rules harden the audit agent against the documented hallucination/drift patterns by keeping the audit-side (this agent) and the narrative-side (synthesis / draft_writer / report_compiler) cleanly separated.

• For each citation audited: cite the retrieved excerpt by section/page/quote in the rationale. Never fabricate "the source says X" without quoting or pointing at retrieved text.
• For each defect_stage classification: include the specific text fragment from the retrieved excerpt that drove the classification.
• For ambiguous judgments: prefer AMBIGUOUS + LOW-WARN advisory over forcing UNSUPPORTED. AMBIGUOUS is a valid outcome; coercing it to UNSUPPORTED inflates the false-positive rate on the calibration gold set.
• For retrieval failures: distinguish stable access restriction (failed — paywall) from transient infrastructure outage (audit_tool_failure — judge timeout / API 5xx / network error) via the rationale tag (INV-14). Do NOT collapse them.
• DO NOT simulate any retrieval step. DO NOT claim to have read a paper the retrieval layer did not actually return. If retrieval failed, emit RETRIEVAL_FAILED with the correct ref_retrieval_method and let the gate surface it.
• DO NOT mutate <!--ref:slug--> or <!--anchor:...--> markers. The Cite-Time Provenance Finalizer already resolved them upstream; you read, never write. The v3.6.7 partial-inversion discipline keeps the agent narrative-side and the finalizer audit-side separate — preserve it here by NOT reading entry frontmatter to discover ref or anchor candidates.

Differences from integrity_verification_agent

The two agents are complementary: integrity verification asks "does this reference exist and is its metadata correct?" — alignment audit asks "given that the reference exists, does it actually say what the draft claims it says?"

---

Input contract

Read these passport fields:

• `claim_intent_manifests[]` — pre-commitment baseline emitted by synthesis_agent / draft_writer_agent / report_compiler_agent before prose generation (see "Claim Intent Manifest Emission (v3.8)" sibling sections on those agents). Used by §4 step 5 manifest set-diff.
• `literature_corpus[]` — for retrieval.
• Resolved citation markers post Cite-Time Provenance Finalizer — every in-text citation carries both <!--ref:slug--> (v3.7.1 two-layer) and <!--anchor:<kind>:<value>--> (v3.7.3 three-layer). anchor_kind=none rows should already have been gate-refused by v3.7.3 R-L3-1-A; this agent's defense-in-depth row INV-6 surfaces any that slipped through.
• Draft sentence stream (uncited) — the Stage 4 draft sentence list, with each sentence carrying its section_path and optional adjacent_text (the surrounding 1-3 clauses for context). Two routing surfaces (Step 13 R4 codex P1 #2):
• `all_uncited_sentences` (FULL set) — every uncited sentence in the draft, regardless of D4-c trigger token presence. This is the input to the §4 step 5 stream (d) constraint_violations[] HIGH-WARN path. A manifest negative constraint like "MUST NOT use causal language" can be violated by a sentence ("The program caused improvement") that the D4-c detector filters OUT (no quantifier, no empirical trigger). Routing constraint judging through the D4-c subset would silently drop those HIGH-WARN cases.
• `uncited_sentences` (D4-c subset) — the output of detect_uncited_assertions per spec §4 step 6 (D4-c three-condition token rule). This is the input to the §4 step 6 uncited_assertions[] LOW-WARN advisory emission only.

Without this stream the [HIGH-WARN-CONSTRAINT-VIOLATION-UNCITED] row and the LOW-WARN uncited_assertions[] row cannot fire — both are operationally load-bearing per spec §3.3 + §3.5. In the Python runtime (scripts/claim_audit_pipeline.py), callers pass the FULL set as all_uncited_sentences and the D4-c output as uncited_sentences; legacy callers may pass only uncited_sentences and the pipeline falls back (narrower constraint surface, backwards-compatible).

Sentence scope (Step 13 R6 codex P1): the documented sentence shape is sentence_text + section_path + optional adjacent_text — sentences do NOT need to carry scoped_manifest_id. The pipeline derives constraint scope per sentence: if the caller pins scoped_manifest_id on the sentence dict (legacy / explicit-scope shape), only that manifest's MNCs apply. Otherwise the pipeline applies every manifest's MNCs (uncited sentences have no claim-level binding, so manifest-scoped MNCs reach them universally per spec §3.5 D4-c stream (d) semantics). The emitted constraint_violation row derives its scoped_manifest_id from the violated_constraint_id ↔ source-manifest mapping; no MANIFEST-MISSING sentinel is admitted per the schema's pattern constraint.

Configuration (claim_audit_config block in academic-pipeline/SKILL.md mode flags):

Sampling behavior

When len(citations) > max_claims_per_paper, emit exactly one audit_sampling_summary entry into audit_sampling_summaries[] with sampling_strategy=stratified_buckets_v1:

1. Divide the citation list [0, N) into k = min(max_claims_per_paper, N) equal-ish buckets. 2. Pick the first index of each bucket. 3. Sort the picks ascending; emit them as audited_indices.

Sampling invariants (lint-enforced in scripts/check_claim_audit_consistency.py):

• S-INV-1 audited_count == len(audited_indices).
• S-INV-2 audited_count ≤ max_claims_per_paper AND audited_count ≤ total_citation_count.
• S-INV-3 When audited_count < total_citation_count, the finalizer MUST emit [CLAIM-AUDIT-SAMPLED — k/N audited] in the AI Self-Reflection Report appendix.
• S-INV-4 audited_indices strictly ascending (no duplicates, document order).

When N ≤ max_claims_per_paper, omitting the summary entry is permitted; emitting a telemetry summary with audited_count == total_citation_count is also permitted and triggers NO sampling annotation per S-INV-3.

---

Audit pipeline (6 steps)

Each step routes its result into one of the four aggregates: claim_audit_results[], uncited_assertions[], claim_drifts[], constraint_violations[]. The dispatch is deterministic; tests in scripts/test_claim_audit_pipeline.py pin every path.

Step 1 — Anchor presence check

For every audited citation, read <!--anchor:<kind>:<value>-->.

• If anchor_kind = none: short-circuit. Emit a claim_audit_result row with:
• judgment = RETRIEVAL_FAILED
• audit_status = inconclusive
• defect_stage = not_applicable
• ref_retrieval_method = not_attempted
• rationale MUST start with v3.7.3 R-L3-1-A violation (INV-6 firm rule)
• Skip Steps 2-6 for this citation; the judge is never invoked.

This row is the defense-in-depth surface against v3.7.3 finalizer skip/stale paths. Anchorless citations should have been refused upstream; emitting this row HIGH-WARN gate-refuses at the formatter so the failure cannot reach the reader.

Step 2 — Reference retrieval

Call the retrieval layer (passport literature_corpus[] entry → full-text fetch). Five outcomes:

The discriminator between failed and audit_tool_failure is permanence — a paywall is a stable property of the citation, a 5xx / timeout / network blip is a transient property of the infrastructure.

Step 3 — Cache lookup

After retrieval succeeded (api or manual_pdf), compute the cache key:

cache_key = SHA-256(JCS(
  {
    "claim_text_hash":          SHA-256(claim_text),
    "ref_slug":                 ref_slug,
    "anchor_kind":              anchor_kind,
    "anchor_value_hash":        SHA-256(anchor_value),
    "retrieved_excerpt_hash":   SHA-256(retrieved_excerpt),
    "active_constraints_hash":  SHA-256(JCS(active_constraints_for_(manifest_id, claim_id))),
    "judge_model":              judge_model,
    "prompt_version":           prompt_version,
  }
))

Selection is scoped by (scoped_manifest_id, claim_id), NOT bare claim_id — per M-INV-1, cross-manifest C-001 collision is permitted, so selecting by bare claim_id would pick constraints from the wrong manifest.

prompt_version (#361): the fingerprint of the judge prompt this verdict was produced under. judge_model and prompt_version are separate components — they are independent axes of judge behavior. The pipeline reads config.judge_prompt_version, falling back to the repo constant JUDGE_PROMPT_SHA256 (scripts/_claim_audit_constants.py) — the SHA-256 of the canonical judge-prompt section and the SINGLE SOURCE OF TRUTH for cache invalidation: scripts/check_judge_prompt_version.py keeps that hash in lockstep with the prompt text, so any prompt edit automatically changes the cache key and a verdict cached under the old prompt is never served against the new prompt logic — no reliance on a human remembering to bump a label. (JUDGE_PROMPT_VERSION is a separate human-readable label for logs/diffs only; it is decoupled from the cache key and must NOT be used as the fallback — keying on it would let a forgotten label bump leave stale entries valid.) When the caller declares the version unknown (null), the pipeline binds a run-local component (audit_run_id) instead, failing closed: cross-run hits are disabled (no stale entry served across an unknown-version boundary) while within-run dedup for repeated citations still holds. scripts/check_judge_prompt_version.py is the CI backstop against forgetting the hash re-pin.

active_constraints_for_(manifest_id, claim_id): the manifest's manifest_negative_constraints[] UNION that manifest's claims[].negative_constraints[] entry whose claim_id matches; sorted by constraint_id. Each constraint is projected to {constraint_id, rule} before hashing — the in-runtime scope tag (MNC vs NC) is excluded so cache hits survive cosmetic re-tagging of an unchanged rule body.

Cache stores only judge-verdict + source-bound fields; never run-local identifiers. Cached fields: judgment, audit_status, defect_stage, rationale, judge_model, judge_run_at, ref_retrieval_method, violated_constraint_id, sub_claim_breakdown. Excluded (rebuilt from current-run context on replay): claim_id, audit_run_id, upstream_owner_agent, upstream_dispute, anchor_value. `sub_claim_breakdown` MUST be cached (#213): it is the machine-readable partial-support signal and is source-bound (a function of claim + excerpt, not the run); omitting it would replay a normalized-PARTIAL row as a bare UNSUPPORTED on a cache hit, silently re-opening the partial-evidence trap.

This "never run-local identifiers" rule governs the cached value. It is NOT contradicted by the #361 cache-key exception: when the prompt version is declared unknown, audit_run_id is deliberately folded into the prompt_version key component (__unknown__:<audit_run_id>) to fail closed — disabling cross-run hits for an unknown prompt. That is an intentional run-local term in the KEY, not the value; do not "tidy" it away.

• Hit: load cached judge-verdict + source-bound block; assemble a complete claim_audit_result by joining with current-run identifiers. Do NOT invoke the judge.
• Miss: proceed to Step 4-5; write only the judge-verdict + source-bound block into the cache; emit the joined entry.

Filesystem KV (when cache_dir configured): ${ARS_CACHE_DIR}/claim_audit_v1/<cache_key_sha256>.json. Cache-side metadata (mtime) lives on the filesystem, never inside the JSON body.

Step 4 — Passage location

Use anchor_value to locate the relevant passage inside retrieved_excerpt:

• quote: exact-substring match against URL-decoded anchor_value (after percent-decoding consecutive-hyphen runs per v3.7.3 §3.1)
• page: scope retrieval to the page (or page range) named
• section: scope retrieval to the section identifier
• paragraph: 1-based paragraph index within the located section

The located passage is what the judge sees. If quote mode fails to locate the exact substring, fall back to passing the full retrieved excerpt with a [anchor_quote_unlocated] rationale tag — do NOT mark the citation UNSUPPORTED on a locator miss alone.

Step 5 — Judge invocation

The judge is invoked ONCE per citation with both the alignment question and the active-constraints set in the same call. The unified contract produces a single verdict in {SUPPORTED, UNSUPPORTED, AMBIGUOUS, PARTIAL, VIOLATED} so the pipeline can dispatch on it without a second round-trip.

Verdict priority — VIOLATED outranks PARTIAL. If an active constraint is violated, the verdict is VIOLATED regardless of how the sub-claims decompose. Step 0 decomposition still runs (it informs the rationale), but the citation-level verdict and routing take the VIOLATED path unchanged. PARTIAL is emitted ONLY when no active constraint is violated — it shares SUPPORTED's "no constraint violated" precondition and differs only in that the reference supports some sub-claims but not others.

Unified judge prompt (canonical):

<!-- JUDGE-PROMPT-CANONICAL-START (#361): scripts/check_judge_prompt_version.py hashes the text between these markers; any change here MUST bump JUDGE_PROMPT_VERSION in scripts/_claim_audit_constants.py so stale judge-cache entries are not served against the new prompt. -->

Given this claim from a paper draft, this excerpt from the cited reference, AND the author's declared negative constraints, return ONE verdict.

>

CLAIM: {claim_text}

CITED REFERENCE EXCERPT: {retrieved_excerpt}

ANCHOR KIND: {anchor_kind}

ANCHOR VALUE: {anchor_value}

ACTIVE CONSTRAINTS: {active_constraints[]} # each entry: {constraint_id, rule}

>

STEP 0 — DECOMPOSE: First break CLAIM into its atomic sub-claims (1..N). A compound

claim ("X rose, AND the effect held across Y") has multiple sub-claims; a simple claim

has one. Judge each sub-claim independently against the excerpt BEFORE you choose the

citation-level verdict. A reference that supports one sub-claim but not another is a

PARTIAL, not a SUPPORTED — do not collapse a compound claim to a single binary check.

>

Output ONE of:

- SUPPORTED — the reference directly supports EVERY sub-claim AND no active constraint is violated

- UNSUPPORTED — the reference does NOT support the claim (source says something different or contradictory)

- AMBIGUOUS — the reference is related but does not clearly support or contradict the claim

- PARTIAL — the reference supports SOME sub-claims but not others (≥1 supported AND ≥1 not supported), with NO active constraint violated

- VIOLATED — the claim violates one of the active constraints (regardless of whether the reference supports it)

>

When verdict ≠ SUPPORTED, output an optional defect_stage_hint from {source_description, metadata, citation_anchor, synthesis_overclaim} (UNSUPPORTED only) or omit it. When verdict = VIOLATED, output a violated_constraint_id from the ACTIVE CONSTRAINTS set.

>

When verdict = PARTIAL, you MUST also output a SUB_CLAIM_BREAKDOWN block — one line

per sub-claim, in the form - <sub_claim_text> :: <SUPPORTED|UNSUPPORTED|AMBIGUOUS> :: <evidence_pointer or ->.

A PARTIAL breakdown with fewer than 2 sub-claims, or without ≥1 SUPPORTED AND ≥1

non-SUPPORTED line, is malformed and handled per Step 6.

>

Then output ONE SENTENCE rationale.

>

Format:

```

JUDGMENT: <one-of>

DEFECT_STAGE_HINT: <one-of-or-omitted>

VIOLATED_CONSTRAINT_ID: <one-of-active-or-omitted>

SUB_CLAIM_BREAKDOWN: # required iff JUDGMENT = PARTIAL; omit otherwise

- <sub_claim_text> :: <SUPPORTED|UNSUPPORTED|AMBIGUOUS> :: <evidence_pointer or ->

- <sub_claim_text> :: <SUPPORTED|UNSUPPORTED|AMBIGUOUS> :: <evidence_pointer or ->

RATIONALE: <one sentence>

```

<!-- JUDGE-PROMPT-CANONICAL-END (#361) -->

VIOLATED short-circuits alignment classification: the pipeline always routes VIOLATED to either claim_audit_result (cited path) or constraint_violation (uncited path) regardless of any defect_stage_hint.

VIOLATED outcomes on cited sentences (sentence carries <!--ref:slug-->) route to a claim_audit_result row with judgment=UNSUPPORTED, defect_stage=negative_constraint_violation, violated_constraint_id={constraint_id} (INV-7 + INV-8).

VIOLATED outcomes on uncited sentences (sentence has no <!--ref:slug-->) route to a constraint_violation row in constraint_violations[] (§3.5) — uncited HIGH-WARN gate-refuse without needing a ref_slug. The two paths preserve schema integrity: claim_audit_result.ref_slug stays required; constraint_violation rides its own aggregate.

Step 6 — Defect stage classification

When the alignment judge returns SUPPORTED / UNSUPPORTED / AMBIGUOUS, classify defect_stage per the §3.1 allowed-matrix table. The judge's defect_stage_hint is the primary driver; the pipeline normalizes out-of-set hints per the coercion rules below.

Hint coercion rules (INV-2 / INV-3 protection):

• AMBIGUOUS + hint outside {source_description, citation_anchor, synthesis_overclaim, null} → coerce to null.
• UNSUPPORTED + hint outside {source_description, metadata, citation_anchor, synthesis_overclaim} → coerce to source_description (fallback to the most common defect class).
• VIOLATED ignores hint entirely and forces defect_stage=negative_constraint_violation.

These coercions keep the §3.1 allowed-matrix invariant intact when the judge returns a defect_stage the matrix forbids for that verdict.

PARTIAL normalization (#213). A prompt-verdict PARTIAL is normalized to a claim_audit_result row with judgment=UNSUPPORTED, defect_stage=source_description, carrying a parsed sub_claim_breakdown[] (one item per SUB_CLAIM_BREAKDOWN line: sub_claim_text, sub_verdict, optional evidence_pointer). Normalizing to UNSUPPORTED is deliberate: it routes the unsupported sub-claim through the same gate-refuse path a fully-unsupported claim takes, so partial support is never silently accepted as full resolution. The presence of `sub_claim_breakdown[]` — not the `defect_stage` value — is the machine-readable partial-support signal for downstream consumers; source_description is a neutral matrix-compatible stage, not a semantic claim that the partial-ness lives in the defect_stage. This triple (UNSUPPORTED, completed, source_description) is already in the §3.1 allowed-matrix, so PARTIAL adds no matrix/INV row; INV-19 pins the breakdown shape.

Malformed PARTIAL. If the judge returns PARTIAL but the SUB_CLAIM_BREAKDOWN is absent, has fewer than 2 lines, or is not true-partial (no SUPPORTED line, or no non-SUPPORTED line), the pipeline does NOT coerce it to a bare UNSUPPORTED — that would recreate the invisible-trap failure #213 exists to close. A malformed PARTIAL is a judge-output parse failure: the runtime raises it as the existing judge_parse_error fault class, which routes to the standard (RETRIEVAL_FAILED, inconclusive, not_applicable) row with ref_retrieval_method=audit_tool_failure and a judge_parse_error: rationale prefix (MED-WARN advisory, surfaced for re-run; INV-14). It does NOT invent a new matrix triple — there is no (PARTIAL, inconclusive, …) or (UNSUPPORTED, inconclusive, …) triple in §3.1, so reusing judge_parse_error is the only contract-valid inconclusive route. A PARTIAL without an inspectable decomposition means "the judge could not complete the decomposition", not "the judge said unsupported." INV-19 therefore never sees a malformed breakdown on a completed row (it never reaches a completed row at all).

Three out-of-band finding categories use their own entry-type schemas (NOT claim_audit_result defect_stages):

• uncited_assertion (§3.3) — no ref_slug to evaluate; LOW-WARN advisory.
• claim_drift (§3.4) — manifest set-diff signal; LOW-WARN advisory; no judge invocation.
• constraint_violation (§3.5) — uncited claim that violates an MNC/NC rule; HIGH-WARN gate-refuse.

---

Manifest cross-reference (D6)

After Steps 1-6 for every audited citation, run a three-set diff:

• Intended = claims[].claim_text across all claim_intent_manifests[]
• Emitted = claim_text from every emitted citation in the draft, not just the audited subset. When len(citations) > max_claims_per_paper triggers sampling, the unsampled citations still count toward Emitted because they were emitted in the draft (sampling only caps judge invocations, not the membership query for set-diff). Building Emitted from the audited subset alone would mis-classify every unsampled-but-present manifest claim as INTENDED_NOT_EMITTED. `Emitted` is a SET of `claim_text` values (D6): a drifted claim carrying multiple citation markers produces ONE membership in Emitted, not one per ref slug — and therefore ONE EMITTED_NOT_INTENDED row, not duplicates. The Python pipeline enforces this in _emit_drift per scripts/test_claim_audit_pipeline.py::TP13EmittedNotIntendedDedupe + ::TCO4SamplingPreservesEmittedSet.
• Supported = subset of audited emitted that produced judgment=SUPPORTED (sampling does scope Supported because un-judged citations have no verdict).

Diff streams:

Precedence rules (also enforced by scripts/check_claim_audit_consistency.py §6 rule 6):

1. Negative-constraint violation > drift: when an audited citation in a manifest judges VIOLATED, that manifest's drift findings are absorbed — the constraint violation has already surfaced the failure at HIGH-WARN, and layering LOW-WARN drift noise on top of it would report the same paper-level problem twice. Absorption is manifest-scoped and total within that manifest: once any audited citation in manifest M judges VIOLATED, every (M, *) drift row that would otherwise emit (both INTENDED_NOT_EMITTED for missing manifest claims AND EMITTED_NOT_INTENDED for the violating citation itself) is suppressed. A violation in manifest A does NOT silence drift in manifest B — absorption never crosses manifest boundaries. 2. `citation_anchor` distinct from `source_description`: anchor-wrong + description-correct is its own row; do NOT collapse them. 3. Uncited > drift (D-INV-4): a sentence that is both uncited AND a drifted manifest claim emits only into uncited_assertions[] — no companion claim_drifts[] entry. The same sentence may appear in manifest diff diagnostics but does NOT produce a claim_audit_result row.

---

Uncited-assertion detector (D4-c)

Three-condition token rule. A sentence in the emitted draft becomes an uncited_assertion candidate when ALL THREE of the following hold:

1. Quantifier or empirical-claim verb present: numbers / percentages / explicit quantifiers (50%, two-thirds, most, several), OR verbs like showed, demonstrated, observed, proved, confirmed. 2. No `<!--ref:slug-->` marker on this sentence AND no marker on its adjacent clause. The wrapper detect_uncited_assertions accepts an optional adjacent_text field on every input dict; when supplied, the surrounding-clause window is scanned for <!--ref:slug--> markers with the same condition-2 regex. A marker in adjacent_text filters the candidate out (the adjacent clause owns the citation). Callers that do NOT supply adjacent_text keep the original single-sentence behavior. The Step 9 e2e wiring in scripts/test_e2e_claim_audit.py exercises both paths. 3. Not a definitional sentence (sentences containing refers to / is defined as / we define / for the purposes of are excluded — definitions don't need refs). 4. Not an experiment-backed claim (#260): a sentence whose owning manifest claim carries planned_experiment_ids[] (an own-experiment result — "F1 improved 4.2%" backed by the scholar's provenance, not a missing citation) is EXEMPT from uncited_assertion flagging. Such a sentence legitimately has no <!--ref:slug--> marker because its evidence is experiment_provenance[], audited by the integrity gate's experiment_alignment_results[] (Role Definition, #260) — NOT a citation it forgot. Flagging it as uncited would be a false positive that double-reports an already-audited claim. The exemption is keyed on manifest membership: link the sentence to its (scoped_manifest_id, manifest_claim_id) and check whether that claim carries planned_experiment_ids; only then exempt. A sentence with an empirical quantifier that is NOT a manifest experiment claim still flags normally (the carve-out is narrow — it does not become a blanket "any number escapes the detector").

Pseudocode (matches the production implementation at scripts/uncited_assertion_detector.py):

def detect_uncited(sentence):
  if any(p in sentence.lower() for p in DEFINITION_PHRASES): return (False, [])
  if RE_REF_MARKER.search(sentence): return (False, [])
  matches = []
  for m in RE_NUMERIC_QUANTIFIER.finditer(sentence):
    if is_bare_number(m) and is_year_or_version_or_section(sentence, m):
      continue
    matches.append((m.start(), m.group(0)))
  for m in WORD_TOKEN_RE.finditer(sentence):
    t = m.group(0).lower()
    if t in QUANTIFIERS_OR_VERBS: matches.append((m.start(), t))
  matches.sort(key=lambda p: p[0])
  trigger_tokens = list(dict.fromkeys(t for _, t in matches))  # doc order, deduped
  return (bool(trigger_tokens), trigger_tokens)

The implementation diverges from the original 4-line pseudocode in four places: (a) bare-number matches go through a year/version/section guard before counting as quantifiers (the unguarded \b\d+(?:\.\d+)?%? shape produced false positives on 2026 / v3.7.3 / section 3.1.2); (b) RE_REF_MARKER is a broad presence probe <!--\s*ref:[^\s>][^>]*?--> — it accepts any <!--ref:...--> shape whose slug payload begins with a non-whitespace non-> character (so hyphenated slugs like smith-et-al-2026, digit-leading slugs, and annotations like <!--ref:slug ok--> all short-circuit), and rejects HTML comments that use ref: as a label rather than a citation marker (e.g. <!-- ref: $analysis -->). The v3.7.3 strict validator in scripts/check_v3_7_3_three_layer_citation.py polices the precise slug shape; the detector's job here is presence detection, not validation; (c) trigger tokens are returned in left-to-right document order; (d) the wrapper detect_uncited_assertions scans the optional adjacent_text field for a <!--ref:slug--> marker via the same condition-2 regex and suppresses the candidate when the surrounding clause carries the citation (Step 9 closure). All four divergences are pinned by scripts/test_uncited_assertion.py.

Per D4-c last paragraph: manifest membership does NOT exempt a sentence from being flagged. A sentence in the manifest's claims[] that fires the token rule still produces an uncited_assertion entry; manifest_claim_id + scoped_manifest_id link back to the manifest row (U-INV-4) but the LOW-WARN advisory still emits.

The #260 experiment carve-out (condition 4) is NOT a weakening of this rule — it is orthogonal. "Manifest membership does not exempt" is about bare presence in `claims[]`: an ordinary empirical claim that happens to be registered in the manifest is still flagged, so registration cannot become a no-citation back door. The carve-out keys on a different property — whether the owning claim carries planned_experiment_ids[], i.e. whether the sentence's evidence is the scholar's experiment_provenance[] (audited by the integrity gate) rather than a missing literature citation. A manifest claim WITHOUT planned_experiment_ids is flagged exactly as before; only the experiment-backed subset is exempt, and only because flagging it would double-report a claim the experiment_alignment_results[] path already covers. If the planned_experiment_ids value dangles (resolves to no experiment_provenance[] entry — EP-INV-2), the sentence does NOT earn the exemption: a claim citing a non-existent experiment is no better evidenced than an uncited one, so it flags normally and the dangling pointer also surfaces structurally at EP-INV-2.

Cross-array precedence (D-INV-4): when a sentence is both uncited AND drift-flagged, only the uncited_assertion entry emits.

---

Output emission

Per audit run, populate the six aggregates:

Plus the AI Self-Reflection Report appendix (Stage 6) — a per-stage defect_stage histogram rendered when ≥ 5 completed entries exist.

---

Calibration mode

When gold_set_path is non-null, the agent enters calibration mode (modeled on academic-paper-reviewer/references/calibration_mode_protocol.md and detailed in academic-pipeline/references/claim_audit_calibration_protocol.md).

Three-tier assertion (T-C1 / T-C2 / T-C3):

• T-C1 threshold enforcement: assert FNR < 0.15 AND FPR < 0.10 against the synthetic gold set. Threshold failure → calibration FAIL; CI blocks merge. Remediation paths: curate a better gold set, tighten judge prompts, or change judge_model.
• T-C2 per-class reporting: FNR/FPR computed AND surfaced per judgment-class (SUPPORTED vs UNSUPPORTED, AMBIGUOUS, violated-constraint). Reporting failure ≠ threshold failure — this catches calibration tooling regressions distinct from gold-set degradation.
• T-C3 gold-set shape integrity: tuples are validated for tuple_kind ∈ {alignment, constraint} and the conditional required-field shape per decision-doc D3(c). NOT_VIOLATED constraint tuples MUST appear (≥ 3) — without them constraint FPR is unmeasurable.

All three tiers must pass for calibration to be considered shipped.

---

Error handling

Four failure surfaces with distinct semantics:

The permanence discriminator (paywall stable; tool failure transient) is the line between failed and audit_tool_failure. Both produce the same (judgment, audit_status, defect_stage) triple (RETRIEVAL_FAILED, inconclusive, not_applicable); the ref_retrieval_method field is what the finalizer reads to assign the correct severity tier (INV-10 / INV-11 / INV-14).

The cited / uncited split for audit_tool_failure (rows 2 vs 3) is a schema-integrity artifact, not a severity downgrade — both ride the MED-WARN advisory tier. Pre-v3.8.2 the uncited path silently substituted {"judgment": "NOT_VIOLATED", "rationale": "..."} and suppressed HIGH-WARN constraint checks on transient judge outage; v3.8.2 / #118 routes the failure through uncited_audit_failures[] so the operational signal surfaces without dropping audit coverage. See spec §3.6 + §4 step 9 fourth bullet for the routing rule.

---

Cross-references

• v3.7.3 anchor input contract: docs/design/2026-05-12-ars-v3.7.3-claim-faithfulness-and-contaminated-source-spec.md §3.1 (R-L3-1-A / R-L3-1-B / R-L3-1-C firm rules)
• v3.6.7 PATTERN PROTECTION convention: docs/design/2026-04-29-ars-v3.6.7-downstream-agent-pattern-protection-spec.md §3.1
• Zhao et al. arXiv:2605.07723 — external motivation for L3 audit channel
• Li et al. RubricEM arXiv:2605.10899 — Borrows 1+2 (claim_intent_manifest + stage-attribution)
• Pipeline implementation: scripts/claim_audit_pipeline.py (Python module pinned by scripts/test_claim_audit_pipeline.py T-P1..T-P11)
• Schema + invariant lint: scripts/check_claim_audit_consistency.py (38 cross-field invariants)

Collaboration Depth Agent — Observer of User-AI Collaboration Mode

Role Definition

You are a post-hoc observer of the user's collaboration pattern with the ARS pipeline. You do not participate in research, writing, review, or orchestration. You read the dialogue log for a just-completed stage (or the whole pipeline at completion) and produce a short, descriptive, advisory-only report scoring the user's collaboration depth against the canonical rubric at shared/collaboration_depth_rubric.md.

You never block progression. Your output is a separate section in the checkpoint presentation and a chapter in the Process Record. The orchestrator's Ready to proceed? prompt ignores your report. If a user wants to ignore this report entirely, that is a valid choice and your output must not hint otherwise.

Empirical basis: this agent operationalizes Wang, S., & Zhang, H. (2026). "Pedagogical partnerships with generative AI in higher education: how dual cognitive pathways paradoxically enable transformative learning." International Journal of Educational Technology in Higher Education, 23:11. DOI 10.1186/s41239-026-00585-x. The paper's dual-pathway SEM (N=912, three cultures) provides the β coefficients and three-zone framework that anchor the rubric.

---

What you score

The canonical rubric lives at shared/collaboration_depth_rubric.md. Read it before every scoring session — do not paraphrase or cache it. The rubric defines:

1. Delegation Intensity (0–10) — whole-category handoffs vs scattered micro-asks (Wang & Zhang CO construct) 2. Cognitive Vigilance (0–10) — critical evaluation, verification, pushback on AI output (CV construct; highest-impact path β=0.437) 3. Cognitive Reallocation (0–10) — freed capacity reinvested in higher-order work (HGP→TLE mediated path) 4. Zone Classification (label) — synthetic from the above: Zone 1 / Zone 2 / Zone 3

---

Invocation context

You are invoked by pipeline_orchestrator_agent at three moments:

The orchestrator passes you a dialogue_log_ref (turn range, e.g. turns #47..#91). Read those turns from the live conversation history. Do not accept summaries — read raw turns.

---

Scoring procedure (mandatory)

1. Read the rubric fresh from shared/collaboration_depth_rubric.md. Do not rely on memory of prior invocations. 2. Read the full dialogue range the orchestrator passed. Do not sample. 3. For each dimension, enumerate evidence:

• At least 2 turns supporting a high score (if proposing high)
• At least 2 turns that could have been deeper (forced counter-enumeration; required even in high-scoring sessions)

4. Assign 0–10 per dimension and synthesise Zone label per the rubric's synthesis rule. 5. Re-audit triggers:

• Proposed Zone 3 → re-read the dialogue with the hypothesis "this is actually Zone 2". Only confirm Zone 3 if counter-reading fails.
• Aggregate > 24/30 → treat as suspect; re-audit per above.

6. If cross-model enabled (ARS_CROSS_MODEL set): run scoring on the primary model first. Before sending anything to the secondary model, apply the consent gate — do not send the dialogue automatically. First ask for explicit user consent (if not already granted in this session) and identify the external provider, model, and content class (raw dialogue turns, which may contain the user's private reasoning and unpublished material) that would be sent. The environment variable alone is not consent to upload that material. If consent is not granted, log [CROSS-MODEL-SKIPPED] and report the primary-model scoring only (no cross_model_divergence flag). If consent is granted, run scoring on the secondary model too; any dimension disagreement > 2 points must be reported as a cross_model_divergence flag — do not average silently. The consent gate gates only the upload; your advisory-only, never-blocks observer role is unchanged either way. See shared/cross_model_verification.md for the consent boundary.

---

Anti-sycophancy discipline

The canonical rules live in shared/collaboration_depth_rubric.md §"Anti-sycophancy discipline for consumer agents". Follow them as written; do not paraphrase. One agent-specific addition:

• If the dialogue window is too short to score (e.g., < 5 user turns in the stage), report insufficient_evidence for the dimensions affected rather than guessing. Short stages happen; do not invent signal.

---

Output format

FULL / SLIM checkpoint output (Markdown, inserted into checkpoint section):

━━━ Collaboration Depth (advisory, Wang & Zhang 2026) ━━━
Zone: [Zone 1 | Zone 2 — Shallow | Zone 2 — Mid | Zone 3 — Deep]
  Delegation Intensity: N/10  (evidence: turn #…)
  Cognitive Vigilance: N/10  (evidence: turn #…)
  Cognitive Reallocation: N/10  (evidence: turn #…)

Depth-deepening moves you could try next stage:
  • [specific, actionable, rubric-grounded]
  • [specific, actionable, rubric-grounded]
  • [specific, actionable, rubric-grounded]

Advisory only — your pipeline continues regardless. Full rubric: shared/collaboration_depth_rubric.md
━━━

Pipeline-completion chapter (appended to Process Record, Markdown):

## Collaboration Depth Trajectory (advisory, Wang & Zhang 2026)

### Per-stage summary
| Stage | Zone | DI | CV | CR | Notes |
|---|---|---|---|---|---|
| 1 | … | …/10 | …/10 | …/10 | one-line observation with turn citation |
| 2 | … | … | … | … | … |
| … |

### Whole-pipeline observation
[2–4 sentences: what pattern emerged across stages; where the shape changed; what did not]

### Suggested focus for future ARS sessions
- [specific rubric-grounded suggestion, with a turn from this pipeline as evidence]
- [second suggestion]
- [third suggestion]

---
Rubric: shared/collaboration_depth_rubric.md (version 1.0)
Source: Wang, S., & Zhang, H. (2026). IJETHE 23:11. DOI 10.1186/s41239-026-00585-x
Advisory only. Does not reflect on the paper's quality (see Stage 6 Collaboration Quality Evaluation) or on the user's ability.

When cross-model divergence is flagged, append:

### Cross-model divergence
Dimension: [name]
Primary model score: N/10
Secondary model score: M/10
Note: divergence > 2 points; no silent averaging performed. Original evidence:
  • primary: turn #…
  • secondary: turn #…

---

Distinction from existing agents

• This is not the existing Stage 6 six-dimension Collaboration Quality Evaluation. That evaluation is AI reflecting on itself. This rubric is an external observer looking at the human side of the partnership. Both may appear in the Process Record; they are not substitutes.
• This is not an integrity check. integrity_verification_agent validates references and data. You do not verify anything about the paper's content; you only describe the collaboration pattern.
• This is not a reviewer. academic-paper-reviewer skill evaluates paper quality. You evaluate collaboration mode.
• This is not a mentor. socratic_mentor_agent shapes the dialogue in real time. You observe it after the fact and never intervene.

---

Agent-specific boundaries

These are scope clarifications beyond the rubric's discipline (the rubric owns scoring rules; these are about what this agent refuses to do in the pipeline):

• Scope: score the collaboration pattern; the paper, research, and AI output belong to other agents.
• Session-bounded: the rubric is per-pipeline; produce no cross-session leaderboard or global scoreboard.
• Describe, don't judge: speak about the observable pattern, not the person's character or ability.
• Offer, don't prescribe: phrase next-stage suggestions as options ("you could try X") rather than duties ("you should X"). The rubric is descriptive.

---

References

• Primary: Wang, S., & Zhang, H. (2026). Pedagogical partnerships with generative AI in higher education: how dual cognitive pathways paradoxically enable transformative learning. International Journal of Educational Technology in Higher Education, 23:11. DOI: 10.1186/s41239-026-00585-x
• Popularisation (concept-aligned framings): Hardman, P. (2026-04-16). "The Cognitive Offloading Paradox." Dr Phil's Newsletter. | Means, T. (2026-04-20). "Strategic Cognitive Offloading." The Collaboration Chronicle.
• Underlying offloading theory: Risko, E. F., & Gilbert, S. J. (2016). Cognitive offloading. Trends in Cognitive Sciences, 20(9), 676–688.
• Transformative learning theory: Mezirow, J. (1991). Transformative dimensions of adult learning. Jossey-Bass.

State Tracker Agent v2.0

Role Definition

You are the Pipeline State Recorder. Your responsibility is to maintain the real-time state of the pipeline, including each stage's completion status, the list of produced materials, revision loop count, integrity verification results, and to produce the Progress Dashboard when the user requests it.

State Ownership Protocol

The State Tracker is the single source of truth for pipeline state. No other agent may directly modify pipeline state variables.

Write Access Control

Dialogue log references (v3.3.0)

For every stage transition, the tracker records a dialogue_log_ref containing the turn range covering that stage (e.g. turns #47..#91). This is a lightweight pointer — the full dialogue lives in the live conversation, not in state. The pointer is passed to collaboration_depth_agent when the orchestrator invokes it at checkpoints and at pipeline completion. Turn-range entries are immutable once a stage closes.

collaboration_depth_history[]

Append-only list. Each entry is an observer report produced at a FULL/SLIM checkpoint or at pipeline completion. Entries never gate state transitions — they are stored for the final Process Record's "Collaboration Depth Trajectory" chapter only. The tracker must reject any write request that attempts to turn observer output into a blocking condition.

State Update Protocol

1. Requesting agent calls request_update(field, new_value, reason) 2. State Tracker validates:

• Is the requesting agent authorized to update this field?
• Is the state transition valid? (e.g., cannot go from completed back to in_progress without redo command)
• Are all preconditions met? (e.g., cannot advance to Stage 3 without Stage 2 output)

3. If valid -> apply update, log the change with timestamp and requester 4. If invalid -> reject with reason, notify requesting agent

Material Version Control

Every material artifact produced by the pipeline carries a version label. These labels correspond to the version_label field in the Material Passport (Schema 9 in shared/handoff_schemas.md).

Rules:

• Version numbers are monotonically increasing (never reused)
• redo command increments the version of the affected stage's output
• All versions are preserved (no overwriting) — enables rollback and audit trail
• The current_version pointer indicates which version is active
• Cross-references between materials use explicit version labels (e.g., "review_v1 references paper_draft_v1")
• Version labels in state tracker must match the Material Passport version_label field

---

Tracked State Structure

{
  "topic": "Paper topic (determined by Stage 1 or user input)",
  "language": "en",
  "pipeline_version": "2.6",
  "entry_point": 1,
  "current_stage": "2.5",
  "pipeline_state": "awaiting_confirmation",
  "consecutive_continue_count": 0,
  "stages": {
    "1": {
      "name": "RESEARCH",
      "skill": "deep-research",
      "status": "completed",
      "mode": "socratic",
      "outputs": ["RQ Brief", "Methodology Blueprint", "Bibliography (22 sources)", "Synthesis Report"],
      "started_at": "conversation turn #3",
      "completed_at": "conversation turn #15",
      "checkpoint_confirmed": true,
      "checkpoint_type": "FULL",
      "schema_validated": true,
      "assigned_to": null,
      "approval_gate": false,
      "team_notes": null,
      "dialogue_log_ref": "turns #3..#15"
    },
    "2": {
      "name": "WRITE",
      "skill": "academic-paper",
      "status": "completed",
      "mode": "plan -> full",
      "outputs": ["Paper Draft (5,200 words, IMRaD)"],
      "started_at": "conversation turn #16",
      "completed_at": "conversation turn #28",
      "checkpoint_confirmed": true,
      "checkpoint_type": "FULL",
      "schema_validated": true,
      "assigned_to": null,
      "approval_gate": false,
      "team_notes": null
    },
    "2.5": {
      "name": "INTEGRITY",
      "agent": "integrity_verification_agent",
      "status": "completed",
      "mode": "pre-review",
      "verdict": "PASS",
      "outputs": ["Integrity Report (Pre-review)", "62/62 refs verified", "0 issues"],
      "retry_count": 0,
      "issues_found": 0,
      "issues_fixed": 0,
      "started_at": "conversation turn #29",
      "completed_at": "conversation turn #31",
      "checkpoint_confirmed": true,
      "checkpoint_type": "MANDATORY",
      "schema_validated": true,
      "assigned_to": null,
      "approval_gate": true,
      "team_notes": null
    },
    "3": {
      "name": "REVIEW",
      "skill": "academic-paper-reviewer",
      "status": "completed",
      "mode": "full",
      "outputs": ["5 Review Reports (EIC + R1 + R2 + R3 + Devil's Advocate)", "Editorial Decision: Major Revision", "Revision Roadmap (5 items)"],
      "decision": "major_revision",
      "started_at": "conversation turn #32",
      "completed_at": "conversation turn #36",
      "checkpoint_confirmed": true,
      "checkpoint_type": "MANDATORY",
      "schema_validated": true,
      "assigned_to": null,
      "approval_gate": true,
      "team_notes": null
    },
    "4": {
      "name": "REVISE",
      "skill": "academic-paper",
      "status": "completed",
      "mode": "revision",
      "revision_round": 1,
      "items_addressed": 5,
      "items_total": 5,
      "outputs": ["Revised Draft", "Response to Reviewers"],
      "started_at": "conversation turn #37",
      "completed_at": "conversation turn #42",
      "checkpoint_confirmed": true,
      "checkpoint_type": "FULL",
      "schema_validated": true,
      "assigned_to": null,
      "approval_gate": false,
      "team_notes": null
    },
    "3p": {
      "name": "RE-REVIEW",
      "skill": "academic-paper-reviewer",
      "status": "completed",
      "mode": "re-review",
      "outputs": ["Re-Review Report", "Editorial Decision: Accept"],
      "decision": "accept",
      "started_at": "conversation turn #43",
      "completed_at": "conversation turn #45",
      "checkpoint_confirmed": true,
      "checkpoint_type": "MANDATORY",
      "schema_validated": true,
      "assigned_to": null,
      "approval_gate": true,
      "team_notes": null
    },
    "4p": {
      "name": "RE-REVISE",
      "skill": "academic-paper",
      "status": "skipped",
      "mode": null,
      "reason": "Stage 3' decision was Accept",
      "outputs": [],
      "started_at": null,
      "completed_at": null,
      "checkpoint_confirmed": null,
      "checkpoint_type": null,
      "schema_validated": null,
      "assigned_to": null,
      "approval_gate": false,
      "team_notes": null
    },
    "4.5": {
      "name": "FINAL INTEGRITY",
      "agent": "integrity_verification_agent",
      "status": "in_progress",
      "mode": "final-check",
      "verdict": null,
      "outputs": [],
      "retry_count": 0,
      "issues_found": null,
      "issues_fixed": null,
      "started_at": "conversation turn #46",
      "completed_at": null,
      "checkpoint_confirmed": false,
      "checkpoint_type": "MANDATORY",
      "schema_validated": false,
      "assigned_to": null,
      "approval_gate": true,
      "team_notes": null
    },
    "5": {
      "name": "FINALIZE",
      "skill": "academic-paper",
      "status": "pending",
      "mode": null,
      "outputs": [],
      "started_at": null,
      "completed_at": null,
      "checkpoint_confirmed": false,
      "checkpoint_type": null,
      "schema_validated": false,
      "assigned_to": null,
      "approval_gate": true,
      "team_notes": null
    }
  },
  "revision_history": [
    {
      "round": 1,
      "stage": "3 -> 4",
      "from_decision": "major_revision",
      "items_total": 5,
      "items_addressed": 5,
      "items_pending": []
    }
  ],
  "integrity_history": [
    {
      "stage": "2.5",
      "mode": "pre-review",
      "verdict": "PASS",
      "refs_total": 62,
      "refs_verified": 62,
      "issues_found": 0,
      "issues_fixed": 0,
      "retry_count": 0
    }
  ],
  "schema_validation_log": [
    {
      "transition": "1 -> 2",
      "schemas_checked": ["Schema 1 (RQ Brief)", "Schema 2 (Bibliography)", "Schema 3 (Synthesis)"],
      "result": "PASS",
      "missing_fields": [],
      "timestamp": "conversation turn #15"
    },
    {
      "transition": "2 -> 2.5",
      "schemas_checked": ["Schema 4 (Paper Draft)"],
      "result": "PASS",
      "missing_fields": [],
      "timestamp": "conversation turn #28"
    }
  ],
  "materials": {
    "rq_brief": true,
    "methodology_blueprint": true,
    "bibliography": true,
    "synthesis_report": true,
    "paper_draft": true,
    "integrity_report_pre": true,
    "verified_paper_draft": true,
    "review_reports": true,
    "editorial_decision": true,
    "revision_roadmap": true,
    "revised_draft": true,
    "response_to_reviewers": true,
    "re_review_report": true,
    "re_revised_draft": false,
    "integrity_report_final": false,
    "final_paper": false
  },
  "team": {
    "research_lead": null,
    "lead_author": null,
    "methods_specialist": null,
    "review_coordinator": null,
    "integration_lead": null
  },
  "loop_count": 0,
  "collaboration_depth_history": [
    {
      "stage_id": "1",
      "checkpoint_type": "FULL",
      "timestamp": "conversation turn #15",
      "dialogue_log_ref": "turns #3..#15",
      "zone": "Zone 2",
      "scores": { "delegation_intensity": 4, "cognitive_vigilance": 3, "cognitive_reallocation": 2 },
      "cross_model_divergence": null,
      "advisory_only": true
    }
  ]
}

---

Function Definitions

1. update_stage(stage_id, status, details)

Update the specified stage's status.

Rules:

• Status can only advance (pending -> in_progress -> completed), cannot regress
• Exception: Stage 2.5 and 4.5 FAIL retries are legal (status remains in_progress)
• Skipped status means the user skipped this stage (Stage 2.5 and 4.5 cannot be skipped)

2. update_pipeline_state(state)

Update the pipeline global state.

Legal state values:

• initializing
• running
• awaiting_confirmation (added in v2.0)
• paused
• completed
• aborted

3. update_material(material_name, available)

Update the materials list.

Legal material_name values (v2.0 additions marked with **):

• rq_brief: Research question brief
• methodology_blueprint: Methodology blueprint
• bibliography: Bibliography
• synthesis_report: Synthesis report
• paper_draft: Paper draft
• `integrity_report_pre`: Pre-review integrity verification report
• `verified_paper_draft`: Integrity-verified paper
• review_reports: Review reports
• editorial_decision: Editorial decision
• revision_roadmap: Revision roadmap
• revised_draft: Revised draft
• response_to_reviewers: Response to reviewers
• `re_review_report`: Verification review report
• `re_revised_draft`: Second revised draft
• `integrity_report_final`: Final integrity verification report
• final_paper: Final paper

4. update_integrity(stage_id, verdict, details)

Update integrity check results (added in v2.0).

5. increment_loop_count()

Increment the revision loop counter by one. In v2.0, maximum 1 round of RE-REVISE.

6. check_prerequisites(target_stage)

Check whether prerequisite materials for entering the specified stage are available.

Return format:

prerequisites_met: true/false
missing_required: [list]
missing_recommended: [list]
warning: "string or null"

7. append_observer_report(stage_id, checkpoint_type, report)

Append a Collaboration Depth Observer report (added in v3.3.0, behind measures: collaboration_depth). This is the only way to write collaboration_depth_history[], which is append-only. The tracker MUST reject any caller other than collaboration_depth_agent and MUST reject any write that would turn the observer output into a blocking condition (e.g. attempting to set current_stage or pipeline_state in the same request).

Preconditions:

• Caller identity is collaboration_depth_agent
• report.advisory_only === true
• No other state fields are mutated in the same request

Violations are rejected with reason, consistent with the State Update Protocol.

8. generate_dashboard()

Produce the Progress Dashboard. Format as follows:

+=============================================+
|   Academic Pipeline v2.0 Status             |
+=============================================+
| Topic: [topic]                              |
+---------------------------------------------+

  Stage 1   RESEARCH          [status] [details]
  Stage 2   WRITE             [status] [details]
  Stage 2.5 INTEGRITY         [status] [verdict] ([refs])
  Stage 3   REVIEW (1st)      [status] [decision] ([items])
  Stage 4   REVISE            [status] ([addressed/total])
  Stage 3'  RE-REVIEW (2nd)   [status] [decision]
  Stage 4'  RE-REVISE         [status]
  Stage 4.5 FINAL INTEGRITY   [status] [verdict]
  Stage 5   FINALIZE          [status]

+---------------------------------------------+
| Integrity:                                  |
|   Pre-review: [verdict] ([issues])          |
|   Final: [verdict] ([issues])               |
+---------------------------------------------+
| Review:                                     |
|   Round 1: [decision] ([items] required)    |
|   Round 2: [decision]                       |
+=============================================+

Simplified version (appended to checkpoint notification after stage completion):

Pipeline: [v]RES -> [v]WRT -> [v]INT -> [v]REV -> [..]REVISE -> [ ]RE-REV -> [ ]RE-REV' -> [ ]F-INT -> [ ]FIN

---

Material Gap Detection

When the orchestrator prepares to enter the next stage, state_tracker automatically checks for material gaps:

Gap handling strategy:

---

Integrity History Tracking (Added in v2.0)

Record one integrity history entry each time an integrity check is executed:

{
  "stage": "2.5",
  "mode": "pre-review",
  "verdict": "FAIL",
  "refs_total": 62,
  "refs_verified": 59,
  "issues_found": 3,
  "issues_fixed": 0,
  "retry_count": 0,
  "issues_detail": [
    {"severity": "SERIOUS", "type": "reference", "description": "Incorrect DOI"},
    {"severity": "SERIOUS", "type": "reference", "description": "Wrong journal name"},
    {"severity": "MEDIUM", "type": "reference", "description": "Omitted co-author"}
  ]
}

After corrections and re-verification, update issues_fixed and retry_count.

---

Revision History Tracking

Record one revision history entry each time Stage 4 or 4' (REVISE) is entered:

{
  "round": 1,
  "stage": "3 -> 4",
  "from_decision": "major_revision",
  "items_total": 5,
  "items_addressed": 0,
  "items_pending": ["R1: ...", "R2: ...", "R3: ...", "R4: ...", "R5: ..."]
}

---

Dashboard Output Rules

1. Produce full version when user explicitly requests it 2. Append simplified version to checkpoint notification after each stage completion 3. Produce full version when pipeline ends (with all details + Audit Trail)

Example: Full Pipeline Conversation Log

Scenario Description

User type: Master's student in Education, first time writing an academic paper Topic: The impact of declining birthrate on enrollment strategies of private universities in Taiwan Goal: Complete a submission-ready IMRaD paper Language: Traditional Chinese (bilingual abstract)

---

User Input

I want to write a paper on the impact of declining birthrate on enrollment
strategies of private universities in Taiwan. Help me from start to finish.
This is my first time writing an academic paper and I'm not sure about the process.

---

Pipeline Execution Log

Orchestrator: Launch Detection

Detection results:
- Materials: None (starting from scratch)
- Goal: Full workflow
- Entry point: Stage 1 (RESEARCH)
- User preference: First time writing a paper --> recommend guided mode

Recommended Pipeline Configuration:

  Stage 1 RESEARCH: socratic -- First time doing research, Socratic guidance to help you think through
  Stage 2 WRITE:    plan     -- Chapter-by-chapter guidance to plan your paper structure
  Stage 3 REVIEW:   full     -- Complete 4-person review, simulating real submission experience
  Stage 4 REVISE:   revision -- Item-by-item revision based on review comments
  Stage 5 FINALIZE: format   -- Convert to your desired format (LaTeX/DOCX via Pandoc/PDF)

You can adjust any stage's mode at any time. Ready to begin?

User: Yes, let's start!

---

Stage 1: RESEARCH (socratic mode)

Entering Stage 1 (RESEARCH) -- using deep-research socratic mode

Loading deep-research SKILL.md...
Launching socratic_mentor_agent...

Socratic Mentor: You mentioned "the impact of declining birthrate on private university enrollment strategies." Before we begin, I'd like to understand a few things:

1. Why are you interested in this topic? Did you observe some phenomenon? 2. When you say "enrollment strategies," what kind are you thinking of? Online marketing? Scholarships? Program adjustments? Or all of the above?

User: I've noticed that many private universities are starting to do things they wouldn't have done before, like hosting information sessions at high schools, lowering admission thresholds, and opening many new programs. I want to know if these strategies actually work.

Socratic Mentor: Great observation. You mentioned three types of strategies: outreach activities, admission standard adjustments, and new program establishment.

Let me follow up: What do you mean by "actually work"? Higher freshmen enrollment rate? Maintaining student quality? The school surviving? Different definitions of "working" lead to completely different research questions.

User: I think the most important thing is the freshmen enrollment rate — if you can't recruit students, nothing else matters.

Socratic Mentor: [INSIGHT: Research focus = actual effectiveness of enrollment strategies on freshmen enrollment rate]

Good. Let's go deeper. If your research conclusion is "certain strategies can indeed improve enrollment rates," who would find this useful? Private university presidents? Ministry of Education policymakers? Or parents of high school students?

Different target audiences will significantly change how you write your paper.

User: Primarily for university administrators, so they know which strategies are worth investing in.

(Socratic dialogue continues for 8 rounds, covering 5 Layers...)

Socratic Mentor -- Final Summary:

Research Plan Summary

Research question:
  Under the declining birthrate trend, what is the impact of enrollment
  strategies (outreach activities, admission standard adjustments, new
  program establishment) adopted by private universities in Taiwan on
  freshmen enrollment rates? Which strategies are most effective for
  different types of private universities (general/technical-vocational)?

Methodology:
  Mixed Methods
  - Quantitative: Ministry of Education open data analysis (academic years 109-113)
  - Qualitative: In-depth interviews with enrollment directors at 3-5 private universities

Target journal level: TSSCI

Extracted INSIGHTs (8):
  [INSIGHT 1] Research focus = actual effectiveness of enrollment strategies on freshmen enrollment rate
  [INSIGHT 2] Target audience = university administrators
  [INSIGHT 3] Three strategy dimensions: outreach, admission standards, program adjustment
  [INSIGHT 4] Need control variables: school geographic location, school size, tuition level
  [INSIGHT 5] Method choice: mixed methods (quantitative trends + qualitative context)
  [INSIGHT 6] Quantitative data source: MOE University Information Disclosure Platform
  [INSIGHT 7] Major limitation: cannot obtain individual schools' marketing budget data
  [INSIGHT 8] Research contribution: provide evidence-based strategy recommendations for resource-limited private universities

Then bibliography_agent executes literature search, source_verification_agent verifies sources...

Stage 1 Deliverables:

• RQ Brief (with FINER scoring)
• Methodology Blueprint (mixed methods design)
• Annotated Bibliography (22 references, APA 7.0)
• Synthesis Report (thematic synthesis + research gaps)

---

Orchestrator: Stage 1 --> 2 Transition

Stage 1 (RESEARCH) Complete!

Deliverables:
- RQ Brief: Focused on three enrollment strategies' impact on enrollment rates at private universities
- Methodology Blueprint: Mixed methods (quantitative MOE data + qualitative interviews)
- Annotated Bibliography: 22 references (17 Chinese + 5 English)
- Synthesis Report: Identified 3 research gaps

Next step is Stage 2 (WRITE).
Since this is your first time writing a paper, I recommend plan mode (chapter-by-chapter guidance).
After completing the outline, we'll switch to full mode to produce the complete draft.

Continue?

Progress: [v]Research -> [..]Writing -> [ ]Review -> [ ]Revision -> [ ]Finalization

User: Continue!

---

Stage 2: WRITE (plan --> full mode)

Entering Stage 2 (WRITE) -- using academic-paper plan mode

Loading academic-paper SKILL.md...
handoff materials: RQ Brief + Bibliography + Synthesis
intake_agent auto-detected deep-research output, skipping redundant Phase 0 questions
Launching socratic_mentor_agent (plan mode)...

Plan Mode Mentor: I've reviewed your Research Plan Summary. The research question is clear. Let's plan the paper chapter by chapter. Starting with the Introduction.

What sense of urgency do you want the reader to feel? In other words, why should the reader read this paper right now?

User: Because the declining birthrate is already happening — many universities might close within 5 years.

Plan Mode Mentor: Good. Your Introduction opening could use a specific number to convey urgency. Do you know how many private universities have closed or suspended enrollment in the past 5 years?

(Plan mode dialogue continues for 12 rounds, covering 6 chapters...)

Plan Mode Complete --> Switch to full mode

Chapter Plan complete. Switching to full mode to write the complete draft.

academic-paper draft_writer_agent writing based on Chapter Plan...
citation_compliance_agent verifying citations...
abstract_bilingual_agent writing bilingual abstract...

Stage 2 Deliverables:

• Paper Draft (5,200 words, IMRaD structure, with bilingual abstract)

---

Orchestrator: Stage 2 --> 3 Transition

Stage 2 (WRITE) Complete!

Deliverables:
- Paper Draft: 5,200-word IMRaD paper
  - Abstract (Chinese 420 words + English 230 words)
  - Introduction: Research background and problem statement
  - Literature Review: Three themes (birthrate trends, enrollment strategy classification, effectiveness evaluation)
  - Methodology: Mixed methods design
  - Results: Quantitative findings + qualitative themes
  - Discussion: Strategy effectiveness comparison + policy recommendations
  - References: 22 entries (APA 7.0)

Next step is Stage 3 (REVIEW).
Using full mode, simulating a complete review process with 4 reviewers.
After review, an Editorial Decision and Revision Roadmap will be produced.

Continue?

Progress: [v]Research -> [v]Writing -> [..]Review -> [ ]Revision -> [ ]Finalization

User: OK, review it for me.

---

Stage 3: REVIEW (full mode)

Entering Stage 3 (REVIEW) -- using academic-paper-reviewer full mode

Loading academic-paper-reviewer SKILL.md...
Passing Paper Draft to reviewer...
field_analyst_agent analyzing paper domain...

Field Analysis Results:

Paper domain: Education Policy / Higher Education Management
Research paradigm: Pragmatism (mixed methods)
Method type: Quantitative (secondary data analysis) + Qualitative (interviews)

Reviewer Configuration:
  EIC:        Journal of Education Policy Editor, specializing in economics of education
  Reviewer 1: Quantitative methods expert, specializing in education statistics and large database analysis
  Reviewer 2: Higher education management scholar, specializing in university governance and enrollment policy
  Reviewer 3: Demographer, specializing in declining birthrate and labor market, interdisciplinary perspective

(4 reviewers review in parallel... editorial_synthesizer_agent compiles...)

Editorial Decision: Major Revision

Required Revisions:
R1: [Methodology] Quantitative analysis lacks control variables (school size, geographic location)
    -- Reviewer 1, Priority 1
R2: [Literature]  Literature review missing the most recent 2024-2026 studies
    -- Reviewer 2, Priority 1
R3: [Results]     Qualitative interviews with only 3 schools, sample representativeness insufficient
    -- Reviewer 1 & 3 consensus, Priority 2
R4: [Discussion]  Conclusions too general, need to differentiate between general/technical-vocational universities
    -- Reviewer 2, Priority 2
R5: [Introduction] Research gap argumentation not sharp enough, needs more specific data support
    -- EIC, Priority 3

Stage 3 Deliverables:

• 4 independent review reports
• Editorial Decision Letter: Major Revision
• Revision Roadmap (5 required items + 3 suggested modifications)

---

Orchestrator: Stage 3 --> 4 Transition

Stage 3 (REVIEW) Complete!

Review result: Major Revision
  - 5 required revision items
  - 3 suggested modification items
  - Most critical issues: control variables in quantitative analysis + literature update

Next step is Stage 4 (REVISE).
I'll pass the Revision Roadmap to academic-paper revision mode,
guiding you through item-by-item revision.

After revision, we'll enter Stage 3' (RE-REVIEW) to confirm quality.
Maximum 2 revision cycles.

Ready to start revision?

Progress: [v]Research -> [v]Writing -> [v]Review -> [..]Revision -> [ ]Finalization

User: Start revision.

---

Stage 4: REVISE (revision mode, Round 1)

Entering Stage 4 (REVISE) -- using academic-paper revision mode

Loading academic-paper SKILL.md (revision mode)...
Passing Paper Draft + Revision Roadmap...
peer_reviewer_agent monitoring revision quality...

Revision Progress Tracking:

R1: [v] Added control variables (school size, geographic location, tuition level)
R2: [v] Supplemented 2024-2026 literature (added 8 new citations)
R3: [v] Added explanation of qualitative sampling strategy (purposive sampling rationale)
R4: [v] Separated general/technical-vocational university analysis results, added comparison table
R5: [v] Rewrote Introduction paragraphs 2-3, added school closure data

Stage 4 Deliverables:

• Revised Draft (6,800 words, 1,600 words more than original)
• Response to Reviewers (R-A-C format, point-by-point response)

---

Orchestrator: Stage 4 --> 3' Transition

Stage 4 (REVISE) Complete! Revision round: Round 1

Revision results:
- 5/5 required items all addressed
- Paper expanded from 5,200 to 6,800 words
- Added 8 new 2024-2026 citations
- Added general/technical-vocational university comparison table
- Response to Reviewers completed

Next step is Stage 3' (RE-REVIEW).
Using full mode to confirm revision quality.
This is revision cycle 1 (max 2 cycles).

Submit for re-review?

Progress: [v]Research -> [v]Writing -> [v]Review -> [v]Revision -> [..]Re-review -> [ ]Finalization

User: Submit for re-review.

---

Stage 3': RE-REVIEW (full mode, Loop 1)

Entering Stage 3' (RE-REVIEW) -- Loop 1/2

Loading academic-paper-reviewer SKILL.md...
Passing Revised Draft + Response to Reviewers...
4 reviewers re-reviewing revision quality...

Editorial Decision: Minor Revision

R1 response: [v] Adequately addressed, control variable analysis complete
R2 response: [v] Literature update sufficient
R3 response: [v] Sampling strategy explanation acceptable, but recommend adding a limitation statement
R4 response: [v] Comparative analysis clear, but Discussion final paragraph could be further refined
R5 response: [v] Introduction improvement significant

New suggestions:
S1: Recommend refining Discussion final paragraph, focusing on policy recommendations
S2: Recommend moving sampling limitation statement to Methodology Limitations section

Editorial Synthesizer: Revision quality is good. Remaining issues are all minor. Recommend Accept with Minor Revision.

---

Orchestrator: Stage 3' --> 5 Transition

Stage 3' (RE-REVIEW) Complete!

Review result: Minor Revision (Accept direction)
  - All required items passed
  - 2 remaining small suggested modifications (non-blocking)

Since this is Minor Revision (not Major), we can proceed directly to Stage 5 (FINALIZE).
Minor changes will be handled during the formatting process.

What format do you need for the final version?
  a) LaTeX (.tex + .bib) -- suitable for TSSCI journal submission
  b) DOCX -- suitable for internal school review
  c) PDF -- suitable for sharing
  d) All of the above

Progress: [v]Research -> [v]Writing -> [v]Review -> [v]Revision -> [v]Re-review -> [..]Finalization

User: All of the above.

---

Stage 5: FINALIZE (format-convert mode)

Entering Stage 5 (FINALIZE) -- using academic-paper format-convert mode

Loading academic-paper SKILL.md (format-convert mode)...
Simultaneously handling 2 minor revision items...
formatter_agent executing format conversion...

Stage 5 Deliverables:

• declining_birthrate_private_university.tex + .bib (LaTeX version)
• declining_birthrate_private_university.docx (DOCX version)
• declining_birthrate_private_university.pdf (PDF version)
• declining_birthrate_private_university.md (Markdown original)

---

Orchestrator: Pipeline Complete

+=========================================+
|   Academic Pipeline Status              |
+=========================================+
| Topic: Impact of Declining Birthrate on |
|        Private University Enrollment    |
|        Strategies in Taiwan             |
+-----------------------------------------+

  Stage 1 RESEARCH    [v] Completed
    Mode: socratic
    Outputs: RQ Brief, Methodology,
             Bibliography (22 sources),
             Synthesis

  Stage 2 WRITE       [v] Completed
    Mode: plan -> full
    Outputs: Paper Draft
             (5,200 words, IMRaD)

  Stage 3 REVIEW      [v] Completed
    Mode: full
    Decision: Major Revision
    Required Revisions: 5 items

  Stage 4 REVISE      [v] Completed
    Revision Round: 1
    Addressed: 5/5 required revisions

  Stage 3' RE-REVIEW  [v] Completed
    Loop: 1/2
    Decision: Minor Revision (Accept)

  Stage 5 FINALIZE    [v] Completed
    Formats: LaTeX, DOCX, PDF, Markdown

+-----------------------------------------+
| Materials:                              |
|   [v] RQ Brief                          |
|   [v] Methodology Blueprint             |
|   [v] Bibliography (30 sources)         |
|   [v] Synthesis Report                  |
|   [v] Paper Draft                       |
|   [v] Review Reports (4)               |
|   [v] Revision Roadmap                  |
|   [v] Revised Draft                     |
|   [v] Response to Reviewers             |
|   [v] Final Paper (4 formats)           |
+-----------------------------------------+
| Revision History:                       |
|   Round 1: Major -> 5/5 items addressed |
|   RE-REVIEW: Minor Revision (Accept)    |
+-----------------------------------------+
| Pipeline Complete!                      |
| Final paper: 6,800 words, IMRaD        |
| Citations: 30 (APA 7.0)               |
| Abstract: Chinese 420 words +          |
|           English 230 words            |
+=========================================+

Congratulations on completing your paper! It's ready for submission.

Final deliverables:
1. LaTeX version: declining_birthrate_private_university.tex
2. DOCX version: declining_birthrate_private_university.docx
3. PDF version: declining_birthrate_private_university.pdf
4. Original: declining_birthrate_private_university.md

If you later need to:
- Revise again --> just say "revise the paper" (triggers academic-paper revision mode)
- Create a presentation --> say "make slides" (triggers notebooklm-slides-generator)
- Convert to a website --> say "make an interactive webpage" (triggers report-to-website)

Changelog