link-entity-taxonomy with basis='reporting' silently renders empty statements (no framework-match validation)

[jfrench9]

Summary

A tenant can link a custom_ontology / reporting_extension taxonomy as the reporting basis via link-entity-taxonomy (basis='reporting', is_primary=True) and the call succeeds — but it does not drive rendering. The renderer selects networks off Graph.reporting_style_id, never EntityTaxonomy, so the statements render empty with no error.

This is a latent UX trap: it bites whenever someone links a non-rs-gaap taxonomy as the reporting basis (the self-service / custom-framework path). It is independent of, and exists prior to, the post-launch custom-framework work tracked in local/RoboSystems/specs/taxonomy-block-framework-authoring.md.

Impact

Low (latent). No current rs-gaap user hits it; it surfaces as soon as a non-rs-gaap reporting taxonomy is linked. Failure mode is silent-empty — the worst kind: no error, just blank statements.

Environment

Production (code-level; present in all environments, reachable only via the non-standard link path).

Steps to Reproduce

1. Author an in-graph taxonomy with a non-rs-gaap namespace (a custom_ontology / reporting_extension Taxonomy Block).
2. Call link-entity-taxonomy with basis='reporting', is_primary=True for that taxonomy — it is accepted (no validation rejects it).
3. Render the entity's financial statements (e.g. live-financial-statement / a report build).

Expected Behavior

Either the link is rejected (or render fails) with a clear, actionable error — e.g. "this taxonomy has no renderable Reporting Style / framework mismatch" — so the user understands why the statements can't render.

Actual Behavior

The link succeeds and the statements render empty, with no error or diagnostic. The renderer never consults the linked EntityTaxonomy; it walks reporting_style_networks for Graph.reporting_style_id (which still points at the rs-gaap default), and the rs-gaap namespace pins find nothing for the foreign framework.

Error Messages / Logs

(none — that is the bug: empty output, no error raised)

Additional Context

Evidence (verified against source):

• link_entity_taxonomy checks only entity-exists / taxonomy-exists / dedup on (entity, taxonomy, basis) and clears the prior primary — there is no validation tying basis to the taxonomy's taxonomy_type: robosystems/operations/roboledger/commands/taxonomies.py (link_entity_taxonomy, ~:513-579).
• basis CHECK ∈ ('reporting','chart_of_accounts','mapping','schedule'), with no taxonomy_type correlation: robosystems/models/extensions/entity_taxonomy.py:57-60.
• The render path reads graphs.reporting_style_id from the platform DB and joins reporting_style_networks ⋈ structures on (reporting_style_id, statement_type) — it never consults EntityTaxonomy: robosystems/operations/roboledger/reports/network_picker.py:48-101.
• Compounding factor: the renderer also has ~6 hardcoded rs-gaap namespace pins on its derivation paths (subtotal persistence, NetIncome/PP&E synthesis, cash-flow attribution, close-to-equity, reachability validation), so a foreign-namespace framework renders empty even if Style selection were wired — e.g. robosystems/operations/roboledger/reads/taxonomies.py:934-939 (_CANONICAL_ROOTS).

Suggested fix (small, standalone — does NOT require the custom-framework work): at link time and/or render time, validate that the render target's framework matches the active Reporting Style's framework, and surface a clear "framework not renderable / no matching reporting style for this taxonomy" error instead of returning empty output. A guard rail, not a feature. Same failure class as the reachability "looks fine but the report is empty" traps.

References: local/RoboSystems/specs/taxonomy-block-framework-authoring.md §1, §5, §8 (surfaced during the framework-authoring research).

[jfrench9]

Re-verified against main (2026-08-04). The bug still reproduces exactly as described — one line of the evidence has gone stale.

Correction

The body says:

The render path reads graphs.reporting_style_id from the platform DB and joins reporting_style_networks ⋈ structures …

Reporting Style moved from the graph to the entity on 2026-07-10 (45b7574, extensions migration 0020_entity_reporting_style), about two weeks after this was filed. The render path now keys off entities.reporting_style_id in the extensions DB, not graphs.reporting_style_id in the platform DB — see the network_picker.py docstring, which names entities.reporting_style_id directly.

Everything else holds

• network_picker.py:54-91 still selects networks by (reporting_style_id, statement_type) and never consults EntityTaxonomy — the move changed where the style id is read from, not that the linked taxonomy is ignored.
• link_entity_taxonomy (operations/roboledger/commands/taxonomies.py) still validates only entity-exists / taxonomy-exists / dedup on (entity, taxonomy, basis), with no basis ↔ taxonomy_type correlation.
• The basis CHECK constraint is unchanged.
• The rs-gaap namespace pins are intact — _CANONICAL_ROOTS at operations/roboledger/reads/taxonomies.py:933-938 still hardcodes rs-gaap:Assets, rs-gaap:LiabilitiesAndStockholdersEquity, rs-gaap:NetIncomeLoss, rs-gaap:CashAndCashEquivalentsPeriodIncreaseDecrease.

Net effect on the fix: unchanged in shape, but a render-time guard now reads the style from the entity row rather than the graph row.