caseclock says whether a plan is feasible. fray says how fragile that answer is. It takes the same case file — and caseclock's tape, so it measures the plan as it stands rather than as it was filed — samples the durations its constraints assume, re-runs the closure a few hundred thousand times, and prints one line: how often the plan survives, what breaks first, and what one action buys.
Status: 0.4.0 — built,
--selftestgreen (64 checks). Stages 0 to 3 are done: the closure (parity with caseclock by equality, on caseclock own binary), the sampler, the margin, the counterfactuals, and the surfaces —--explain,--replay,--aboutwith an import-table receipt, and a chained tape glance own verifier reads. The numbers are indocs/devlog.md. What is open is in BLUEPRINT section 10: the right default N, correlated delays, and where a site distributions come from.
TR-4118-drawn · survives 37.0 % of 200,000 futures · first to break: recovery-team mobilisation (51 %)
the futures that survive clear by 24 min at the median, 4 at the tenth percentile, 0 at worst
draw serology 20 min earlier -> 54.3 % (+17.4 points), and the survivors clear by +8 min
200,000 futures · 201 ms · CPU · seed 0x0000000000c0ffee · 3 of 7 constraints varied
caseclock calls that same plan feasible, with 275 to 620 minutes of slack on every deadline. Both are true. The second one is the one worth a phone call.
A case is feasible or it is not — caseclock computes that exactly, in whole minutes, with the chain of constraints that produced it. What it cannot say is whether the plan clears by four hours or by four minutes, and which single thing running long would end it. That gap is where cases are actually lost, and it is the only thing fray does.
- Reads caseclock's case file, unchanged: the constraints, the times already entered.
- Reads a distributions file the site owns (
rules/delays.yml): the reference lab is usually six hours and sometimes six forty; the transport leg is five hours, occasionally six and a quarter. The engine ships no site's numbers. - Draws a few hundred thousand futures, each with its own sampled durations, and re-runs the closure over every one.
- Reports survival, what broke first, the slack left in the futures that survived, and the effect of each action the site listed — draw twenty minutes earlier, put the courier on standby — measured, not guessed.
- Proves it: the seed is printed, the count is printed,
--replayreproduces the answer's checksum, and the distributions file's hash rides on the tape beside the number.
No network stack — the exe links none, and the build fails if one appears. No model: the sampler is arithmetic. Nothing about the person. fray perturbs durations, never patients; it does not rank recipients, score organs, compare candidates or estimate a clinical outcome, and the only counterfactuals it will accept are actions the OPO takes with its own resources. The project's charter is binding here: these tools never determine organ viability, never make or override an allocation or clinical decision.
No GPU. The closure over a seven-event case is a shortest path on a seven-node graph; two hundred thousand of them is milliseconds. The tool prints what it actually used.
the record ──▶ glance ──▶ caseclock ──▶ fray
(a screen) (text) (is it (how much does it depend
feasible?) on nothing going wrong?)
facet finds files, vramtop shows the card, everywho shows the disk, glance reads the screen, caseclock keeps the clock, fray tells you how thin the margin is. Six tools, six jobs, one tape shape.
The idea descends from a 2025 specification for a GPU technology demonstration that ranked organ
allocations by score. Its credibility system — exact counts, a printed seed, deterministic replay,
a verifiable checksum — is kept and is the best thing in it. Its allocation scoring is not: it
crosses the line these tools do not cross, so fray perturbs schedules instead. docs/BLUEPRINT.md
§1 records what was kept and what was cut, and why.
MIT · Access Intellect LLC.