The most useful thing you can do is check a number.

The four things worth doing, in order.

1. Settle a recorded contradiction. The parameters page lists cases where two official sources disagree, each with the contract reference that would settle it. Read the contract, tell us what it says, and we will update the registry and credit you. This is the highest-value contribution available.
2. Re-verify a stale parameter. Open the source, read the value, update verified and the quote. Takes minutes and keeps the whole site honest.
3. Fix something wrong. If a lesson misdescribes a mechanism, say so with a source. Being corrected is the point.
4. Write a lesson. Useful, and the least urgent of the four.

The house rules.

• Never hard-code a protocol number. Add it to data/parameters.toml with a source, a verbatim quote and the date you read it, then render it with <Param name="..." />. The build fails on an unknown key and warns on a hard-coded literal.
• Cite inline. Every protocol claim names its source in the frontmatter, and the page renders those sources under the title.
• Explain why, link for how. If you find yourself writing CLI flags or configuration keys, stop and link to the docs instead. That material is maintained elsewhere and a copy of it here will rot.
• Record disagreements, do not resolve them silently. If two official pages conflict, add a note to the registry entry, set the status to disputed, and teach the conflict.
• Mark roadmap as roadmap. Announced is not shipped, and a capability that exists but is switched off is neither impossible nor current.
• No em dashes. A house rule from the design system, and it is absolute. Use a full stop, a colon, or recast the sentence.
• No hype vocabulary. No seamless, powerful, robust, unleash, revolutionary, effortless, game-changer, next-gen, blazing, or leverage as a verb. No exclamation marks. Numbers instead of adjectives, and every number must be true today.
• No placeholder names. Real contracts, real repositories, real addresses. If you need an example, use a real one.

Writing a lesson.

Lessons are MDX in src/content/lessons/<hub>/. The frontmatter schema is enforced by Zod at build time, so a missing field is a build failure rather than a broken page. Copy an existing lesson and change it.

Every lesson needs, at minimum:

• A summary that says what the reader will be able to do.
• At least one entry in sources, being a page you actually read.
• last_verified as the date you read those sources, and verify_before as when somebody should look again. Ninety days is the usual choice.
• A Quiz or a Checklist, because a lesson without a way to check yourself is an article.

Available components need no import: Param, Note, Tip, Warn, Model, Disputed, Reveal, Quiz, Checklist, Terminal, Flow, and the two calculators.

One thing the tooling cannot check.

Quiz questions and checklist items are JavaScript strings, so a component cannot go inside them and the parameter linter skips those blocks. It says so in its output. Numbers written inside a quiz are checked by a human reviewer or not at all, so if you put one there, be sure.

Before you open a pull request.

npm run params      # registry integrity and parameter usage
npm run staleness   # pages and parameters past their date
npm run audit:style # design system compliance
npm run contrast    # colour contrast, blocking
npm run build       # the site itself

All five run in CI. The contrast check blocks a merge, because an accessibility regression is not a matter of taste.

Where.

The repository is at nightswatchhq/graph-academy-v2. Discussion about the protocol itself belongs on the community forum, which is also the best place to find somebody who can settle a contested parameter.