backwards — check if your goal is actually ready before you start coding
Tell backwards the outcome you want. Before writing any code, it breaks your
goal into the specific things that would have to be true, then runs quick
checks on each one and shows you which passed and which failed.
The problem
You set a goal like "ship a release I can safely undo." Tools start writing
code before anyone knows what "done" even means. Backwards works the other
way: it figures out what would have to be true for your goal to work, then
checks each assumption before any code gets written.
How it works
- Tell backwards one goal — one outcome you want.
- It breaks the goal into the assumptions that would have to hold.
- It runs a quick check on each assumption. The ones that fail tell you what is not ready yet.
- Change the goal — only the affected checks re-run.
- A record you can re-check later shows what passed, failed, and why.
Quick start
git clone https://github.com/jcoeyman/backwards.git
cd backwards
bun install
bun test
bun run proof:generate
What it checks
- Goal breaks into specific assumptions
- Conflicting assumptions are identified; one is ruled out
- Editing the goal re-runs fewer than all checks
- The record explains what passed, failed, and why
Limits
- No real AI or execution (it simulates the checks)
- No persistent storage beyond DO SQLite
- No authentication or access control
- One goal per run; no branching or merging
API
POST /api/runs {"text": "..."}
GET /api/runs/:id public run view
POST /api/runs/:id/step execute one round
POST /api/runs/:id/complete run to completion
GET /api/runs/:id/receipt replayable receipt
PUT /api/runs/:id/north-star {"text": "..."} edit goal
Policy
Edit src/policy.ts to change templates, bounds, and experiment limits without touching code.
What this unlocks
This project is a demo. The checked assumptions and their results feed into
a sibling project called Temper. Every checked goal becomes a candidate for
that pipeline.