The Kenos Method treats AI as a primary collaborator, not a bolt-on. An audit that would take a single designer weeks — cataloguing every hardcoded hex, every ad-hoc spacing value, every one-off component — becomes a conversation with an AI agent that can read the entire codebase in minutes.

AI is used to audit at scale, generate tickets from the violation catalog, identify patterns a human eye would miss, suggest semantic mappings (e.g. "this #6366F1 appears 47 times — is it --color-accent?"), and write the first draft of every remediation PR. The human stays in the loop for intent, naming, and final approval — but the mechanical work of compliance is delegated.

Before a single token is renamed or a single component refactored, the Kenos Method starts with an audit. The audit produces four artifacts:

1. Component inventory — every component in the system, Figma and code, tagged by status.
2. Violation catalog — every hardcoded value, every off-token color, every ad-hoc spacing step.
3. Baseline compliance score — a single percentage, calculated the same way every time, so progress is measurable.
4. Priority ranking — violations sorted by frequency × impact, so the highest-leverage fixes land first.

Everything downstream (tickets, PRs, wiki pages, scorecard updates) traces back to this baseline. No audit, no method.

The Kenos Method enforces a strict three-tier separation. Primitive tokens never appear in components directly — they pass through semantic tokens, which pass through component tokens. This is how a system survives a rebrand without touching a single component file.

Rebrand in one place (primitive layer), ripple everywhere. Never let a primitive leak into a component file — that's the invariant the compliance score tracks.

Every token, component, and decision gets documented at decision time, not retroactively. Retro-documentation is how design systems drift — by the time someone writes it down, the reasoning is gone. The Kenos Method closes that gap by tying documentation to the same PR that ships the change.

In stitchwand's case, this means every DESIGN.md file generated by the tool is both the design system and its own documentation. There is no separate "docs" step that can drift — the output is the source of truth.

A single percentage score, recalculated every time the audit runs, against a fixed rubric. Four bands:

Current stitchwand token compliance score: 100% — Excellent tier. Measured 2026-04-13 by running auditPages() (lint + analyze) against all 115 pages and components in apps/web.

Five steps, always in this order. Skipping a step breaks the method.

1. Audit — run the scan, produce the violation catalog, establish the baseline score.
2. Document — write the decision, the naming, the rationale. Wiki or Confluence page per violation category.
3. Implement — ship the remediation PR. Figma and code together, never one without the other.
4. Verify — re-run the audit on the touched surface. Confirm the violation is gone.
5. Update score — publish the new percentage. Celebrate the delta. Loop.

The Kenos Method was developed against enterprise-scale Figma + React systems, but the methodology is stack-agnostic. It applies whether you are running Tailwind + Next.js, a Figma library with 400 components, a native iOS app with SwiftUI, or a DESIGN.md file consumed by Cursor. The specifics of the audit tooling change — the five-step loop and the three-tier invariant do not.

Stitchwand generates DESIGN.md files that encode the same three-tier token architecture for AI consumption. The Kenos Method is both the methodology behind stitchwand and the methodology it helps others implement. Stitchwand's own token compliance score is a live proof point — we dogfood every claim we ship.

For the full go-to-market framing of the Kenos Method, see AI Strategy and Strategy. This page states the philosophy in the design-system voice; those pages tell the revenue story.