ars-pipeline-orchestrator

Academic Pipeline v3.21.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: see references/shared/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.

---

Runtime Environment Self-Check (run first, non-blocking)

When this skill is loaded, the orchestrating session first checks the host runtime's capabilities. Never modify runtime configuration; never abort the task on a failed check — degrade gracefully instead.

Cross-Skill & Sub-Agent Dispatch Rules

1. This orchestrator performs no substantive research/writing/review work itself. Each stage is executed by dispatching the corresponding independent skill package: Stage 1 → ars-deep-research, Stage 2 → ars-academic-paper, Stage 3 → ars-academic-reviewer.
2. When dispatching ANY role agent or stage skill as a sub-session, the FIRST sentence of the task instruction MUST be: "Before executing, fully read the applicable rule file (./SKILL.md of the target skill, or ./references/.md for a role agent) and load all its constraints. Do not skip the rule files; do not work from the task summary alone."
3. Sub-sessions start with isolated context — pass only the materials required for the stage (e.g. research report → paper writing → review); do not assume the sub-session sees the orchestrator's history.
4. When a sub-session returns, the orchestrator collects its output, records state in the Material Passport, closes the sub-session, then proceeds to the next stage after user confirmation.
5. If the runtime has no sub-agent dispatch, execute each stage inline (role-play) in the current session — the target skill's rule files MUST still be read and applied with equal strictness.

Universal Academic Integrity Rules (binding on ALL agents)

1. Vision/OCR mandatory reading — scanned documents, figure tables, logic diagrams, and complex formulas MUST be parsed with vision/OCR tooling; never guess image content from surrounding text.
2. Evidence binding — every academic claim must carry a verifiable source; any unsupported conjecture MUST be labeled [SPECULATION — UNVERIFIED] / 【推测·待验证】.
3. Zero hallucination — never fabricate DOIs, references, authors, experimental data, or research results.
4. Logic conservation — never silently alter the agreed research scope, direction, or assumptions mid-project.
5. Computation recheck — after any mathematical derivation or data computation, remind the user to manually verify the result.

---

v3.6.3 (opt-in): Enable the ARS_PASSPORT_RESET option to promote FULL checkpoints to context-reset boundaries. Use resume_from_passport= in a fresh session to continue from the recorded stage. See references/guides/passport_as_reset_boundary.md.

v3.8 (opt-in): Enable the ARS_CLAIM_AUDIT option 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 references/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 checks — After paper completion and before review submission, run the declared reference, registered-claim, and reported-data checks; expose denominators, sampling, unknown states, and blocking verdicts
3. Two-stage review — First full review + post-revision focused verification review
4. Final integrity check — After revision completion, rerun the final-check contract from fresh inputs; 100% applies only where the named registered population is explicitly complete
5. Auditable — Version, hash, and retain workflow artifacts; deterministic checks are replayable, while generative outputs are not promised byte-identical
6. Process documentation — Stage 6 generates a "Paper Creation Process Record" PDF documenting the human-AI collaboration history (delivered before the terminal acknowledgement that completes the pipeline)

Quick Start

Full workflow (from scratch):

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

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

Mid-entry (existing paper):

I already have a paper, help me review it

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

Revision mode (received reviewer feedback):

I received reviewer comments, help me revise

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

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

resume_from_passport= [stage=] [mode=]

--> Loads the Material Passport (Schema 9), locates the kind: boundary entry matching ``, 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= 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): the ARS_PASSPORT_RESET option must be enabled 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= against a passport that carries a valid boundary entry matching the hash.
• Intent: Invoke in a fresh agent 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/guides/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 ars-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; then Integrity Check FAIL Loop -> recorded user decision)
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; after 3 unresolved rounds -> Integrity Check FAIL Loop -> recorded user decision)
9. Stage 5 FINALIZE -> MD -> DOCX via Pandoc when available (otherwise instructions) -> ask about LaTeX -> confirm -> PDF -> completion checkpoint (FULL) -> Stage 6 (user may decline Stage 6: marked skipped, pipeline goes directly to completed)
10. Stage 6 PROCESS SUMMARY -> ask language version -> generate process record MD -> LaTeX -> PDF -> terminal acknowledgement (finish / end / done / confirm, or an unambiguous natural-language equivalent) -> pipeline global state completed

