Skip to content
problem genome

For instructors

Teach with the collection

Every one of the 613 problems here is real, open, verified from an expert source, and scoped so a student team can make meaningful progress in a term. Each brief is already an assignment sheet: the problem, why it matters, what’s been tried and why it hasn’t worked, what would unlock progress, and entry points sized for a semester.

The assignment recipe

  1. Teams pick a problem. Send students to the finder (guided: field, kind of hard, semester fit) or the drawer (browse every problem as a drawn card). A shortlist travels in the URL — students can send you their three candidates as links.
  2. First deliverable: argue with the brief. Before designing anything, have the team re-state the problem in their own words and challenge the genome — is the binding constraint really what the card says? The “what’s been tried” section is a ready-made related-work assignment; every claim carries its source.
  3. Scope to the semester-fit line. Each brief names how far a team should realistically get — frame & propose, prove a concept, build a prototype, or contribute research. Grade against that, not against “solve it.”
  4. Register the team on the problem’s page (“adopt” box, two minutes). Registration collects only a team name, course, and contact email.

What it costs in class time

Choosing a problem: one homework or half a session with the finder. Registering: about two minutes per team. The re-reads — the part that feeds research — would be two short revisits of the team’s own problem during the term, roughly ten minutes each; they begin only once the study protocol is approved, and only for teams that accept the invitation. Nothing about using the collection in your course depends on participating.

Can two teams take the same problem?

Yes — deliberately. These are real open problems, not puzzles with an answer key; two teams that start from the same brief will diverge at the first design decision, and comparing where they diverge is one of the best discussions the collection can give you. If you’d rather spread coverage, the structural cousins on each brief (problems in other fields sharing the same deep structure) make good adjacent assignments.

What your class gets back

  • Problems with constraint information — students start from “why past attempts failed,” not from a blank page.
  • A citable problem definition: every brief has a cite this problem block, so student reports can reference the problem the way they’d reference a paper.
  • Updates when an adopted problem’s page changes, and first look at what the study finds once it runs.
  • A path for good student work to matter: if a team surfaces a problem the collection misses, they can bring it to us — accepted problems publish as verified briefs, with credit if they want it.

How the collection is built and checked: data & method. Questions about running it in your course: designdartmouth@gmail.com.