You asked whether the current framework is good enough to move towards a version 1.0 of the app, and you asked for the head of the queue refocused off scaffolding and onto charts and the platform. This page answers the first question in its second paragraph, re-derives last month’s competitor survey against what has actually shipped since, proposes ten items to replace the current ten, names the charts worth building, and recommends the smallest piece of real clinical work that would genuinely test the machine over a weekend.
Yes for building clinical work, and no for calling anything 1.0 — and those are two different problems, only one of which is about the framework. The machine that builds has spent the last month proving it can do clinical work well: it delivered a kidney-safety explorer, a Kaplan–Meier survival chart whose estimator agrees with R’s survival package to ten decimal places, three participant-level safety metrics, and a study census, each through the same lane — isolated branch, tests written first, a published evidence page, release notes. Two of those were displays last month’s survey listed as things everyone else ships and we did not. What is not ready is the bookkeeping a version number rests on: nobody has ever written down what 1.0 contains, the design question that would let the app’s requirements be filed at all has sat open since 12 July, and the demo study a 1.0 would be judged on has failed its weekly rebuild three times running since 3 August, and the issue filed for it was never ranked. Push, and start this weekend with clinical build work — but the first hour of it belongs to those three, because they cost almost nothing and every week of a v1.0 push without them arrives at a version nobody can define.
You used the word twice in one breath — “how some clinical build work goes in our new framework”, then “whether the current framework is good enough”. Read as the machine that builds — workers, lanes, gates, release candidates, evidence pages — the answer is yes, with one caveat below. Read as the product architecture — the chart library, the R package that carries it into clinical reports, the app that assembles them — the answer is yes for the charts and not yet for the layer around them. Both readings are answered on this page; the first is the one the recommendation above is about.
Of the fifty-seven items this program closed in August, seven carry the safety label, and six of those seven were closed on a single day in what reads as bookkeeping on work that shipped weeks earlier. The machine is capable of clinical work. It has mostly not been pointed at it. That is what you are correcting, and it is a scheduling fact rather than a capability one.
The survey you asked me to review is What everyone else ships that we don’t, written on 25 July: thirteen safety platforms and two reference catalogues, sixty-three capabilities, our own column read off the code rather than assumed. It is unusually careful and it states its own limits — a competitor is scored as having a capability because its documentation says so, and nothing was tested. Its headline was that the chart set is competitive and the review layer around it barely exists.
It is four weeks old, and four weeks is a long time here. I re-derived its numbers against the code and the issue trackers tonight rather than repeating them.
| What it said on 25 July | What is true tonight | Why it moved |
|---|---|---|
| 11 of 30 chart types shipped | 13 of 30 | The kidney explorer shipped on 14 August and the Kaplan–Meier survival chart on 15 August. |
| Kaplan–Meier is missing, and on the headline list | Shipped, marked Experimental | Four platforms ship it and we did not. The estimator is cross-checked against R’s survival package. The headline list drops from sixteen rows to fifteen. |
| 0 of 10 review-workflow capabilities shipped, and none filed | 1 filed, covering 3 of the 10; still 0 shipped | You directed the action-log requirement on 28 July, three days after the survey; it was filed on the 29th and covers review state, comments and issue tracking to resolution. It has seven design questions written out and has not moved since. |
| Nothing in the portfolio flags a participant | Half wrong now | The R package scores three participant-level safety metrics as of 17 August, and the demo site shows a queue of flagged participants. What is missing is the notification half and the reviewer’s own state. |
| “What changed since I last looked” does not exist here | Partly ours | The app draws snapshot-to-snapshot change chips at study and site level. Nothing does it per participant, and nothing is scoped to one reviewer’s last visit — which is the capability the survey was pointing at. |
| Charts sharing one filter and one selection is left to a requirement’s design stage | Worse | That requirement was closed on 15 August with the mechanism unbuilt and nothing filed in its place. This capability now has no issue anywhere. |
| Twelve requirement proposals, none filed, awaiting you | Unchanged after four weeks | The issue asking which of the twelve to file is still open. Question four on this page is the chart half of that answer. |
Thirteen of the thirty chart types are shipped. Of the seventeen that are not: four are already filed as requirements, four are marked low priority by the survey itself and I agree with all four, and nine are genuinely wanted and unfiled. So “the charts are nearly done” is true as a competitive claim about the displays a safety reviewer actually opens, and false as a count of rows. Both sentences are worth having, because the first is what a September audience will see and the second is what a build plan has to work from.
The summary reaching you was that charts are nearly done, the workflow layer was never started, and therefore the gap is the platform around the charts rather than the charts. That is right as strategy and wrong in two particulars, and one of the particulars changes what to do this weekend.
Every one of these already has an issue behind it; nothing here is ranked on a hope. The order is a proposal — ranking is obot-prime’s call and it will act on this rather than adopt it. The migration is off by your own word tonight and is not ranked. Under each, whether it needs your clinical review before it ships.
The R package that carries these charts into clinical reports still wraps a copy of the chart library from three releases ago. One of those releases fixed a defect in the composite liver view: a participant with no day-zero record had their own baseline counted as an on-treatment peak — twenty-four of three hundred and eighteen participants on the demo data. The JavaScript chart was corrected in July; the R widget still draws the old one. This item ships the catch-up and a build check that makes the next drift loud instead of silent, so this is the last time it is discovered by accident. obot.roadmap#164
You answered all six questions on the census design on 20 August and nothing has been built since. Thirteen numbers become individually validatable metrics, the census becomes a report, and the death count goes from one to thirteen on the study the design measured, because it starts using the standard mapping’s definition. It is the clinical work in the whole backlog with the fewest remaining unknowns — the design is signed, so the only thing between here and a release candidate is the building. obot.roadmap#274
Data coverage per visit is the figure that decides whether a quiet visit is reassuring or empty, and it is the one census number that genuinely wants a picture. You approved deferring it and filing it in the same breath, and it was filed. Its first question — whether it reuses the existing risk-indicator bar chart or is built properly in our own library — is ours to answer in design, not yours. obot.roadmap#291
Three consecutive weekly pipeline runs have failed at the step that installs its pinned packages. The published site still shows the last good run, so nothing looks broken from outside — which is exactly why it went three weeks. This is the study a version 1.0 would be demonstrated on and the template a fork would copy. The issue was filed on 14 August, after the first failure, and never ranked since. obot.roadmap#153
This one is on the list because it is a gate, not because it is work. The app’s own goal says no requirement can be filed for it until this lands, and it has been open since 12 July. Your recorded position is that you did not agree with demoting GitHub from a prerequisite to an optional publishing lane — and the unreleased 0.2.0 shipped exactly that architecture anyway, because the code kept moving while the decision did not. Half an hour of yours unlocks the entire app requirement set. obot.roadmap#34
The Kaplan–Meier chart is live on the site with an Experimental label, because six statistical choices were made provisionally by an unattended session: which estimator, whether curves rise or fall by default, that the confidence bands are pointwise rather than simultaneous, what the at-risk table counts. All six are written down and defensible. None has been reviewed by a person with the standing to sign them, and until one is, we ship a survival curve carrying our own warning label. obot.roadmap#182
The rule you set is that a chart is not finished until it exists as an R widget as well as a web component. The survival chart and the participant profile do not have one. Two shipped, demonstrated, evidence-backed charts are unfinished by the standard this program applies to itself, and the requirement for it is sitting in the backlog. obot.roadmap#165
The survey’s strongest single finding, and the thing that separates a chart library from a review tool: a reviewer opening the same study every week can neither record what they have already looked at nor see what arrived since. The requirement exists, written at your direction on 28 July, and its central problem is already identified — review state is mutable and the entire data architecture rests on snapshots being immutable. That is a design pass, not a build, and it is worth one this quarter. obot.roadmap#139
Eight of the original chart repositories still carry issues filed by the people who used them. That is a source of charts to make grounded in what real reviewers asked for, rather than in what a competitor’s marketing page describes — and it is the one input to the chart roadmap that costs nothing to trust. obot.roadmap#33
Twelve requirement proposals, none filed, four weeks old, and the issue asking which to file still open. Question four on this page answers the chart half. This closes the rest — including the four capabilities the survey recommends writing down as deliberately out of scope, which is cheaper now than being asked in September and having no answer. obot.roadmap#176
Nine of the current ten are harness work. Four of those would bite a clinical push rather than merely being unfinished, and I would keep two of them where you can see them rather than pretend they do not matter: nobody can currently write to the roadmap board, so every requirement’s stage is wrong and every surface built on it inherits that; and agent commits still go out under your name. Neither is a chart. Both change what you can trust about a week of clinical work. One slot on the current ten is already empty — the honest-on-a-fresh-machine item closed today.
None of these can go on a ranked list, because ranking a thing with no requirement behind it is how work goes missing. Each needs filing first. I checked both trackers by search rather than by memory; nothing matching any of these exists anywhere.
Two linked views of one question: which adverse-event terms differ between treatment arms and by how much. A volcano for screening hundreds of terms at once, and a paired panel — incidence per arm on the left, the difference with a confidence interval on the right — for reading the top of that list. We count adverse events and we list them and we never compare arms with an interval, which is the first question anyone asks of an imbalance. The original working group already built one and it was never migrated. Two of the FDA’s core figures are the static twin.
Our results-over-time chart draws quantile boxes, which answer “how spread out is this”. Every platform surveyed also draws the mean with an interval at each visit, which answers “did the group move”, and reviewers use both. It reuses the existing chart’s data contract unchanged, which is what makes it the cheapest real gap on the list. Two more FDA core figures.
The views a reviewer opens before any safety display: baseline characteristics by arm, discontinuations and their reasons, enrolment over time by site. Five platforms open on these and we ship none of them. Without them a reviewer cannot answer the standard first challenge to anything else we draw — is this a safety signal or a population difference.
Pick a participant in one chart and every open chart follows; set a filter once and it holds everywhere. Five platforms do the first, seven the second. The requirement that would have carried this closed on 15 August with the mechanism unbuilt, so this capability now has no issue at all — it went from filed to unfiled without anyone deciding to drop it. A searchable participant selector is filed in the chart library, but that is a component, not the mechanism.
The app has change chips between snapshots at study and site level. What does not exist is the participant-level version, and the part that makes it a review tool rather than a diff: scoping it to when this reviewer last looked. It is inside the action-log requirement’s scope, so this may be a design decision inside that rather than a sixth filing — worth saying which.
The abnormal-baseline liver tooling requirement has all three of its sub-issues closed and is still open. It looks finished. Somebody should read it and close it rather than leave it counting against the quarter.
You said the weekend is busy, and the point of it is to watch clinical work go through this machine rather than to maximise output. So the question is not what fits — it is which single piece would actually test the thing you want tested.
| Work | Two days? | Why |
|---|---|---|
| The R widget catch-up and its guard | Yes | A re-vendor, two new widget bindings, a build check, refreshed example data. Bounded, testable, ends in a release candidate. |
| The demo pipeline fix | Yes | Hours rather than days, and everything else becomes demonstrable again. |
| Taking Experimental off the survival chart | Yes, if you read it | The work is yours, not the machine’s: six written decisions to accept or send back. |
| The census rebuild | No — an arc | Thirteen metrics and a report on a clinical package, plus death records the demo study does not yet supply. |
| The data-coverage chart | Design, then build | Its first design question has to be answered before anyone draws anything. |
| The review layer | No | Seven open design questions, one of which is an architecture problem. |
| Any of the five unfiled charts | No | They need requirements before they can be built. |
The R widget catch-up. It is real clinical work — it changes what a liver chart shows in R output — it is already filed and scoped, and it exercises every part of the framework end to end in one pass: an isolated branch, tests written first, a clinical package, an evidence claim, a release candidate, and your review gate at the end of it. It also fixes a defect that is live right now, so a weekend spent on it is not a rehearsal. If it goes cleanly you have your answer about the framework from something that mattered; if it goes badly, it goes badly on work small enough to see why.
If you would rather watch a chart get built than a chart get fixed, the second choice is the data-coverage chart — but its first design question has to be answered on the Saturday, which makes it a design-then-build weekend and a weaker test of the build lane.
You asked directly, so this section is by clinical value rather than by how many competitors ship the thing. The count of platforms is in the survey and it is a weak signal on its own — every platform ships demographics tables, and that does not make them the most valuable thing we could build next.
Three ways to go. Start the push now with clinical build work and fix the bookkeeping alongside it. Or harden first — finish the harness items on the current ten and start the push in September. Or push only once someone has written what 1.0 contains, which makes the definition the blocking task.
Ten items above, every one with an issue behind it, ordered so that the first four are things that are broken or signed-off rather than things that are new. Ranking is obot-prime’s to do; this is a proposal it will act on.
The R widget catch-up, which fixes a chart that is wrong today. The data-coverage chart, which builds something new but needs a design answer first. Or the census rebuild, which is the largest and is signed off but will not finish in two days.
Five have no issue anywhere: risk-difference screening, mean change with intervals, the context set, one filter and one selection across charts, and per-participant change since last review. Filing is cheap; ranking something unfiled is what goes wrong.
Mark it reviewed, show me what changed, annotate a finding, track it to resolution. It is the survey’s strongest finding and the difference between a chart library and a review tool. It is also a design problem with a real architectural conflict at the centre of it. Either it is in 1.0, or it is explicitly out and we say so before somebody asks in September.
Citations, for a deep dive rather than as explanation: the platform gap analysis and its twelve proposals; the census rebuild you approved; the app plan rewrite whose third question was never answered; the ranked head. Roadmap issues named above, in order of appearance: #164, #274, #291, #153, #34, #182, #165, #139, #33, #176, #43.
Drafted by Claude Code using Opus 5, background worker W0109, 2026-08-21. Nothing on this page was filed; every proposal is a proposal.