Contribute

An open spec, governed in the open

100% open source and community-supported: the schema, the engine, and every instrument that verifies them are in one repository under one permissive license, with no gated tier. Here is how changes happen.

The claims rule

The repository's credibility rests on one norm above all others: no capability claim without an eval behind it. A statement of capability does not enter the docs until an adversarial check backs it in the eval suite. If you're adding a capability: fixture first, eval second, claim last. Every change must leave the gates green:

CONTRIBUTING.md — the gates

npm run build     # tokens → schema → all components, contract-validated
npm run parity    # three-way differ: code, canvas, tokens vs contracts
npm run eval      # the full deterministic suite
npx tsc --noEmit  # src, scripts, extract, parity, evals

Proposing a schema change — the RFC convention

The schema grows by demonstrated need. A proposal starts from a field case — a real component in a real system that cannot be expressed honestly today — and must state its projection on all four emitters, its refusal rules, and its receipts plan before any code lands. Proposals live as numbered files under site/governance/; rejected proposals are kept, with reasons — a rejected proposal is a receipt too.

The site itself enforces the documentation step: the coverage guard fails the build when the schema grows a branch this reference doesn't document, so an accepted RFC cannot ship undocumented.

No RFCs predate this convention. The schema's v2–v13 history was built before it existed and is documented as history — in MILESTONES.md and the versioning page — not retro-fitted into RFC files.

The template

Copy site/governance/TEMPLATE.md — rendered below from the committed file:

RFC-NNNN: {title}

Status: draft
Author(s): {name / handle}
Date opened: YYYY-MM-DD
Discussion: {link to the GitHub issue or PR}
Schema round targeted: {e.g. v14, or "none — process change"}

The field case

What real component, in what real system, cannot be expressed (or cannot be expressed honestly) today? Name the file, the kit, or the fixture. A proposal without a concrete field case is a speculation — the schema grows by demonstrated need, never by anticipation (YAGNI is a design principle here).

The proposal

The schema change, precisely: new fields, types, and where they attach (contract / part / prop / event). Spell the shape the way scripts/contract-schema.ts would.

Projections — every surface, stated

How does each surface render the new vocabulary?

Surface	Projection
React (emit-react)
HTML (emit-html)
React-inline (emit-react-inline)
Canvas (emit-figma-script)

A surface that cannot represent the feature is a declared fidelity limit: say so explicitly, and say what that surface renders instead. "The canvas ignores it" is an acceptable answer; an unstated gap is not.

Refusal rules

The illegal states, named. What must validateContract refuse, with what message? New vocabulary that cannot be half-used silently is the bar.

Compatibility

Existing contracts must keep parsing (add optional fields; never repurpose existing ones).
Is this widening (minor) or narrowing (major) for consuming contracts?
Differ impact: what new drift classes exist, and how are they classified (ahead / behind / mismatch)?

Receipts plan

The claims rule applies to proposals too: fixture first, eval second, claim last.

Committed fixture (a shipping contract that needs this, or a capture fixture that exercises it)
Refusal evals for the named illegal states
Round-trip / drift eval where applicable
Reference page section (the site's coverage guard will force this mechanically — a new schema branch fails the site build until documented)

Alternatives considered

Including "do nothing" and "carry it as a receipt instead of vocabulary" — the receipt path is the default for anything below the expressiveness bar.

Other ways to contribute

Skepticism. Genuinely welcome — start with Questions & Objections, where every hard question is asked the skeptic's way and answered with receipts. An unanswered hard question is an issue worth opening.
Field cases. Run the extraction against your own library (get started · path 3) and report what the pipeline couldn't carry. Named degradations from real systems are how the schema has grown every round so far.
A second implementation. The roadmap's endgame is an implementation this repo's authors didn't write passing a conformance kit. If you're building one — in any language, against any design tool — open an issue early; the conformance kit is being shaped by exactly this conversation.

Code of conduct

Contributions are governed by the repository's contribution norms. The project follows the spirit of the Contributor Covenant v2.1: be direct about the work, decent to the people. Report conduct issues via GitHub issues or privately to the maintainers.

License

MIT — the schema, the reference implementation, the extraction adapters, the eval suite, the playground, and this site. Fully open, no gated tier, no "open core." A spec the community can't fully use isn't a spec.