Software that learns your jobsite, then ships.
No settings screen and no ticket to IT. Your crew does the job. The harness learns the job and keeps only what helps.
- 1 · YOUR CREW WORKSPhotos, searches, owner updates
Supers shoot MEP rough-in. PMs search for "before drywall". PEs build the turnover package.
- 2 · IT NOTICESIt sees the pattern
The same OAC photo pack every Friday. The same open-wall search on every unit.
- 3 · IT SHIPSA new screen, made for you
It adds a field, a tool or a screen, and turns it on.
Here is something we built for you.
- 4 · IT CHECKSKept or rolled back
Each version is scored on use. A worse version rolls back by itself.
Each person gets the screen the harness chose for them.
The harness writes one layout per role and changes it when the role's work changes. These are the layouts in the current version.
Every new feature came from how people used it.
Ten versions over seven years of a simulated general contractor. Each card says what the harness noticed on the jobs, then what it shipped. One change made answers worse, so it rolled back.
Plan, Build, Instrument. Then the improver.
The stages run on a frozen copy of the policy: rules, context policy and tool grants. Only the improver writes a new policy, and only from what Instrument found. So each version has a reason you can read.
Reads the last checkpoint and its measurements. Picks one sprint mode: feature, improvement or fix.
Runs the coding agent (Claude Code today) with freezePolicy() and a store that refuses rule writes.
Runs checks for ten capabilities in trade terms: MEP rough-in, OAC photo pack, closeout walk, turnover package, fall protection. Writes findings.
Turns findings into policy vn+1, tags git cp/n, and writes policies and checkpoints to Atlas.
Every version is a checkpoint. Any checkpoint comes back.
- Rules are data. Rules, context policy and tool grants live in a versioned policy, not in a prompt.
- Checkpoints are durable. Git sha, policy version, scores and a retrospective, in MongoDB Atlas.
- Rollback is one command. The old policy returns as a new version, so history is never lost.
pnpm 3pt loop [plan] start iteration 1 [plan] mode=feature basedOn=none [build] claude-code dry run: feature sprint, 3 rules, 4 tool grants [instrument] 3 checks planned, 0 findings written [improver] policy v1 written; checkpoint cp/1 pnpm 3pt rollback cp/1 [rollback] policy v1 from cp/1 restored as v2 [rollback] code is not touched. To also restore it: git checkout cp/1
Long-term memory is the database, not the context window.
Every stateful thing lives in one Atlas cluster. The stages read from it, the improver writes to it, and any version can be run again over the same data.
The harness
What it is, and how it got here.
policiescheckpointsharness_versionsplansfindingsmeasurementsThe media
Photos are read once, then tiered.
media_indextranscriptsjobsThe contractor
The simulated GC it learns on: projects, photos, activity, outcomes.
demo_projectsdemo_photosdemo_activitydemo_outcomesCheck it in four clicks.
/app/
DIFFICULTY · 30Frozen policyStages get a read-only policy and a store that refuses rule writes.harness/packages/core
IMPACT · 20For non-technical crewsEach role sees the screen the current harness chose for it.#feel
CREATIVITY · 15It changes its own rulesThe improver is the only writer of the rules.harness/packages/improver
Built today: inspect the commits.
Built on real construction photos.
Openly licensed site photos and 20 NYC building records from NYC Open Data. Photos are the workload the harness learns on, not the product. It learns which fields matter: unit, level, trade, open or closed wall, issue.
What is real and what is simulated: the loop, the policies, the checkpoints and the rollback are code in the repo. The firm in the app, with its years of jobs, is a simulation with a fixed seed.