idea-009 · 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 run this as a DMEPOS supply business — buying textile tooling, enrolling as a supplier, and getting paid one wrap at a time out of Medicare Part B.
How to read this: every slide is a condition, not a conclusion. A bracketed reference points into knowledge-base/candidates/idea-009.md — the number is the claim's position in its ## Claims list, the tag is copied from it and never adjusted here. [no claim] means nothing in the file speaks to the condition. No number appears on this deck that is not in a claim, and there is no ask slide. See docs/deck-spec.md.
One thing to hold while reading: the candidate's Verified Composite is 6.0/100 over 1/9 factors verified, and the one verified factor is Regulatory. Reimbursement, TAM, FTO, moat and competitive intensity — every factor on this deck — have zero verified claims behind them. That is "almost nothing has been established", not "the answer is no".
Would have to be true: Medicare Part B would have to pay for this out of the lymphedema compression treatment items benefit, billed by an enrolled DMEPOS supplier, for items furnished on or after 2024-01-01 — that benefit category is the entire reason this candidate exists in this form.
Where it stands: Unread against any primary source, and for a structural reason worth stating: the benefit category was created by statute (the Lymphedema Treatment Act as enacted in the Consolidated Appropriations Act, 2023), and connectors regulation serves CFR text only — it reaches neither the US Code nor the CMS transmittals and MLN Matters articles where the effective date is actually published [claim 10: unconfirmed]. The Verifier's probe of the implementing-regulation side returned HTTP 503 from an eCFR endpoint that was down all day, which establishes nothing either way. The payment mechanics on top of it — 80% of the lesser of actual charge or the DMEPOS fee schedule amount, deductible and coinsurance applying — are likewise unread [claim 11: unconfirmed]. Payers outside Medicare FFS are not addressed anywhere in the file; that went on record only with this deck [claim 35: unverified].
What would settle it: The CMS transmittal or MLN Matters article implementing the LTA, downloaded into data/ by a human or Scout — no connector reaches it. Then re-run connectors payment A6583 once data/hcpcs_payment_rates.csv is present, confirming the schedule field reads DMEPOS and not PFS or OPPS.
If it's false: Factor 2 (reimbursement pathway) has no budget line behind it, and the product's whole design rationale — below-knee only, sized to one code's descriptor — was optimised against a benefit that either does not exist as assumed or starts on a different date.
Would have to be true: All three would have to land independently: a code whose descriptor this product fits, a fee-schedule amount large enough to be a business, and a coverage policy that does not narrow the diagnosis or cap the quantity below what the therapy needs.
Where it stands:
data/hcpcs_level_ii.csv is absent, so
the file's strongest-looking asset is entirely unread against primary CMS text
[claim 8: unconfirmed]. The garment comparators A6552 and A6554 are unread for the same
single reason [claim 9: unconfirmed]. A missing cache is a data gap, not a negative result.
data/hcpcs_payment_rates.csv is absent, so the 80%-of-lesser rule is a formula with an
unknown operand [claim 11: unconfirmed], and the net selling price it would bound is
unverifiable by design [claim 16: unconfirmed]. No estimate is supplied here.
coverage connector
confirms policy existence, not a positive stance, while "any diagnosis of lymphedema" is
exactly the breadth an LCD narrows [claim 12: unconfirmed]. Billing mechanics sit on top:
RT/LT laterality modifiers [claim 13: unconfirmed] and a PDAC coding-verification review
with quantity and replacement limits, neither requirement nor allowance established
[claim 14: unconfirmed].
What would settle it: One human drops the CMS quarterly files into data/ per data/README.md and every hcpcs, payment, coverage and procedures line in the file re-runs unattended — the file names this as the cheapest fix it contains. The coverage breadth then needs the DME MAC Local Coverage Determination and its Policy Article read directly, with the L-number pulled from the CMS Medicare Coverage Database rather than guessed. PDAC's own published procedure and product list is a separate human retrieval.
If it's false: Any one of the three failing takes Factor 2 with it. A code without a payment amount is not a pathway; a payment amount under an LCD that excludes most lymphedema diagnoses, or caps replacement below the wear life, is a different business at a different scale.
Would have to be true: Four separate quantities would have to be known and multiply to something worth building: how many patients, how many wraps a year each, at what net price, and what share this entrant could reach against four incumbents.
Where it stands:
data/medicare_procedure_volumes.csv
is absent [claim 15: unconfirmed]. Two cautions travel with it when it lands: a Medicare FFS
count is a floor on US volume, never a market size, and for a code first payable
2024-01-01 a low number would be a young-code artefact, not a small market.
unverifiable by design and permanently so absent a human-attached licensed report;
the DMEPOS allowable that would have capped it is itself unread [claim 16: unconfirmed]. No
price is asserted in the file and none is asserted here.
unverifiable as a
market claim, and an adoption claim in market-share clothing that also depends on the
fitter-channel assumption [claim 17: unconfirmed], [claim 24: unconfirmed].
What would settle it: connectors procedures A6583 once the CMS utilisation file is in data/ — the only component with a real primary source. Components 2 and 3 move only when a human attaches a licensed compression-therapy market report and edits the claims by hand, plus a denominator of enrolled DMEPOS compression suppliers from the CMS supplier-enrollment public file and certified fitter counts from the accrediting-body registry. Component 3 additionally costs a round of fitter and supplier interviews.
If it's false: Factor 3 is already at the floor as a placeholder for "unquantified" rather than an estimate of a market, and the Gate Check records that the TAM kill condition cannot be evaluated because the operand is undefined. If the volume comes back genuinely small for reasons other than code youth, that condition becomes evaluable for the first time.
Would have to be true: The path to first revenue would have to be textile tooling, fitter training, PDAC coding verification and CMS-855S supplier enrolment — not an FDA submission, a predicate and a clinical study.
Where it stands: Conditional on a question this file has not settled, and the file says so in the load-bearing word of the claim itself: "on the exempt route". § 880.5780(b) is verified Class I and exempt from premarket notification under subpart E of part 807 [claim 2: verified] — but the same verified primary text identifies the device as one "constructed of elastic material" against an expressly inelastic mechanism, and § 880.9 requires a premarket notification anyway for lay use where the former intended use was professional-only, against an indication of self-application without a fitter; whether this device is inside that generic type at all is an FDA judgment no connector answers [claim 6: unconfirmed]. The file's own conclusion: if either goes the other way this is not a slightly worse row, it is a different business [claim 22: unconfirmed]. No dollar figure and no calendar figure appears anywhere in this file, deliberately — see the feasibility deck for the build side. The billing-side long pole, PDAC verification for a new entrant, went on record only with this deck [claim 32: unverified].
What would settle it: A 513(g) Request for Information to FDA, or Tier 3 regulatory-counsel review of the draft labelling — the two routes the file names, neither of which is an agent action. Then PDAC's published coding-verification procedure and turnaround, and CMS-855S enrolment timelines from CMS enrolment guidance, retrieved by a human. Tooling and fitter-training cost is a Tier 3 human estimate, not a lookup; nothing here estimates it.
If it's false: Factor 7 is not a downgrade, it is a replacement — a submission, a predicate search in a database where exempt competitors do not appear, and a calendar nobody in this file has sized.
Would have to be true: The printed strap elongation window and its calibration would have to be protectable, and the certified-fitter / DMEPOS channel would have to be harder to enter second than first.
Where it stands: Weak by the file's own account, and unexamined rather than clear. The IP half cannot resolve ahead of FTO: no patent search was performed and no patent number is named, PATENTSVIEW_API_KEY is unset, and no connector in this repo performs patent discovery — so the indicator is an asserted differentiator, not a demonstrated asset [claim 19: unconfirmed], [claim 20: unconfirmed]. The channel half returned unverifiable by design [claim 20: unconfirmed]. And the regulatory position is explicitly not a moat: the verified text of § 880.5780 exempts the generic type from premarket notification [claim 2: verified], [claim 3: verified], so the exemption protects incumbents and entrants symmetrically — an open door, not a barrier. Whether an incumbent would simply copy the indicator went on record only with this deck [claim 34: unverified].
What would settle it: A human or Scout assignee sweep — medi GmbH, Essity/BSN, Sigvaris, Solaris — in USPTO Patents Public Search and Espacenet, with CPC class A61F13/08 and keyword sets on strap tension and elongation indicators, to produce numbers; only then does setting PATENTSVIEW_API_KEY and running connectors patent US<number> become useful. The ordering matters and is easy to get backwards. The channel half needs commissioned fitter and supplier interviews on brand-switching and shelf economics.
If it's false: Factor 5 has nothing left, and Factor 4 is worse than that — FTO is the rubric's only automatic kill regardless of other scores, and the Gate Check records it as cannot be evaluated, with zero patents searched, in exactly the narrow art four long-established incumbents occupy.
Would have to be true: The four incumbents this file names by name — medi circaid juxtafit/juxta-lite, Essity/BSN JOBST FarrowWrap, Sigvaris Compreflex, Solaris — would have to be beatable in a channel they already own, and the same 2024 benefit that makes this attractive would have to not have made it equally attractive to them.
Where it stands: The competitor count is unmeasured, and that is emphatically not zero. Because the launch route is 510(k)-exempt [claim 2: verified], competing wraps do not appear in openFDA's 510(k) database at all, so a null there is a property of the exemption rather than evidence of an empty field [claim 7: unconfirmed]. The Verifier demonstrated the failure mode deliberately and it must be read before anyone treats this factor as favourable: the query 510k "juxtafit" --applicant "medi" returned connector status refuted — purely from database absence — about a product this file's own predicate_or_analog: frontmatter names as a live commercial incumbent [claim 7: unconfirmed]. That is not a finding that medi has no such product or does not compete, and no 510k or clearances result may be read as whitespace, as a moat, or as an input to this factor. A separate query returned verified on K162481, an unrelated powered compression device that merely name-matches — so the null is not even reliable in the direction the claim predicted. Whether the field really is four firms went on record only with this deck [claim 33: unverified].
What would settle it: Not clearances. The database where exempt-route competitors actually appear is FDA Establishment Registration & Device Listing, queried by product code — no connector in this repo reaches it, so it is a Scout or human retrieval into data/, and it is the specific check that converts a structural null into a real competitor count. Run connectors classification --product-code FQL first to get the code right [claim 4: verified].
If it's false: Factor 8 is already scored at 1/5 on the draft table (low score = high intensity) and is blank in the verified composite. A count that comes back much larger than four does not change a score that does not exist yet — it changes whether the channel assumption on Slide 3 was ever plausible.
Would have to be true: The unit economics would have to survive the arithmetic: the DMEPOS allowable, minus the dispensing supplier's or fitter's channel margin, minus manufactured cost, would have to leave a positive gross margin — and that arithmetic would have to be computable from files a human can download this week.
Where it stands: Two of the three terms are unread for the same single, cheap reason. The allowable needs data/hcpcs_payment_rates.csv [claim 11: unconfirmed]; the channel margin is an unverifiable market claim [claim 16: unconfirmed]; the manufactured cost appears nowhere in the file, since the capital claim is deliberately stated without a dollar figure [claim 22: unconfirmed]. The margin condition itself went on record only with this deck [claim 31: unverified]. The file's own assessment of sequencing is worth carrying: causes A (missing CMS caches) and B (the eCFR outage) together would resolve up to 11 claims and would likely lift Reimbursement and TAM out of blank at low cost — a data-and-infrastructure task, not a research one.
What would settle it: The four CMS quarterly files into data/, then re-run the hcpcs/payment/coverage/procedures lines unattended; re-run the three eCFR-dependent lines once the endpoint recovers, which is free. Manufactured cost is a Tier 3 human estimate against a real textile quote — not a lookup, and not estimated here.
If it's false: If the allowable minus channel margin does not cover cost, nothing else on this deck matters and the reimbursement anchor that motivated the whole design becomes the reason it cannot be sold.
Every condition above with nothing verified behind it. The candidate's five verified claims are all regulatory — the regulation's text, its two paragraphs' classes and exemptions, and two product codes [claim 1: verified], [claim 2: verified], [claim 3: verified], [claim 4: verified], [claim 5: verified] — and none of them is about money. Every factor on this deck is blank in the Verified Composite.
If only one thing from this chair could be checked: what Medicare actually allows for A6583, and to whom [claim 11: unconfirmed], [claim 8: unconfirmed], [claim 12: unconfirmed].
This one rather than the others because it is simultaneously the most decisive and the cheapest. It is decisive because the entire candidate was engineered backwards from this code — below-knee only, 30-50 mmHg, adjustable straps, all chosen to match a descriptor — so if the allowable is thin or the LCD narrow, the design rationale itself is what fails, not merely the forecast. It is cheap because the block is not an obstacle but an absence: data/ contains only README.md, so the descriptor, the payment amount, the coverage policy and the utilisation volume were never searched at all, and one human placing four CMS quarterly files resolves up to eleven claims unattended. And it is prior to the rest: without the allowable, Slide 7's margin arithmetic has no first term, Slide 3's price component has no ceiling, and the file's strongest-looking asset stays what the Gate Check calls it — an artifact of nobody having checked it.
Naming it is not a recommendation, a gate, or a kill.