Challenge Stakes Calibration

This article governs how the mode parameter on oddkit_challenge filters output. Nine modes coexist: software-engineering modes (exploration, planning, execution) from canon epistemic-modes, and architectural-writing modes (voice-dump, drafting, peer-review-ready, canon-tier-2, canon-tier-1, published-essay) from the klappy.dev writing lifecycle. Each mode names which question tiers to surface (baseline, elevated, rigorous), how strict prerequisite checking is (optional, required, required-plus-source-named), and whether reframings surface (none, first one, all, all-plus-block-until-addressed). Voice-dump mode suppresses all challenge output as a structural invariant — some modes exist for getting thoughts out of the head, and pressure-testing at that stage damages the mode. Default is planning when no mode is supplied. If this article is absent, the server surfaces everything at every mode — challenge without calibration is still challenge, just uniformly loud.

Software Engineering Modes (canon epistemic-modes)

• exploration — widening the space of ideas. Heavy challenge here kills good ideas before they mature.
• planning — narrowing to a path. This is where tradeoffs get examined.
• execution — committing. The cost of being wrong is highest; scrutiny is highest.

Architectural Writing Modes (klappy.dev writing lifecycle)

• voice-dump — raw thinking, transcribed. Challenge here is counterproductive; suppress and let thought flow.
• drafting — shaping a voice-dump into an argument. Light challenge only.
• peer-review-ready — the draft is leaving the author's head and entering review. Baseline and elevated checks apply.
• canon-tier-2 — content is being added to canon but not as a load-bearing foundation. Same treatment as peer-review-ready.
• canon-tier-1 — content will be load-bearing for future work. Rigorous treatment including source-named strictness.
• published-essay — the work is going to an external audience, including hostile readers. Maximum scrutiny, including reframings as block-until-addressed so the author explicitly chooses to publish despite any open gaps.

This table uses three tiers: baseline, elevated, rigorous. Challenge-type articles assign each question to a tier in their ## Challenge Questions table. Tier names are coordinated across this article and every type article — if this article changes the tier names, type articles must follow.

The mode voice-dump surfaces none — the tool suppresses all challenge questions regardless of which types matched. This is a feature: some modes are for getting thoughts out of the head, and pressure-testing at that stage damages the very function of the mode.

• optional (warn only): Missing prerequisites produce advisory notes; the challenge does not flag them as blocking.
• required (gap messages): Missing prerequisites produce explicit gap messages in the response.
• required plus source-named: All required gaps surface, plus the source-named check is escalated from advisory to blocking. When stakes are high, sources matter.

• none: No reframings surface. Used for voice-dump mode.
• first 1: Only the first reframing from each matched type is surfaced. Keeps exploration and drafting unhurried.
• all: All reframings from all matched types surface, deduped.
• all, plus block-until-addressed: All reframings surface, and the response includes a posture marker indicating the claim should not proceed until reframings are addressed or explicitly declined.

When the mode parameter is not provided, the server defaults to planning with a low-confidence marker. This matches existing behavior and keeps calibration safe-by-default: neither too loose (exploration) nor too strict (execution) when the caller hasn't said which mode they're in.

If this article is absent entirely, the server surfaces every question at every mode, runs prerequisites as advisory, and surfaces all reframings. Challenge without calibration is still challenge — it is just uniformly loud.

The software-engineering modes and the architectural-writing modes coexist in one table because klappy.dev canon supports both kinds of work. A KB with a single-domain workflow can prune to its own set.

A KB whose workflow uses different lifecycle stages (ideation / design / build / ship for product development; note-taking / drafting / teaching-material for thought leadership from books; drafting / community-check / consultant-check / publication for Bible translation) can rename modes here — the server treats mode names as strings matched against the mode parameter.