klappy · klappy · Apr 17, 2026 · Apr 17, 2026
diff --git a/docs/oddkit/evidence/challenge-governance-articles-commit.md b/docs/oddkit/evidence/challenge-governance-articles-commit.md
@@ -0,0 +1,91 @@
+# Gauntlet Evidence — Challenge Governance Articles Commit
+
+**Branch:** `feat/challenge-governance-articles`
+**Date:** 2026-04-17
+**Scope:** 11 new governance articles under `odd/challenge-types/` and `odd/challenge/`
+**Deliverable type:** Canon documents (governance only — no code, no UI, no runtime behavior change)
+
+---
+
+## Definition of Done — Evidence
+
+### 1. Change Description
+
+Eleven governance articles committed to klappy.dev canon, setting up the oddkit_challenge refactor to mirror the PR #96 encode pattern (governance-driven via extraction contract rather than hardcoded source logic).
+
+- 1 meta governance article: `odd/challenge-types/how-to-write-challenge-types.md`
+- 4 software-engineering default challenge types: `strong-claim`, `proposal`, `assumption`, `observation` (fallback)
+- 3 architectural-writing overlay challenge types: `pattern-coinage`, `comparative-positioning`, `principle-extraction`
+- 3 supporting articles: `base-prerequisites`, `normative-vocabulary`, `stakes-calibration`
+
+### 2. Verification Performed
+
+- `oddkit_preflight` surfaced three constraint documents to check against: `canon/constraints/ai-voice-cliches.md`, `canon/constraints/author-identity-language.md`, `canon/constraints/definition-of-done.md`
+- AI voice clichés audit via grep against new articles for formulaic transitions, puffing, overclarification, summary clichés, bold-then-explain, and em-dash clustering
+- Em-dash density compared against precedent `odd/encoding-types/how-to-write-encoding-types.md`
+- Author identity language audit (no identity claims about Klappy in any article)
+- `derives_from` path audit — every referenced path checked against repo filesystem
+- Writing Canon checklist (8 tests) applied per-article: title test, blockquote test, metadata test, summary test, header scan test, no buried claims, axiom space test, ghost writer test
+- Header scan output reviewed for each representative article
+
+### 3. Observed Behavior
+
+- AI voice clichés audit: zero hits on formulaic transitions, puffing, overclarification, summary clichés, bold-then-explain
+- Em-dash density: new articles average 0.04–0.16 per line; precedent meta averages 0.11 per line — same neighborhood, no ticced clustering
+- All 11 articles contain the required `## Summary — [subtitle]` section after the blockquote
+- Header scan confirmed headers tell each document's story in sequence (no "Background / Discussion / Conclusion" generic forms)
+- `derives_from` paths: all verified against repo except one caught error — `canon/epistemic-modes.md` corrected to `canon/definitions/epistemic-modes.md` in `stakes-calibration.md`
+
+### 4. Evidence Produced
+
+This file. Plus the git diff (11 new files under `odd/challenge-types/` and `odd/challenge/`). Plus the session journal at `/home/claude/session-journal-challenge-refactor.md` capturing the full DOLCHE derivation: 1 Decision, 4 Learnings, 1 Constraint, 1 Handoff.
+
+Visual proof: **N/A — no UI/interaction/layout change.** These are canon governance documents rendered by existing klappy.dev article templates (same as `odd/encoding-types/*` articles already in production). No new rendering path, no new visible state.
+
+### 5. Self-Audit Completed
+
+- **Intended outcome:** klappy.dev canon contains a complete governance set that the future `workers/src/orchestrate.ts` refactor can extract against — governance articles first, code refactor second, matching PR #96 order.
+- **Constraints applied:** Writing Canon (progressive disclosure, summary sections, descriptive headers), AI voice clichés (no clustering of AI tells), author identity language (no translator claims about Klappy), definition-of-done (this file), frontmatter schema (booleans/integers/dates unquoted, strings with special chars quoted).
+- **Decision rules followed:** mirror the PR #96 encode pattern; ship software-engineering defaults labeled honestly; use base-plus-overlay for prerequisites; multi-match semantics by design; governance before code.
+- **Tradeoffs:** the defaults are software-flavored on purpose (alternative was "generic human-language defaults" that would serve every domain badly); both software and writing modes coexist in single supporting articles (alternative was separate canons per mode — heavier, not yet justified); no `## Summary` was originally drafted — caught by Writing Canon gate and remediated before commit.
+- **Remaining risks:** detection-pattern overlap between new architectural-writing types and existing software types may produce noisier multi-matches until stakes-calibration trims by mode; `Priority` field semantics in Type Identity are under-specified for display ordering (flagged in session journal); no integration test against the live challenge tool yet — that comes with the workers/src/orchestrate.ts refactor.
+
+---
+
+## Writing Canon Gate — Per-Article Results
+
+| Article | Title test | Blockquote test | Summary section | Header scan |
+|---|---|---|---|---|
+| how-to-write-challenge-types.md | ✓ | ✓ | ✓ | ✓ |
+| strong-claim.md | ✓ | ✓ | ✓ | ✓ |
+| proposal.md | ✓ | ✓ | ✓ | ✓ |
+| assumption.md | ✓ | ✓ | ✓ | ✓ |
+| observation.md | ✓ | ✓ | ✓ | ✓ |
+| pattern-coinage.md | ✓ | ✓ | ✓ | ✓ |
+| comparative-positioning.md | ✓ | ✓ | ✓ | ✓ |
+| principle-extraction.md | ✓ | ✓ | ✓ | ✓ |
+| base-prerequisites.md | ✓ | ✓ | ✓ | ✓ |
+| normative-vocabulary.md | ✓ | ✓ | ✓ | ✓ |
+| stakes-calibration.md | ✓ | ✓ | ✓ | ✓ |
+
+---
+
+## OLDC+H — Session Capture Reference
+
+Full DOLCHE capture at `session-journal-challenge-refactor.md`. Summary:
+
+- **D** — challenge-refactor-full-governance-drafted: commit 11 articles mirroring PR #96 encode pattern
+- **L** — framework-agnostic-defaults-are-not: the extraction contract is domain-agnostic but default articles are not, and labeling them honestly serves every domain better than pretending they are neutral
+- **L** — voice-dump-mode-is-a-feature: suppressing challenge in voice-dump mode preserves raw thought flow
+- **L** — tim-complaint-surfaces-architectural-insight: software-verbiage complaint was a structural signal that the framework needed domain-adaptation as a first-class capability
+- **L** — klappy-two-modes-same-kb: operator mode and architectural-writing mode coexist in klappy.dev canon via multi-match and shared supporting articles
+- **C** — voice-dump-suppression-invariant: the tool must not interfere with raw thought capture
+- **H** — challenge-refactor-code-next: implement extraction contract in `workers/src/orchestrate.ts` mirroring PR #96 after this commit merges
+
+---
+
+## Version Tracking
+
+- Branch: `feat/challenge-governance-articles`
+- Post-merge: ledger entry capturing E0008 challenge-governance milestone
+- Related PRs: depends-on conceptually from PR #96 (governance-driven encode); precedes future PR for `workers/src/orchestrate.ts` challenge refactor
diff --git a/odd/challenge-types/assumption.md b/odd/challenge-types/assumption.md
@@ -0,0 +1,73 @@
+---
+uri: klappy://odd/challenge-types/assumption
+title: "Challenge Type: Assumption"
+audience: docs
+exposure: nav
+tier: 2
+voice: neutral
+stability: semi_stable
+tags: ["odd", "oddkit", "challenge", "challenge-type", "assumption"]
+epoch: E0008
+date: 2026-04-16
+derives_from: "canon/constraints/epistemic-challenge.md, odd/challenge-types/how-to-write-challenge-types.md"
+governs: "oddkit_challenge behavior for assumption type"
+status: active
+---
+
+# Challenge Type: Assumption
+
+> An implicit premise treated as established. Assumptions are dangerous precisely because they are not examined — the work built on top of them silently inherits their uncertainty. Pressure here is about making the premise explicit and naming what would validate or invalidate it.
+
+---
+
+## Summary — Make The Implicit Explicit Before It Compounds
+
+This type fires when an input rests on an unexamined premise — `assume`, `since`, `because`, `given that`, `of course`, `naturally`. Assumptions are the silent structural risks: if the premise is wrong, every claim built on top inherits the error. The challenge asks whether the assumption has been validated, what breaks if it is wrong, whether it is documented or merely implicit, and when it was last verified. Prerequisites check that the assumption is marked for validation, that its breakage impact is considered, and that its source is named. The goal is to surface the assumption from the background of the argument into the foreground, where it can be tested or explicitly accepted.
+
+---
+
+## Type Identity
+
+| Field | Value |
+|---|---|
+| Slug | assumption |
+| Name | Assumption |
+| Priority | medium |
+
+---
+
+## Detection Patterns
+
+```
+assume, assuming, presume, given that, since, because, if we, taking for granted, it's obvious that, naturally, of course
+```
+
+---
+
+## Challenge Questions
+
+| Question | Stakes tier |
+|---|---|
+| Has this assumption been validated with evidence? | baseline |
+| What if this assumption is wrong — what breaks? | baseline |
+| Is this assumption documented or just implicit? | elevated |
+| When was this last verified against reality? | elevated |
+| Is this a universal assumption or context-specific? | rigorous |
+
+---
+
+## Prerequisite Overlays
+
+| Prerequisite | Check | Gap message if missing |
+|---|---|---|
+| validation-marked | input contains "test", "verify", "validate", "check", "confirm" | "Assumption not marked for validation — assumptions without tests compound silently" |
+| breakage-considered | input contains "if wrong", "break", "fail", "impact", "depends on" | "Dependency on this assumption not named — what else falls if this is false?" |
+| source-of-assumption | input contains "from", "based on", "per", "according to", "historically" | "Source of the assumption not named — is this documented, observed, or inherited?" |
+
+---
+
+## Suggested Reframings
+
+- Make explicit: "We are assuming X; we believe it because Y; we would test it by Z"
+- Reframe as known-unknown: "X is assumed but unverified; impact if false is W"
+- Promote to hypothesis: "Assumption X is treated as true until evidence from test T says otherwise"
diff --git a/odd/challenge-types/comparative-positioning.md b/odd/challenge-types/comparative-positioning.md
@@ -0,0 +1,76 @@
+---
+uri: klappy://odd/challenge-types/comparative-positioning
+title: "Challenge Type: Comparative Positioning"
+audience: docs
+exposure: nav
+tier: 2
+voice: neutral
+stability: semi_stable
+tags: ["odd", "oddkit", "challenge", "challenge-type", "comparative-positioning", "writing-analysis"]
+epoch: E0008
+date: 2026-04-16
+derives_from: "canon/constraints/epistemic-challenge.md, odd/challenge-types/how-to-write-challenge-types.md"
+governs: "oddkit_challenge behavior for comparative-positioning claims — positioning work against a landscape of other work"
+status: active
+---
+
+# Challenge Type: Comparative Positioning
+
+> A claim that locates this work against other work — existing approaches, adjacent projects, viral repositories, published papers, competing frameworks. Comparative positioning lives or dies on whether the comparison target is characterized honestly and freshly. The failure mode is strawmanning, selective citation, or comparing against a stale snapshot of something that has since evolved.
+
+---
+
+## Summary — Honest Comparison Requires Fair Characterization And Current Evidence
+
+This type fires when an input positions work against a landscape — `unlike`, `similar to`, `existing approaches`, `in contrast to`, `prior work`, `state of the art`. The challenge asks whether the comparison target is fairly represented or strawmanned, whether the snapshot is current, whether the strongest version of the compared work was engaged, what each approach is actually trying to solve, and whether a better comparison exists that was overlooked. Prerequisites check that the target is specifically named, that it is actually described (not just alluded to), that freshness is established, and that shared ground is acknowledged before differences. The goal is to keep comparative claims honest against both the comparison target and the reader who may know that target better than the writer does.
+
+---
+
+## Type Identity
+
+| Field | Value |
+|---|---|
+| Slug | comparative-positioning |
+| Name | Comparative Positioning |
+| Priority | high |
+
+---
+
+## Detection Patterns
+
+```
+unlike, similar to, where x differs, existing approaches, the difference from, as opposed to, compared to, in contrast to, other frameworks, unlike other, what makes this different, prior work, state of the art, comparable to
+```
+
+---
+
+## Challenge Questions
+
+| Question | Stakes tier |
+|---|---|
+| Is the comparison target fairly represented or characterized in its weakest form? | baseline |
+| When was the comparison target last examined? Has it changed since? | baseline |
+| Have you engaged the strongest version of the compared work, or the most convenient? | elevated |
+| What is the compared work trying to solve that yours isn't, and vice versa? | elevated |
+| If the author of the compared work read this, would they recognize their own work in your description? | rigorous |
+| Are you missing an adjacent work that would be a better comparison than the one you chose? | rigorous |
+
+---
+
+## Prerequisite Overlays
+
+| Prerequisite | Check | Gap message if missing |
+|---|---|---|
+| comparison-target-named | input contains a proper-noun reference to the compared work (project name, author, paper, repo) | "Comparison target not specifically named — 'existing approaches' is not a comparison" |
+| target-accurately-characterized | input contains "their approach", "they do", "their design", "the x approach" with descriptive content | "Compared work not actually described — contrast requires describing what is being contrasted" |
+| freshness-verified | input contains a date, version, or recency marker ("as of", "current", "recent", "latest", year) | "Freshness of the comparison not established — comparisons against stale snapshots are misleading" |
+| shared-ground-acknowledged | input contains "similarly", "shared", "in common", "both", "where we agree" | "No shared ground acknowledged — honest comparison names similarities before differences" |
+
+---
+
+## Suggested Reframings
+
+- Reframe with fairness: "X and my approach share A and B; they diverge on C, where X does Y and I do Z"
+- Reframe with recency: "As of [date/version], X does Y; I'm aware this may have changed"
+- Reframe with humility: "I may be mischaracterizing X; the claim holds against my reading of their docs as of [date]"
+- Reframe to acknowledge strongest version: "The strongest defense of X is A; my claim is that even granting A, Z still holds"