Argument Self-loop (write -> self-check -> ledger -> revise)#

Purpose: upgrade C5 from “generate text” to “execute argument actions under explicit constraints”.

This skill operationalizes the mechanism you described as a reusable, pipeline-native component:

• write section-by-section
• self-check paragraph-by-paragraph
• maintain a small argument ledger that makes dependencies explicit
• revise only what fails until the chain is continuous

It complements (not replaces) the other self-loops:

• evidence-selfloop: blocks writing when packs are not writeable (do not pad)
• writer-selfloop: blocks template voice, missing sections/leads, scope/citation violations
• argument-selfloop (this skill): blocks argument discontinuity and premise drift (even when prose is fluent)

Core idea: two intermediate artifacts (never in the paper)#

This skill treats “argument structure” as a first-class intermediate artifact, like evidence packs.

Outputs:

• output/SECTION_ARGUMENT_SUMMARIES.jsonl (structured; per-section/per-paragraph argument moves)
• output/ARGUMENT_SKELETON.md (compact narrative + dependency map; not a prose restatement)
• output/ARGUMENT_SELFLOOP_TODO.md (PASS/FAIL + actionable edits)

These files are not reader-facing and must never be merged into output/DRAFT.md.

Downstream:

• paragraph-curator uses output/SECTION_ARGUMENT_SUMMARIES.jsonl (moves/outputs) + the ## Consistency Contract to run a controlled select->evaluate->subset->fuse pass without changing citation keys.

What this self-loop enforces (your 3 invariants)#

After you complete a section (H3 or key front matter), the section must satisfy:

1. Correct narrative linkage (paragraph-to-paragraph)

• the relation between adjacent paragraphs is explicit (cause/contrast/refinement/boundary)
• no silent topic-switch; no “jump cut”

1. Closed argument loop (section-level) The section answers, in its own text (not in a hidden outline):

• what question is it resolving?
• what argument path does it take?
• what is the conclusion?
• what premises does the conclusion rely on?

1. Premises + definitions are explicit and stable

• new terms / protocol assumptions are defined at first use
• the definition matches global usage (no drift)
• task/metric/constraint assumptions do not silently change across sections

The self-check must result in concrete edits: add a missing definition, add a bridge sentence, add an explicit contrast, add a scope boundary, delete/reorder a paragraph, or strengthen the local conclusion.

Paragraph contract (argument actions)#

Every paragraph must execute at least one argument action and be locally self-consistent. Use this action set (can be combined, but never empty):

• Claim: a testable judgement/conclusion (avoid generic background)
• Definition/Setup: introduce a concept, assumption, task definition, protocol, comparison set
• Justification: reasoning chain or evidence support (including citations)
• Contrast/Differentiation: clarify differences, remove ambiguity
• Boundary/Failure: applicability limits, failure modes, threats to validity
• Local Conclusion: a reusable takeaway / constraint that downstream paragraphs can rely on

One-sentence self-check (per paragraph):

• "This paragraph’s action(s) are: <…>. Its output is: <…>."

If you cannot answer, the paragraph must be rewritten/merged/split until the action and output are clear.

How to run it (LLM-first workflow)#

1. Pick the scope of this pass

• default: run it after writer-selfloop PASS, before merge
• incremental: run it after finishing 1-2 H3s, so you catch drift early

1. For each target section file (start with H3 bodies)

• read the section
• do a paragraph-by-paragraph action labeling in the ledger, not in the prose
• identify failures (missing definition, missing bridge, missing conclusion, implicit premise)
• apply the fix to the section file ( sections/S<sub_id>.md) without changing citation keys

1. Update the two-level ledger

• write/update the record for that section in output/SECTION_ARGUMENT_SUMMARIES.jsonl

• update output/ARGUMENT_SKELETON.md so it reflects:

  • the section’s functional role in the paper
  • what premises it consumes
  • what conclusions/definitions it produces for downstream sections

1. Write output/ARGUMENT_SELFLOOP_TODO.md

• - Status: FAIL + a list of concrete edits when any section fails
• - Status: PASS only when all required sections are coherent and premises are stable

1. Rerun until PASS

Output contract#

output/ARGUMENT_SELFLOOP_TODO.md#

Must exist and start with:

• - Status: PASS|FAIL

Recommended structure (keep it short and debuggable):

• ## Failures (blocking)
• ## Fix plan (actionable edits) (per file)
• ## Premise drift watchlist (non-blocking)

output/SECTION_ARGUMENT_SUMMARIES.jsonl#

JSONL (one record per section/subsection).

Required fields per record:

• kind: h3 | front_matter | discussion | conclusion (minimal set)

• id: for H3 use the subsection id (e.g., "3.2")

• title

• section_id, section_title (for H3)

• section_role: what this unit does in the paper (e.g., mechanism, evaluation_lens, risk_lens, synthesis)

• depends_on: list of premises/definitions it assumes

• adds: list of premises/definitions/conclusions it introduces

• paragraphs: list of objects, each with:

  • i (1-based paragraph index)
  • moves (non-empty list; pick from: claim, definition_setup, justification, contrast, boundary_failure, local_conclusion)
  • output (one sentence: what this paragraph produces)

Notes:

• This is an intermediate ledger: short, structural, no prose restatement.
• Do not paste long sentences from the draft. Use short summaries.

output/ARGUMENT_SKELETON.md#

A compact narrative/dependency map (not a retelling of the paper).

It should include:

• each H2/H3's necessity (what gap it fills)

• explicit dependencies (premises consumed, outputs produced)

• a global Consistency Contract section (single source of truth) that must not drift across edits:

  • canonical terminology + synonym policy (what to call the same thing)
  • task/environment/threat-model boundary (what counts as in-scope)
  • evaluation protocol fields that make numbers interpretable (task + metric + constraint/budget/tool access)
  • comparison set naming policy (baseline families; avoid drifting labels)

Minimum format requirement:

• output/ARGUMENT_SKELETON.md must contain a heading line: ## Consistency Contract

Change rule (regression trigger):

• If you change any definition/protocol assumption/term naming, update the Consistency Contract first, then revise the affected sections/*.md to match, and rerun this self-loop until PASS.

Keep it "writer-facing": no reader signposting, no “in this section we…”.

Routing rules (avoid polishing around missing substance)#

• If a section cannot produce a justified claim without new evidence: STOP and route to evidence-selfloop.
• If a section fails due to template voice / missing citations / out-of-scope keys: route to writer-selfloop / citation-* first.
• This skill is for argument continuity and premise hygiene, not for adding new facts.

Script (generator + validator)#

This skill includes a validator script so the pipeline can block on missing ledgers. It does not write paper prose, but it does generate the required ledger artifacts from existing sections/*.md files and then validates coverage/consistency.

Quick Start#

• python scripts/run.py --workspace workspaces/<ws>

All Options#

• --workspace <dir>
• --unit-id <U###>
• --inputs <semicolon-separated>
• --outputs <semicolon-separated>
• --checkpoint <C#>

Examples#

• Validate the ledgers exist + are PASS + cover all H3:
  • python scripts/run.py --workspace workspaces/<ws>