Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Campaign Workflows

Campaigns are the recommended way to run bulk compliance operations across multiple controls, policies, or scope questions. They replace manual one-at-a-time updates with a coordinated prepare-claim-propose-apply lifecycle.

When to Use Campaigns

  • Initial control implementation — Draft narratives and evidence for an entire control family
  • Fixing review findings — Address issues flagged by family or policy reviews
  • Answering questionnaires — Bulk-answer policy or scope questions
  • Issue remediation — Fix controls flagged by platform issues

Campaign Lifecycle

Prepare → Claim → Draft → Propose → Apply
  1. Prepare — Snapshot platform state and create a checkpoint file. This captures the current state of all target items so the campaign works from a consistent baseline.

  2. Claim — Lease items for drafting. TTL-based leases prevent concurrent editing when multiple agents are working in parallel.

  3. Draft — For each claimed item, get full context (control requirements, current state, guidance) and produce a draft.

  4. Propose — Submit drafts as proposals without writing to the platform. This provides a review opportunity before any changes are persisted.

  5. Apply — Push all accepted proposals to the platform as a single operation.

Apply is safe to retry: each create write carries an idempotency key derived from the checkpoint’s per-run run_id, so a resumed run replays writes the platform already committed instead of duplicating them. See Idempotency and Replay.

External Agent Pattern

Campaigns are designed for external agents (Claude Code, Codex, Cursor, etc.) operating through MCP:

Agent A: prepare_campaign → claim_campaign_items → get_campaign_item_context → submit_campaign_proposal
Agent B: claim_campaign_items → get_campaign_item_context → submit_campaign_proposal
...
Coordinator: get_campaign_status → apply_campaign

The checkpoint file enables independent agent execution. Agents can claim non-overlapping items and work in parallel.

CLI Usage

Campaigns are preview by default. Without --apply, a run prepares, claims, drafts, and checkpoints — it prints the proposals and writes the checkpoint file but persists nothing to the platform. Add --apply to push accepted proposals.

Modes are per domain, and a mode from the wrong set is rejected:

CommandValid --mode values
campaign controlsinitial, issues-fix, notes-fix, review-fix
campaign policyanswer, review-fix
campaign scopeanswer, review-fix

All three commands also accept --checkpoint, --concurrency, --max-retries, and --output (auto, live, compact, json).

Control Campaign

# Draft narratives for the Access Control family
pretorin campaign controls --mode initial --family AC \
  --system "My System" --framework-id fedramp-moderate

# Fix controls flagged by open issues
pretorin campaign controls --mode issues-fix --all-open-issues \
  --system "My System" --framework-id fedramp-moderate

# Fix controls flagged by review
pretorin campaign controls --mode review-fix --family AC --review-job <job-id> \
  --system "My System" --framework-id fedramp-moderate

# Auto-apply after completion
pretorin campaign controls --mode initial --family AC --apply \
  --system "My System" --framework-id fedramp-moderate

Policy Campaign

# Answer all incomplete policy questions
pretorin campaign policy --mode answer --all-incomplete

# Fix review findings for a specific policy
pretorin campaign policy --mode review-fix --policies <policy-id>

Scope Campaign

# Answer scope questions
pretorin campaign scope --mode answer \
  --system "My System" --framework-id fedramp-moderate

# Fix scope review findings
pretorin campaign scope --mode review-fix \
  --system "My System" --framework-id fedramp-moderate

Check Status

campaign status reads the run’s state from its checkpoint file, so --checkpoint is required and there is no active-context fallback. When the campaign command was run without --checkpoint, the checkpoint is written to a timestamped default path — .pretorin/campaigns/<domain>-<mode>-<YYYYMMDD-HHMMSS>.json — and the prepared-run output prints the exact pretorin campaign status invocation to use.

# Pass an explicit checkpoint path so the follow-up command is predictable
pretorin campaign controls --mode initial --family AC \
  --system "My System" --framework-id fedramp-moderate \
  --checkpoint .pretorin/campaigns/ac-initial.json

pretorin campaign status --checkpoint .pretorin/campaigns/ac-initial.json

MCP Tool Sequence

For AI agents working through MCP:

  1. get_workflow_state — Understand what needs work
  2. get_pending_families — Identify target families
  3. prepare_campaign — Create the campaign
  4. claim_campaign_items — Claim items
  5. get_campaign_item_context — Get context per item
  6. submit_campaign_proposal — Submit drafts
  7. get_campaign_status — Review progress
  8. apply_campaign — Push to platform