See references/guides/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]
- Criterion status: [named criterion + evidence-anchored categorical judgement, or `NOT_COMPARABLE`]

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 entry gate): always MANDATORY — this is the checkpoint between Stage 4.5 PASS and the Stage 5 dispatch, where the user explicitly confirms proceeding and makes the finalization-format decision (citation style); the in-stage LaTeX question and content confirmation stay inside Stage 5 execution. The Stage 5 completion checkpoint (Final Paper delivered, before Stage 6) is FULL — never SLIM. See references/guides/pipeline_state_machine.md § Stage 5 boundary semantics
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. Criterion trajectory: For each applicable named criterion, did the evidence-anchored status improve, remain unchanged, regress, or become non-comparable? Never reduce this to a hidden scalar or latest >= previous. Pause and flag any unresolved decision-bearing regression; use NOT_COMPARABLE when the criterion or evidence base changed.
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: ars-deep-research handoff (RQ Brief + Methodology Blueprint + Bibliography + Synthesis)
   -  cargo on every transition: exact builder-produced `preregistration-artifact/1.0` receipt and its named companion when provided; validate and carry byte-for-byte
   - Stage 2  --> 2.5: Pass complete paper to integrity_verification_agent
   - Stage 2.5 --> 3: Pass the Stage 2.5 paper to reviewer (verified, or carrying the recorded FAIL-loop partially-unverified warning)
   - Stage 3  --> 4: Pass Revision Roadmap to ars-academic-paper revision mode
   - Stage 4  --> 3': Pass revised draft, the hard-required original pre-revision draft ( current 1.1 §3.1 Phase 2A comparison base), exact author-adjudication sidecar, fully replayed Revision-Evidence Bundle, Response to Reviewers, Editorial Decision Letter, Round-1 findings, the immutable Roadmap, the exact ordered patch/report pairs projected by the bundle, and Round-1 Reviewer Configuration Cards. Missing original/roadmap/author/bundle is `manifest_incomplete`; this is the default contract re-review transfer. A user-requested fresh full review at 3' remains a separate full-mode branch.
   - Stage 3' --> 4': Pass new Revision Roadmap + R&R Traceability Matrix (Schema 11) to ars-academic-paper revision mode; the traceability sidecar (frozen `previously_missed`/`indeterminate` records,  §8) rides through 4' toward Stage 4.5
   - Stage 3' --> 4.5 (Accept/Minor direct path): Pass verified revised draft + the traceability sidecar's frozen records to integrity_verification_agent as gate input
   - Stage 4/4' --> 4.5: Pass revision-completed paper to integrity_verification_agent (final verification); on the Major-via-4' path the Stage 3' traceability sidecar travels along as gate input
   - Stage 4.5 --> 5: Pass the accepted final draft (verified, or carrying the recorded FAIL-loop partially-unverified warning) to the one mandatory Stage-5 entry checkpoint; run  then  against that same accepted artifact ID/SHA-256 before format-convert dispatch
   - Stage 5  --> 6: Pass final deliverables list + the Process-Summary projection of pipeline state history, omitting the  activity projection of terminal root `run_id`, pending/sealed activity fields, selected-store data, renderer output, and diagnostics (user may decline Stage 6 at the Stage 5 completion checkpoint)
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/guides/reinforcement_content.md for the full transition → reinforcement focus table.

---

Invocation Modes

ars-pipeline-orchestrator is the orchestrator skill that coordinates the full pipeline across 10 stages (delegating to ars-deep-research, ars-academic-paper, ars-academic-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): the user invokes one phase agent at a time across sessions, typically with the ARS_PASSPORT_RESET option enabled + resume_from_passport= (see references/guides/passport_as_reset_boundary.md).

In Mode B, single-phase agents in the downstream skills (ars-deep-research, ars-academic-paper, ars-academic-reviewer) stay strictly within their assigned phase for writes. The 5 agents in ars-pipeline-orchestrator itself are all cross-phase / meta by design — they have no fence by design:

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

