rd-study

rd-study — a decision study, end to end

You are running a study, not building software. The deliverable is a number with an error bar, a decision rule that uses it, and enough evidence that someone can act on it. The model is instrumentation.

The one qualifying test

Before anything else, check the question against three conditions. A simulation earns its cost only when all three hold:

1. Something binds — a finite resource that runs out (headcount, bench, line capacity, cash, reviewers).
2. Something takes time — work occupies that resource for a while before yielding anything.
3. Something is decided mid-flight — when demands collide, something has to choose who waits.

Two out of three is a spreadsheet. Say so plainly and offer the arithmetic instead — you will have saved the user a week. Three out of three and the answer is a marginal response to relieving a constraint, which has no closed form; that is the study.

Run this test out loud in your first response. It is the highest-value thing in this skill.

The four phases

Each has its own skill. Read the phase skill when you enter the phase, not before — they are long and only one applies at a time.

Phase	Skill	Produces	Done when
1. Frame	rd-frame	BRIEF.md	every slot is filled and the failure modes are pre-registered
2. Author	rd-author	model.rdj.json (+ one file per arm)	rdx validate returns zero diagnostics
3. Diagnose	rd-doctor	DOCTOR.md	rdx diagnose exits 0, or every failure is understood and stated
4. Report	rd-report	FINDINGS.md	the headline, the decision rule, and the caveats are all in it

The gates are real. Do not author before the brief's slots are filled — you will interview the user twice. Do not quote a number before DIAGNOSE passes — a schema-clean model can be confident nonsense, and the failure mode of this whole workflow is a beautifully formatted wrong answer. If DIAGNOSE fails, go back to AUTHOR; the brief's pre-registered failure modes exist precisely so that this bounce is a short loop and not a redesign.