What changed
FACT (source: Federal Register 2026-10116, IRS/Treasury): final regulations modify the information-reporting obligations for sales or exchanges of certain interests in partnerships owning inventory or unrealized receivables (Section 751 'hot assets'). INFERENCE: the obligation in question is the Section 6050K information return, in practice Form 8308, plus the statements furnished to the transferor and transferee. The source text does not name the form, does not state an effective date, and does not state a respondent count — all of that is inference in the input, not fact.
Why now
FACT: the regulations are final, not proposed, so the obligation is fixed rather than speculative. HYPOTHESIS (not supported by the provided source text): practitioners have struggled with the Part IV 751 gain-breakdown requirement because the partnership frequently does not have the transferor's information or a completed hot-asset valuation by the statement deadline; if that is true, a computation-and-generation tool has a real pain to attach to. This must be verified against the actual regulation text and any accompanying IRS notices before any build.
Converging signals
Weak. There is exactly ONE substantive signal here: the Federal Register rule itself, appearing twice in demand_evidence (once as a matched item at similarity 0.735 and once as the structural parent of this opportunity — the same document double-counted). The third evidence item, the CFPB international-money-transfer larger-participant rule (similarity 0.727), is topically unrelated and is retrieval noise, not convergence. Per the system's own lesson at 0.89 confidence about fabricated demand retrieval, that item should be discarded. Calling this a convergence of three signals would be self-deception: it is one rule.
Customer pain
INFERENCE: a CPA firm preparing Form 1065 must (a) detect that a reportable transfer occurred, (b) determine whether the partnership holds Section 751 property, (c) compute the ordinary-income portion of the transferor's gain, and (d) issue correct statements to both parties. Steps (b) and (c) are judgment-heavy revaluation work, not form-filling. Penalty exposure runs per return and per statement under IRC 6721/6722, so a missed or wrong filing is expensive. HYPOTHESIS: this is the pain. No complaint threads, job postings, or practitioner discussion were supplied to corroborate it.
Who pays
Small-to-midsize CPA firms and partnership-tax boutiques; secondarily, fund administrators for PE/VC/real-estate funds where LP interest transfers are routine. The buyer is reachable (state CPA societies, tax-practitioner conferences, NAEA/AICPA tax-section channels) and is emphatically NOT a government procurement office — the enterprise_sales flag does not apply. But this buyer is conservative, professionally liable for the output, and buys tax computation tools almost exclusively through its incumbent tax-software vendor.
Solved today
INFERENCE, high confidence but unverified against the source: CCH Axcess/ProSystem, Thomson Reuters UltraTax, Intuit Lacerte/ProConnect, and Drake all already generate Form 8308 as part of the 1065 module. What they generally do NOT do is compute the 751 ordinary-income figure — that is entered by the preparer, derived from a hot-asset schedule built by hand in Excel, or bought as an hourly engagement from a partnership-tax specialist.
Why current solutions are bad
The form is auto-generated but the number that goes in it is not. The preparer carries the liability for a figure the software refused to compute. That is a genuine, narrow seam. HYPOTHESIS.
Proposed product
NOT the 'engine' described in the convergence title. The title's product — detect reportable transfers from partnership books, compute the split, generate the return, and track filings — is four products, three of which are already owned by incumbents. The only defensible slice is the computation: a Section 751 hot-asset gain calculator that takes a trial balance, a fixed-asset schedule, an inventory listing, and the transfer terms, and produces a defensible, workpaper-backed ordinary/capital split with the Form 8308 Part IV values and a memo citing the authority for each allocation. Sell the workpaper and the audit trail, not the PDF.
MVP version
A web app with a structured intake (partnership balance sheet, inventory at cost and FMV, unrealized receivables including depreciation-recapture items, transfer date, percentage transferred, consideration), a deterministic 751(a) computation engine, and a generated PDF workpaper plus fillable Form 8308 Part IV values. No ledger integrations. No e-file. No portal submission — note that unlike the founder's ELDT product, THERE IS NO PORTAL HERE: Form 8308 attaches to the 1065 and the statements are furnished to partners. The founder's proven government-portal-integration edge does not transfer to this idea. That is an important correction to the surface-level founder-fit read.
30-day build
Do not build. Read the actual final regulation and the preamble at the cited URL; confirm which form and which obligation changed, and whether a computation requirement was added, relaxed, or deferred. Then interview 15 partnership-tax preparers at firms of 5-50 people. Ask one question: 'When a partner sells an interest and the partnership holds inventory or receivables, who computes the ordinary-income piece, how long does it take, and what do you charge for it?' If the median answer is 'the tax software does it' or 'it almost never comes up,' kill the idea outright.
60-day build
Conditional on the interviews showing manual Excel work and billable hours: build the computation engine against three real anonymized fact patterns supplied by an interviewee. Have a partnership-tax attorney or an EA with 751 experience review the allocation logic on a paid engagement — the founder has capital and this review is non-optional, because the product's entire value is being right.
90-day revenue plan
Sell per-computation at a price anchored to the preparer's billable hour, not to a SaaS seat. First revenue would come from the small number of firms that already have a transfer in progress. Revenue in the 30-180 day window is unlikely because partnership-interest transfers are episodic and cluster around the 1065 season; a March-April launch has a demand window, a July launch has none.
Distribution path
Weakest dimension. CPA firms do not adopt tax-computation tools from an unknown solo vendor without professional-liability comfort. Realistic channels: a paid content wedge (an authoritative free 751 explainer that ranks), continuing-education webinars through a state CPA society, and the specialist consultants who currently do this work by hand — sell to them as a tool, not to the firms as a replacement. The founder's stated preference for selling through demonstrated value rather than relationship sales works against him here: this is a trust purchase.
Pricing hypothesis
$300-800 per computation, or $3,500-6,000/year for a firm-level seat. Below the cost of two billable hours of a partnership-tax specialist; above the psychological threshold where a CPA suspects the answer is unreliable.
Technical difficulty
Moderate-to-high, and not where the founder is strong. The engineering is trivial; the domain modeling is not. Section 751(a) hot-asset allocation involves hypothetical-sale mechanics, depreciation recapture characterization, and interaction with Section 743(b) basis adjustments when a 754 election is in place. Getting this wrong produces a confidently-formatted wrong number, which is worse than no product.
Legal / regulatory risk
Real, and it is the kind the founder's own profile says to avoid. Producing tax computations that a licensed preparer signs creates a professional-liability tail. The founder does not need to become licensed to sell a calculator — so heavy_compliance is not flagged in the founder-must-be-certified sense — but he does need E&O coverage and careful disclaimer framing, and a single materially wrong allocation on a large transfer is a lawsuit.
Platform dependency
None. No platform owner can deplatform this, and there is no government portal to be locked out of. Also no portal to build a moat around.
Founder fit
Lower than the FedMoney framing suggests, and this is the crux. The public-money/forced-filer thesis scores maximal when a regulation compels a defined class to submit to a government portal and a solo operator can own the submission layer. Here the regulation compels a filing that is already bundled into software every filer owns, there is no portal, and the residual value is a tax-law computation requiring domain expertise the founder does not have and cannot acquire in 90 days. The thesis pattern-matches on 'IRS final rule + forced filer' and misfires. Systems thinking and fast prototyping do not substitute for partnership-tax judgment.
Breakout potential
Low. Episodic transaction volume, no network effects, no data moat, and a ceiling set by the number of hot-asset transfers per year — which the input concedes is an unstated subset of ~4 million partnership returns. The '4 million returns' figure is an inference in the input, not a fact from the source, and it is not the addressable market; the addressable market is the unknown subset with reportable transfers, which could plausibly be tens of thousands of computations a year across all firms.
Final recommendation
KILL. Not because it needs upfront capital or a six-month ramp — the founder can fund both — but for four of the enumerated right reasons at once: it is trivially copyable by incumbents who already ship the form, it has no defensible wedge, it faces a long trust cycle with a conservative professionally-liable buyer, and the single supporting source does not actually establish that a new filing burden exists. The FORCED BUYER label on the evidence is doing far more work than the evidence supports: a rule that 'modifies information reporting obligations' is not the same as a rule that creates a compelled filer class with a deadline and a portal. The system's own high-confidence lesson — that government-portal mandates fit this founder best — is being applied to an opportunity with no portal. I am explicitly declining to score this into the acceptance band to satisfy the pattern; the pattern does not fit. Do not build. If a single cheap action is warranted, it is 30 minutes of reading the actual regulation to confirm this kill, not a product.
Next action
Open the cited Federal Register rule and read the preamble and the amended CFR text. Determine (1) which form is actually affected, (2) whether the amendment adds or reduces burden, and (3) whether any respondent count appears in the Paperwork Reduction Act section. If the rule reduces burden or defers a requirement — which is a live possibility given that the input could not identify a deadline — record the kill and, more importantly, fix the ingestion: the pipeline surfaced a rule as a FORCED BUYER mandate without confirming a filer class, a submission, or a deadline. That is the reusable lesson from this run and it is worth more than the idea.