Skip to content

Latest commit

 

History

History
53 lines (34 loc) · 3.22 KB

File metadata and controls

53 lines (34 loc) · 3.22 KB

Contributing

This roadmap has exactly one thing that makes it different from a link list: every node is a checkable milestone, not a keyword. Contributions are welcome, but they have to hold that line. This guide is the quality gate.

The one rule

A node is a milestone, not a topic. It must state an artifact the reader can point to.

Concretely, every node is phrased as You're done when … and ends in something checkable: a passing test, a merged PR, a captured flag, a leaderboard entry, a shipped-and-measured guardrail, a written report someone signed off on. If the "done" condition is "you understand X" or "you've read about X," it is not a milestone and it does not belong here.

✅ A milestone ❌ Not a milestone
"You're done when your Inspect Task runs end to end and you can explain each score." "Learn how evals work."
"You're done when your name is on the leaderboard with a confirmed break." "Understand jailbreaking techniques."
"You're done when your eval is accepted into the UK AISI register." "Explore the Inspect framework."

Suggesting a resource

Resources are held to the project's standard: three excellent resources beat ten mediocre ones, and no resource appears twice. Before you propose one, it must be:

  1. Open — readable/runnable without a paywall, an application, or a closed cohort. (Pointing at a gated program as a milestone target, like a fellowship, is fine — that's a destination, not a resource to consume.)
  2. Live — you opened it this week and it works. Dead links and abandoned repos get removed, not added.
  3. Best-in-class — it is the best hands-on resource for that milestone, not merely a resource. If something already covers the milestone, argue why yours is better, or don't add it.
  4. Hands-on where possible — a "build/break/ship this" resource beats a "read this" resource for the same milestone.

Use the Suggest a resource issue template.

Suggesting a milestone

New milestones are welcome if they fill a real gap in the "working engineer → safety engineer" path. Use the Suggest a milestone template and include:

  • the You're done when … line (the artifact),
  • where it fits in the section order and why,
  • one candidate resource that meets the bar above — or a note that this is a [reference implementation] gap (no good resource exists yet).

Editing the map

The path map in the README is generated, never hand-drawn. Edit the SECTIONS / EDGES data at the top of scripts/render_map.py, then regenerate:

python scripts/render_map.py

CI runs python scripts/render_map.py --check and fails if assets/roadmap.svg is out of sync with the script. Commit both.

What gets rejected

  • Keyword nodes with no checkable artifact.
  • A second resource that does the same job as one already present.
  • Resources behind paywalls/logins, or that were already dead when submitted.
  • Scope creep into alignment research (interpretability theory, RL, agent foundations) beyond the working minimum in §1 and §7 — this is an engineering roadmap, and §7 already marks the fork out to the research track.

Facts only in review comments — no need for pleasantries.