{
  "version": "2026.1",
  "about": "Loom public rubric: the eight areas shared by the health check, the audit and the control area. Generated from src/rubric/areas.ts by npm run rubric:build; do not edit by hand. Docs: docs/product/RUBRIC.md.",
  "overall": "Overall = Σ(area weight × area score) / Σ weights of the areas that could be scored. Areas that cannot be scored are left out, not counted as zero.",
  "areas": [
    {
      "id": "foundations",
      "name": "Foundations and tokens",
      "description": "The basic decisions everything else is built from (colour, type, spacing, motion, modes) and how they reach code as tokens.",
      "weight": 1.2,
      "good": "Every decision is a typed token with a role and a source; semantic tokens alias primitives across three tiers; light, dark and high-contrast modes are supported or explicitly decided against; colour pairs pass WCAG in every mode.",
      "selfAssessment": "Colour roles, a type and spacing scale people use, tokens that code reads directly, and rules for themes or modes.",
      "audit": "Token inventory size, typing, DTCG validity, aliasing and tiers, literal duplicates, required modes, computed contrast, colour space, descriptions with provenance and naming."
    },
    {
      "id": "components",
      "name": "Components",
      "description": "The building blocks teams reach for: catalogued, contracted, tested and released.",
      "weight": 1.2,
      "good": "Every component is catalogued with a complete usage contract (purpose, when and when not to use, anatomy, API, states, behaviour, accessibility, content, examples), its own automated tests and stories, scripted keyboard paths, a platform decision and a versioned release.",
      "selfAssessment": "Coverage of what teams need, when-to-use guidance, visible states, built-in accessibility and design–code parity.",
      "audit": "Catalogue, contract completeness (10-field template), components at 80% or more, per-component QA, keyboard/focus tests, cross-platform parity and release records."
    },
    {
      "id": "patterns",
      "name": "Patterns and pages",
      "description": "How components come together for real tasks and screens: patterns and page templates.",
      "weight": 0.9,
      "good": "Common tasks (forms, search, confirmation, empty states) are documented patterns with followable rules, and page templates show the pieces on a real screen.",
      "selfAssessment": "Reusable patterns for common tasks, page templates, and proof in real product screens.",
      "audit": "Documented patterns, patterns that carry rules, and page templates. Not assessable when the inputs contain no pattern or template records (it is then left out of the overall score, not scored zero)."
    },
    {
      "id": "usage",
      "name": "Usage",
      "description": "Whether product teams actually use the system, and whether anyone can tell.",
      "weight": 1.1,
      "good": "Product code (not only the system's own site) uses system components for most UI; bypasses (raw colours, raw pixels, hand-rolled controls, deep imports) are rare; there are no local copies or duplicate definitions; every element in use has a contract.",
      "selfAssessment": "Adoption for new work, local copies, hard-coded values and visibility of where the system is used.",
      "audit": "Adoption share, a product consumer, bypasses per 1,000 lines, local re-implementations, used-but-unruled elements, entry-point imports and duplicate definitions. Not assessable without consumer code."
    },
    {
      "id": "governance",
      "name": "Governance",
      "description": "Who looks after the system and how it changes without breaking things.",
      "weight": 1,
      "good": "Machine-readable owners, a contribution flow with templates, semver with release tooling, changelogs, deprecations with a timeline, decision records, a declared layer model and defined lifecycle labels.",
      "selfAssessment": "Named owners, a known contribution path, versioned releases with migration paths, and written decisions.",
      "audit": "Owners, contribution, versioning, changelog, deprecation, decision records, layers and lifecycle, each graded from mention to machine-readable or enforced."
    },
    {
      "id": "brand",
      "name": "Brand, illustration, microcopy and localisation",
      "description": "Whether brand, imagery and writing rules can be checked, not only admired in a PDF.",
      "weight": 0.8,
      "good": "Brand, illustration and voice rules are machine-readable or enforced; illustrations live in a library with per-asset metadata; strings are externalised in a message catalogue; localisation is ready (pseudo-localisation, text expansion, direction rules).",
      "selfAssessment": "Checkable brand rules, a managed illustration library, a voice guide applied in reviews, and readiness for other languages.",
      "audit": "Brand, illustration and microcopy rules, illustration library, message catalogue, localisation policy and localisation readiness signals; UI-string casing against the documented rule."
    },
    {
      "id": "tools",
      "name": "Tools and sync",
      "description": "Whether design, code and docs tell the same story, kept in step by tooling rather than by hand.",
      "weight": 0.9,
      "good": "One token source is built into code by a pipeline; every component has stories in a workshop; a documentation site is generated from the system's records; CI runs the system's checks on every change; the design tool is linked to code.",
      "selfAssessment": "Figma and code in sync, one up-to-date place to look things up, and one agreed source of truth.",
      "audit": "Detectable signals only: stories per component, a token pipeline (source file plus build), a documentation site, CI that runs checks, and a design-to-code link (Code Connect, token sync config)."
    },
    {
      "id": "ai",
      "name": "AI readiness",
      "description": "Whether AI coding and design tools can use the system, not guess at it.",
      "weight": 1,
      "good": "Machine-readable contracts and followable rules for every component, one exact import each, an MCP knowledge interface, retrieval tests in CI, agent instructions and tokens with allowed and forbidden uses.",
      "selfAssessment": "Machine-readable rules, direct lookup by AI tools (for example MCP), and on-system AI output.",
      "audit": "Machine-readable contracts, rules, knowledge interface, exact imports, retrieval tests, a measured name lookup, agent instructions and token rules."
    }
  ]
}