idea-001 · viability deck
Every slide states a condition that would have to be true, then reports where it stands using the candidate file's own claim and its own confidence tag. A deck never upgrades a tag, invents a number, or recommends anything, and there is no ask slide.
The chair: the investor, and the operator who would have to make a device sale plus a monitoring subscription add up to a business.
How to read this: every slide is a condition, not a conclusion. A bracketed claim reference points into knowledge-base/candidates/idea-001.md — the number is the claim's position in its ## Claims list, the tag is copied from it and never adjusted here. A [no claim] marker means nothing in the file speaks to the condition at all. No number appears here that is not in a claim, and there is no ask slide. See docs/deck-spec.md.
What changed since the 2026-08-24 build — read this first. That deck's load-bearing condition was "load the CMS files and read the coverage policy". It was done, on 2026-08-30, and this is the deck reporting the answers. Four questions that had been unconfirmed for a missing cache are now resolved, and three of the four resolved against the candidate. This is what a deck looks like when its cheapest next test comes back. Rebuilt from the file, not patched.
Would have to be true: Two separate revenue lines would have to work at once — a device supplied under a DME benefit, and remote-monitoring time billed by the clinician — and the second is what makes the first attractive to the prescriber.
Where it stands: The device line is now real and small. E0740's descriptor is confirmed against the CMS file and matches the device as written, including "complete system" [claim 7: verified], and a published DMEPOS allowed amount exists [claim 10: verified] — the candidate records it as $74.52 for 2026, national unadjusted, and says in its own note that "a dollar figure now exists, and it is a small one". The monitoring line rests on CPT codes that this repo cannot check at all: they are AMA-licensed and the connector cannot return verified or refuted under any circumstance [claim 13: unconfirmed], [claim 15: unconfirmed], [claim 11: unconfirmed]. And the money splits across two parties: RTM professional time accrues to the clinician, not the manufacturer [claim 18: unconfirmed], so the second line is an incentive to prescribe rather than revenue to the company.
What would settle it: A licensed AMA CPT source for the RTM descriptors — a purchase, not a lookup, and now the only unbought input on this slide. Then a locality-adjusted read of the DMEPOS rate against a real bill of materials.
If it's false: The prescriber's incentive disappears and the model reverts to a one-off device sale, at $74.52 [claim 10: verified], into a channel that has to be built.
Would have to be true: A code, a payment, and a coverage policy — all three, and here a fourth: a PDAC coding verification that says this specific device fits the code.
Where it stands: Three of the four are answered, and the pattern is that the plumbing exists but the permission does not.
What would settle it: The NCD 230.8 text read directly — a published document that a human can open and this repo's fetch path cannot. Then PDAC's own coding-verification decisions.
If it's false: If the NCD does not exist as described, the indication's four-week prerequisite — accepted as a funnel cost to win coverage — was paid for nothing.
Would have to be true: Enough diagnosed, in-care women, at enough revenue per system, to support a specialty sales motion.
Where it stands: The two checkable components came back, and both are refuted at the threshold the file asserted.
market connector reports as permanently unverifiable here.
The structural caution the file records still stands and matters more now that the volumes are low: Medicare volumes are a floor, not the market, because this population skews younger and commercially insured [claim 32: unconfirmed].
What would settle it: A commercial claims read — the only thing that can tell whether 4,130 Medicare units is a floor under a real market or the size of the market. A human-pulled payer-mix source for the same reason.
If it's false: TAM is a hard kill condition. It did not fire — a refuted threshold is not a refuted market, and the file is careful about the difference — but the direction of the correction is against the candidate and the commercial read is now the load-bearing TAM work.
Would have to be true: A 510(k) with an existing predicate, plus PDAC coding verification, plus the app's software documentation, would have to reach revenue on modest capital.
Where it stands: No cost or timeline claim existed in the file at all until this deck's write-back [claim 30: unconfirmed], and the Verifier confirmed no connector in this repo covers capital-cost or time-to-revenue projections at all. The Stage 2 draft scored this factor by inference from other factors, and Stage 4 correctly voided it as having nothing to verify. What is verified bounds only the review clock: cleared devices in this class with known decision dates [claim 4: verified], [claim 5: verified], [claim 37: verified]. Whether a 510(k) is even the right pathway is unresolved for a tooling reason worth reading precisely: FDA publishes no De Novo endpoint and this repo holds no cached copy of the De Novo listing, so the "not a De Novo" half is unchecked rather than confirmed [claim 6: unconfirmed]. The app adds SaMD documentation and cybersecurity work that no claim scopes [no claim].
What would settle it: FDA MDUFA performance reports for KPI decision times; a quoted contract-manufacturing BOM for probe and controller — which is now the number that decides this candidate, since the payment side of the comparison is fixed [claim 10: verified]; a PDAC verification timeline.
If it's false: The "cheap and fast" premise that carries this candidate's whole appeal goes with it — and it is still an inference, not a claim.
Would have to be true: Something other than the stimulator would have to be defensible — the file concedes the hardware is commodity — and the proposed asset is the longitudinal EMG-plus-adherence dataset feeding an RTM billing workflow.
Where it stands: Unverified, and the connector says why: the payer-documentation half asserts what payers would require and needs primary research [claim 22: unconfirmed]. There is one genuinely structural lever, and it is a coding rule rather than technology: if PDAC guidance really does reserve E0740 for stimulators with integrated monitoring, then stim-only competitors are excluded from the reimbursed field even though they remain in the overall field [claim 8: unconfirmed], [claim 45: unconfirmed]. That lever got weaker in one respect this week: the incumbent's second clearance already delivers integrated biofeedback, by manometry [claim 37: verified], so "integrated monitoring" does not by itself distinguish this candidate from a device that is already cleared. The dataset moat also depends on patients keeping the device in use [claim 27: unconfirmed] — a moat that decays with adherence.
What would settle it: The PDAC coding-verification record; a payer policy that requires documented adherence or EMG evidence for continued coverage, which would turn the dataset from an asset into a condition of payment; and an FTO position, which does not exist [claim 21: unconfirmed].
If it's false: Commodity hardware, a licensed code anyone can bill, and a dataset nobody requires.
Would have to be true: The prescription home segment would have to be enterable at a rate a new entrant can outrun.
Where it stands: It is not obviously so, and the sharpest number in the whole candidate file is on this slide: 510(k) activity in product code KPI averaged roughly 2.8 clearances a year over 2014-2023, while 2024 through 2026-08-23 totals 14 (2024:4, 2025:4, 2026:6), the 2026 partial year already matching the highest full year on record [claim 25: unconfirmed]. Read plainly, that is a crowd arriving — into a code whose Medicare fee-for-service volume is 4,130 allowed units a year [claim 17: refuted]. The named incumbents are better confirmed than they were: ELITONE is cleared for SUI [claim 4: verified] and holds a second clearance for urge [claim 5: verified], and InControl turns out to hold two distinct KPI clearances rather than one [claim 37: verified]. The consumer-wellness half of the competitive claim remains unverifiable [claim 23: unconfirmed], and the predicate the file most relied on was downgraded on re-verification once its cleared indications could be read [claim 3: unconfirmed].
What would settle it: clearances --product-code KPI over a trailing window for the real entrant count and follower rate; FDA establishment registration and device listing for the US-marketed roster; a licensed source for funding and launches.
If it's false: Read this inverted — the risk is that the file's own count already says the field is filling, and the entrant's advantage window is a function of that rate rather than of anything this candidate controls.
Would have to be true: There would have to be a next test as cheap as the last one, and as decisive.
Where it stands: The last one has been spent. The four claims this slide previously listed as blocked on a missing local file are now resolved — [claim 7: verified], [claim 10: verified], [claim 9: refuted], [claim 17: refuted] — which is the CMS-cache work order closed out. What remains is more expensive in every case. One class cannot be resolved this way at all: the CPT claims are unverifiable by design, because AMA licensing prevents this repo from reproducing the descriptors [claim 11: unconfirmed], [claim 12: unconfirmed], [claim 14: unconfirmed]. That is a licence to buy, not a lookup to run — and it is a permanent cost line for anyone whose reimbursement thesis rests on CPT. The cheapest remaining item is the NCD 230.8 text itself, which is published and free and which this repo's fetch path cannot reach (HTTP 403).
What would settle it: A human opening NCD 230.8 and reading whether it names this device class; then a bill-of-materials quote to set against $74.52 [claim 10: verified].
If it's false: Nothing here is false — this slide is a work order, and the reason this candidate is still in queued-research has changed: not for want of the cheap checks, but because the cheap checks are done and the answers narrowed the case.
Every condition above with nothing verified behind it.
patent connector takes a specific patent number and cannot run a landscape search. The
tooling cannot ask the question, so the answer is not "unknown", it is "unasked".
What is no longer on this list is worth stating: code, payment amount and utilisation volume have all moved off it. The file has real reimbursement evidence now. It is just not encouraging evidence.
If only one thing from this chair could be checked: whether a device supplied under a $74.52 DMEPOS allowable, with no coverage determination naming the code, can carry the $350-$700 net revenue per dispensed system the TAM rests on [claim 10: verified], [claim 18: unconfirmed], [claim 9: refuted].
The previous load-bearing condition was answered, so this deck names the one the answer created. The gap is the whole business case: the only payment figure anyone has verified for this code is roughly a fifth to a tenth of the per-system revenue the TAM assumes, and the claim carrying that assumption is permanently unverifiable through this repo. It is not enough to say the two numbers measure different things — they might, if a cash-pay or bundled model is intended, or if the RTM lines carry the difference — but nothing in the file says which, and [claim 10: verified] warns in its own text that the fee-schedule figure may not even be the relevant payment line for this device.
Settling it needs two things a connector cannot supply: a bill of materials for an app-linked EMG-sensing intravaginal probe, and a stated revenue model. Both are cheap relative to anything else left on this candidate, and neither has been attempted.
Naming it is not a recommendation, a gate, or a kill.