> The complete Setup Score scoring rubric, published so you can score
> yourself by hand or check our arithmetic. This is the file the product
> actually uses.

# Scoring rubric: the 100-point Claude setup maturity score

Setup Rubric v1.2, reviewed 2026-08-04, tested against Claude Code,
Claude Desktop and claude.ai Projects.

Read by the insight-report generator (Phase 1), the pack's own scoreboard,
and later the benchmark (post-MVP). One rubric, two modes, stated honestly.

## The scale

| Band | Score | Reads as |
|---|---|---|
| Ad hoc | 0 to 20 | Chats from scratch; nothing persists between sessions |
| Emerging | 21 to 40 | Some saved prompts or notes; no durable system |
| Systematic | 41 to 60 | Operating manual and project context exist; memory partial |
| Compounding | 61 to 80 | Memory, rituals and first skills in daily use |
| Productised | 81 to 100 | Workflows encoded, automated where safe, deployable to others |

Category weights (must always sum to 100 before renormalisation):
foundation 24, memory-context 22, skills 10, integrations 10,
productisation 14, advanced 6, control 14.

**Renormalisation**: when personalisation excludes a category (for example
productisation when `productisation_intent != yes`), the remaining categories
scale to 100: `score = raw x (100 / included_weights_sum)`, rounded to the
nearest integer. The report states which categories were excluded and why.
Control is never excluded.

## Mode A: interview-estimated (the insight report)

Computed from profile fields alone; self-report, so the report gives the
BAND plus a range of plus or minus one band boundary, never a false-precision
single number, and says plainly: "estimated from your answers; the pack's
audit runbooks verify it on your machine."

Per-category evidence rows; each row scores its listed points if the profile
supports it, 0 if not, and half if partial or unclear. Exception: on control
rows, an answer that describes no recognised safeguard scores 0, not half
(control holds the top two bands, so a vague answer must never outscore the
honest bottom option).

**Foundation (24)**
- Global CLAUDE.md exists and is a real operating manual: 7
  (global_claude_md present with summary; else session habits imply one: 3.5)
- Per-project context exists: 6 (project_claude_md_count >= 1, or
  project_context_files == yes)
- Workspace under version control or deliberate sync: 3.
  Mode A excludes this row: no interview answer reaches it and a browser
  cannot inspect a workspace, so it is verified by the pack's audit
  runbook in Mode B rather than scored from self-report.
- Account situation understood; if multiple, continuity practised: 3
  (one account, or multiple with no governance_flag confusion: full;
  multiple with a governance flag outstanding: 1.5)
- Baseline sanity (settings known, skills folder exists): 5
  (skills_installed not unavailable: half; count >= 1: full).
  Mode A excludes this row on the same grounds: both branches need an
  inspection this context never has.

**Memory-context (22)**
- Session-end habit persists knowledge: 10
  (session_end_habit: nowhere 0, notes 3, files 5, claude_md 7, system 10)
- Context re-established from files, not re-explaining: 7
  (from files: full; pasting old chats, or answered but unclear: 3.5;
  re-explaining from scratch: 0)
- Long-term archive of decisions exists in any form: 5
  (system-level memory: full; files or CLAUDE.md, not confirmed as an
  archive: 2.5)

**Skills (10)**
- Any skill or reusable encoded workflow installed: 5
  (skills_installed >= 1, or working_today includes a saved reusable
  prompt: 2.5)
- A recurring deliverable runs the same way every time: 5
  (working_today has 1 or more genuinely recurring entries)

**Integrations (10)**
- Core tools connected to Claude at all: 5
  (share of core_tools with a connection: none 0, some 2.5, most 5).
  Not applicable by design: keeping Claude deliberately away from these
  tools excludes this row (see the row-exclusion rule below).
- Ownership and auth known per connection: 5
  (credential_hygiene described with locations: full; secrets seen in
  chats: 0 on this row regardless)

**Productisation (14)** (excluded unless productisation_intent == yes)
- A workflow named and deployable in principle: 5 (next_candidate or
  productisation target named)
- Any runbook, intake or checklist already written down: 5
  (memory habit implies documents exist: full; recurring work reported
  without them: 2.5)