Routing into Mode B requires an explicit user signal — naming the stage/mode or a [direct-mode] prefix. Ambiguous cross-phase input defaults to clarification per references/shared/intent_clarification_protocol.md. Critically: if pipeline_orchestrator_agent is dispatched on ambiguous cross-phase materials, the orchestrator itself cannot reconcile them — such cases route to clarification BEFORE the orchestrator runs.

Enforcement: Phase Boundary blocks on downstream single-phase agents; the multi-phase envelope + orchestrator structured intake remain forward-scope. Where the runtime supports automated pre-tool checks they may reinforce this boundary; otherwise the orchestrator enforces it by instruction.

---

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 reach a recorded terminal resolution before Stage 5: PASS, or — after the 3-round integrity FAIL loop is exhausted — an explicit, recorded user decision on the listed unresolved items (rationale requirements escalate on repeated overrides; see references/shared/compliance_checkpoint_protocol.md). Unresolved items are never silently dropped. Stage 4.5 performs a fresh from-scratch pass without relying on Stage 2.5 conclusions; this is not a claim of independent error processes.

⚠️ 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. No configuration flag silences this block; the only path past it is the recorded user acknowledgment above — a trust-based control with an audit trail. Stage 6 PROCESS SUMMARY then reports the full failure-mode audit log as part of the AI Self-Reflection Report.

See references/guides/integrity_review_protocol.md for the 5-phase citation/claim verification procedures. See references/guides/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 references/shared/compliance_checkpoint_protocol.md.

Tortured-phrase advisory

After the exact Stage 4.5 pass and immediately before Stage 5 formatting, the orchestrator runs the deterministic checker over the exact accepted working draft using an explicit user-supplied or synthetic-fixture snapshot and detached manifest bound to the raw snapshot SHA-256; omitted supply produces an explicit not_checked artifact. The path ships no native PPS content/importer/fetcher or redistributed phrase list and uses no live model, external API, human or model judge, or ambient clock; timestamps are explicit inputs. Its own-draft result is HEURISTIC-ADVISORY / UNMEASURED, never changes the Stage 4.5 PASS or Stage 5 gate, never rewrites prose, and must be re-run only after a revision has re-entered the existing integrity/screen sequence.

For the literature corpus, a non-in-place producer emits one current v1.2 advisory row per cited_title and cited_abstract; a missing abstract remains explicitly not_checked / unresolved with ABSTRACT_MISSING. Downstream consumers are read-only and compose every row into the one existing Bibliographic Integrity Advisories section. The advisory mints no marker, triggers no terminal policy, gate, finalizer promotion, ranking, citation rewrite, or replacement text, and supports no clean-draft, origin, papermill, contextual-validity, publisher-acceptance, or matcher-accuracy claim.

Cross-document consistency advisory

