US-Federal Only: Why the Registry Stops at State Lines

Every row in the facts registry carries jurisdiction: US-federal. The field is small, the commitment behind it is not — it is a promise that no model is quietly pretending to know your state.

The question arrives early in any integration conversation: what about state taxes? The answer is a scope statement worth reading in full rather than a limitation to apologize for. Worthune's registry and models are US-federal, every registry row says so in its jurisdiction field, and the specs name state-level rules in their exclusions. This piece explains why the line sits where it sits, what would have to be true to move it, and how integrators handle the state layer cleanly in the meantime.

What maintaining a jurisdiction actually costs

The registry's discipline is that every constant carries a primary source, a period, a verification date, and a consumer. Meeting that bar for federal rules means tracking a known set of documents on two annual cadences — the October–November IRS announcements and the spring §223 procedure — plus occasional statutes. Meeting it for state rules means multiplying that by fifty legislatures, fifty revenue departments, mid-year special sessions, and local overlays like county property-tax schedules. The multiplication is not just effort; it is failure surface. A registry row that exists but is stale is worse than a row that simply does not exist, because the stale row carries the registry's credibility with it. Fifty jurisdictions maintained at the same verification bar is a different product with a different team, and pretending otherwise would spend the registry's trust to buy its breadth.

Where the line shows up in the models

The property-tax portion of a housing comparison is a user-supplied input, not a computed one, because property tax is local. The tax models compute federal brackets, federal capital-gains thresholds, the federal net investment income tax — and where a state amount appears at all (the RSU model's flat state rate, the estate model's state rate), it is a user-supplied input applied as given, never a computed state rule; the remaining tax specs list state income tax in their exclusions. The quarterly-estimates model handles federal estimated taxes; a Californian's state obligations are real and explicitly out of scope. Nothing in the catalog silently blends a state guess into a federal computation, which means every state-shaped number in a Worthune-backed product is one the product itself chose and can account for.

Integrator patterns for the state layer

• ✓Surface the scope — the models' own disclaimers and assumptions name the federal scope, and your UI should not bury it.
• ✓Collect state-dependent amounts as inputs where the models take them — property tax, insurance, quoted premiums.
• ✓If your product needs computed state tax, source it from a state-specialist provider and keep its provenance separate from the federal envelope.
• ✓Never subtract a guessed state adjustment from a verified federal answer inside your own code — compose surfaces, do not blend numbers.
• ✓Watch the roadmap rather than assuming — jurisdiction expansion would arrive as specs and registry rows, not as a silent widening.

The composition pattern in the third and fourth items is the load-bearing one. A verified federal computation plus a clearly labeled state estimate from a state specialist is an honest product: two numbers, two provenances, each defensible on its own terms. A single number that secretly merges them is not — it inherits the weakest provenance in the blend while displaying the confidence of the strongest.

What would move the line

Jurisdiction is not dogma; it is a bar. A state row would need what every federal row has — a primary source, a maintenance cadence someone owns, a verification date that stays current, and a consuming model whose spec documents the state-specific behavior. The roadmap page, which promises themed packs and no dates, is the only place a commitment like that would appear. Until it does, the jurisdiction field is the registry telling the truth about itself — and a field that tells the truth when the truth is "not yet" is exactly the field you want certifying "yes" everywhere else.