- A first customer identified: 4
  (customer named: full; a detailed intent without a named customer: 2)

**Advanced (6)**
- Sub-agents, scheduled runs or headless use in practice: 6
  (reported real use: full; aware but unused: 2)

**Control (14)** (never excluded)
- Client and project work kept separate: 5
  (strictly separate, each client or project in its own space: full;
  mostly separate with shared chats: 2.5; one shared stream: 0).
  Not applicable by design: only ever one client or project context
  excludes this row.
- Work reviewed before it ships: 5
  (checked against a written definition of done, everything read and
  corrected first, or work that never leaves its author: full;
  high-stakes work reviewed while routine ships as produced: 2.5;
  ships as produced: 0). No not-applicable option: work that stays with
  its author scores full rather than excluding the row, so the category
  always keeps at least this row.
- A way back exists when a change goes wrong: 4
  (version control or backups, could roll back: full; partial backups: 2;
  reconstructing from memory: 0). Not applicable by design: Claude never
  changes files or systems excludes this row.

## Not applicable by design (row exclusion and renormalisation)

Some rows can be not applicable by design: staying unconnected, a single
working context, or no write surface can be a deliberate choice rather
than a gap. Choosing that option is evidence of a decision, not a skip.
The row is excluded: it appears in the report with a note, but counts
towards neither the points nor the denominator. The category then
renormalises over its remaining rows:

    remaining_max  = sum of max over rows not excluded
    category score = min(weight, points x (weight / remaining_max))

so a deliberate minimalist scores the same as an equivalent adopter on
the rows that remain. Client-chosen exclusion comes only from choosing
the explicit option in the interview; a typed answer never excludes a
row. Separately, Mode A excludes the two foundation rows named above for
every client, because no answer to the interview can reach them; the same
formula applies, over a foundation remaining_max of 16.

## The capability band cap

The top two bands, Compounding and Productised, require control to reach
at least half its weight: 7 of 14, measured after any row renormalisation.
When the arithmetic lands in either band with control below 7, the numeric
score stands as computed but the band is held at Systematic, the stated
range runs from Emerging up to the band the arithmetic reached, and the
report carries the verdict "High capability, exposed controls". Vague
typed answers cannot clear the cap: unrecognised text scores 0 on control
rows.

## Mode B: audit-verified (after the pack runs)

The pack's audit runbooks each end in a findings report with the category's
rubric applied on evidence (the v0 kit pattern). The verified score is the
sum of those evidence-scored criteria across the category audits, under the
same category-inclusion and renormalisation rules as Mode A. The pack's
scoreboard separately sums ticked tasks' points; that number is pack
progress, not the verified score, and completing a task is not the same
measurement as proving a maturity condition. Rule carried from the kit:
anything not determinable is scored 0 and marked "unavailable", never
guessed.

## Top-gaps selection (for the insight report)

Rank categories by points lost (weight minus scored), take the top three,
and for each name: the gap in plain language, what it costs day to day, and
which pack runbooks address it (ids only; the fixes themselves stay in the
pack). Never name fixes' contents in the report. Control gaps map to five
existing runbooks (foundation-06, integrations-03, skills-04, foundation-03,
foundation-04); no runbook is exclusive to control, so the pack-contents
preview lists those runbooks under their own categories only.

## Changelog

- v1.0: initial six-category rubric (foundation, memory-context, skills,
  integrations, productisation, advanced).
- v1.2 (2026-08-04): excludes foundation's version-control and
  baseline-sanity rows in Mode A, where no interview answer can reach
  either, so foundation renormalises over 16 rather than docking every
  client 8 points they cannot win. Mode B still scores both on evidence.
  The global-CLAUDE.md row is unchanged: it stays live, reachable at half
  credit through the session-end habit.
- v1.1 (2026-07-16, amended 2026-07-17): adds the control category
  (weight 14, never excluded), not-applicable-by-design answers with row
  renormalisation, and the capability band cap; reweights the original
  six categories (foundation 26 to 24, memory-context 24 to 22, skills
  12 to 10, integrations 12 to 10, productisation 18 to 14, advanced
  8 to 6). The amendment adds full credit on the review row for work
  that never leaves its author (a scored answer, not an exclusion).