The Stage-1 shell-capable dispatcher is the only consumer that may invoke 自动校验脚本（移植版未附带，以文字规则为准） build-preregistration-artifact`. The non-shell research architect supplies only the caller declaration and named companion handle. The resulting exact sidecar and provided companion are replay-validated and carried byte-for-byte through every handoff. Omission, silent substitution, template replacement, or digest repair is invalid.

After the same exact Stage 4.5 PASS, the single mandatory Stage-5 entry checkpoint runs first and second. Both bind the identical accepted draft; input_binding.artifact.artifact_id/artifact_sha256 must equal input_binding.accepted_draft_artifact_id/accepted_draft_sha256. They remain separate carriers with separate failure semantics: preserve a schema-valid degraded artifact on exit 1; a contract/runtime failure writes no artifact and records only bounded ADVISORY_UNAVAILABLE:.

is always LLM-ADVISORY / UNMEASURED. It has no score, pass/fail, gate, readiness, authorization, ClaimIntent, rewrite, consent/protocol duplicate, or clean/agreement meaning. It cannot change Stage 4.5, block or delay the existing checkpoint, or alter Stage-5 routing after user confirmation. A manuscript revision stales both advisories and must re-enter integrity before and rerun, in that order, against the new accepted bytes.

---

Two-Stage Review Protocol

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

Stage 3' runs under the three-gate evidence-before-persuasion contract by default: the orchestrator emits a hash-bound input manifest, dispatches Phase 1 (criteria commitment, revision-blind) → Phase 2A (evidence verdict, persuasion-blind) → Phase 2B (claim matching, letter revealed), and invokes 自动校验脚本（移植版未附带，以文字规则为准） as a MANDATORY step before any decision surfaces — outcomes are Accept / Minor / Major, a user_review_required deferral, or a fail-closed abort (never Reject). The sidecar's frozen previously_missed/indeterminate new-issue records forward to Stage 4.5 on both routes. Legacy single-pass re-review requires the explicitly enabled ARS_RE_REVIEW_LEGACY option and is marked [LEGACY-NO-CONTRACT]. Authority: pipeline_orchestrator_agent.md § Stage 3' Re-Review Contract Dispatch + ars-academic-reviewer/references/guides/re_review_mode_protocol.md.

See references/guides/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/guides/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/guides/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 ars-academic-paper's max 2 revision rule: In the pipeline, revisions are limited to Stage 4 + Stage 4' (one round each), replacing ars-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

At the end of each revision round, suggest stopping only when no P0 issue remains, no unresolved decision-bearing regression remains, no applicable criterion has a substantive status change requiring another revision, and the author has no outstanding required action. Explain the criterion-bound basis; do not compute a score delta or treat small label-count changes as convergence. The user can override. Hard cap: 2 full revision loops (Stage 4 + Stage 4').

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

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.

---

Cross-run Adjudication Activity (; opt-in advisory side channel)

The state tracker section "Adjudication-activity metadata" is the single producer/state authority. Each run receives one stable explicit run_id. Structured handlers first durably apply their existing author-choice, compliance-override, explicit-request, or MANDATORY-checkpoint routing/state effect and only then best-effort append a data-minimized binding to the five-row pending_adjudication_activity_bindings[] inventory. A refused MANDATORY skip leaves state unchanged before the optional receipt stores skip_refused. Author groups use artifact_group_stage and may preserve both Stage 3 and Stage 3-prime; receipt stages use the complete Stage 1-through-6 closed enum, with no Stage 0. Compliance permits a plain report-only captured-zero group and requires the paired action receipt only for a fully qualifying override.

Terminal behavior is unchanged and runs first. After the completed/aborted state is durable, and only for a user-selected local store, the orchestrator passes explicit state/artifact-root paths and the explicit pending five rows to seal_terminal_inventory(state_path, artifact_root, pending_bindings), then best-effort runs sealed-inventory build-input, idempotent append-run, and optional render. The helper computes hashes; it does not read pending state, accept caller hashes, infer sources, or scan. Root run_id plus sealed root adjudication_activity_sources are exact authority. Any activity failure is an advisory diagnostic and cannot affect the already-durable terminal outcome.

Activity data never enters a Material Passport, handoff, Process Record, reviewer/model/observer/compliance input, gate, verdict, checkpoint input, or stage transition. No live model, judge, eval, network/API, ambient clock, directory scan, or glob participates. Full details and frozen receipt schemas remain in 对应设计文档（移植版未附带） and references/shared/contracts/activity/.

---

Auditability and replay boundaries

Pipeline artifacts are versioned, hashed, and auditable. Deterministic validators can be replayed against the same bytes and configuration. LLM-generated prose and semantic judgements are stochastic and are not byte-reproducibility guarantees; record model/configuration and evidence so differences can be inspected.

See references/guides/reproducibility_audit.md for the standardized workflow contract, deterministic replay boundary, 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.

Terminal semantics: Stage 6 is non-mandatory — the user may decline it at the Stage 5 completion checkpoint (Stage 6 marked skipped; the pipeline still terminates completed). When it runs, after the process record is delivered the orchestrator prompts for a terminal acknowledgement — finish / end / done / confirm, or an unambiguous natural-language equivalent that accepts the deliverables. On acknowledgement, Stage 6 is marked completed and the pipeline global state is set to completed; change requests (the other language version, content corrections) keep Stage 6 in_progress and are not acknowledgements. See references/guides/pipeline_state_machine.md § Stage 6 terminal semantics.

See references/guides/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 during Stage 6 record compilation (the whole-pipeline pass runs before the Process Record is generated and delivered, so its output can be a chapter of the record the user acknowledges). 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 (during Stage 6 record compilation), scores the pattern against the canonical rubric at references/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: