28 Slice Forecasting Tpp

Pipeline Slice: Forecasting and TPP Reporting

Status: SHARP BOUNDARY. Forecasting/TPP is downstream; optional SQL readiness/support models are allowed, but app state, forecast engines, and HTTP contracts are not. Denoising state: sharp (noise -> rough -> sharp -> converged) Updated: 2026-07-23

Purpose

Define the boundary between bioloupe-data and downstream forecasting / target-product-profile (TPP) consumers. This doc exists to prevent accidental rebuilding of the legacy forecasting API/application inside the greenfield data repo.

Legacy evidence says forecasting lived as a separate React/TypeScript app consuming Data Gov over HTTP, with producer/consumer contract tests and Zod schemas in the consumer (../bioloupe-data-gov/docs/forecasting-cross-repo-contract.md). Legacy must-have-variable docs describe readiness gates for disease/indication statistics, but also identify client-owned schema/engine behavior (../bioloupe-data-gov/docs/forecasting-must-have-variables.md). Under the greenfield decision “no API,” the core repo should expose SQL-ready inputs and readiness diagnostics, not app endpoints.

Therapeutic development landscapes, emerging clinical evidence, epidemiology observations, and source-reported commercial facts are core intelligence capabilities, not forecasting internals. They are owned by 33-slice-development-landscapes.md, 34-slice-epidemiology.md, and 35-slice-commercial-intelligence.md. This boundary slice only describes how a downstream forecasting/TPP consumer may use them.

Current Boundary Decision

Forecasting/TPP is downstream by default.

flowchart LR
  DataGov[bioloupe-data canonical assets]
  Q["q_* SQL read models"]
  Readiness[q_forecasting_readiness optional]
  Downstream[Downstream forecasting / TPP app or agent]

  DataGov --> Q --> Readiness --> Downstream
  Q --> Downstream

This means:

• no REST/GraphQL forecasting API in bioloupe-data;
• no forecasting UI/app state owned here;
• no saved-model CRUD owned here;
• no forecast engine/math owned here unless explicitly re-scoped;
• data repo may own readiness/read-model surfaces that say whether downstream forecasting has the data it needs.

Source / Evidence Inventory

Evidence	Greenfield implication
../bioloupe-data-gov/docs/forecasting-cross-repo-contract.md says producer is Data Gov and consumer is bioloupe-forecasting, a separate React/TypeScript app	Treat forecasting app/API as downstream, not core repo.
Contract covered /api/forecasting/statistics, CRUD, pricing, saved model values	Replace API surfaces with SQL read models only if core data support is needed.
../bioloupe-data-gov/docs/forecasting-must-have-variables.md defines gate-enforced must-have variables by disease type	Keep readiness diagnostics as possible core data outputs.
Readiness checker recomputed readiness per request; no cached forecasting_ready column	In greenfield, readiness can be a materialized SQL read model with provenance/checks.
Saved-model bypass lived in downstream client	Do not solve client saved-state problems inside bioloupe-data; expose current readiness truth.

Optional Core Support Model

If downstream forecasting remains important, the data repo can publish supporting SQL models without owning forecasting behavior.

Query model	Grain	Purpose
q_forecasting_inputs	one disease/indication/geo/line variable	current quality-passing input facts with source provenance and curation overlays when applicable
q_forecasting_readiness	one disease/indication/type readiness row	missing-variable diagnostics and ready/not-ready flag
q_forecasting_variable_dictionary	one required variable definition	variable name, disease type applicability, units, source preference
q_tpp_evidence_summary	one product/disease context	optional downstream support projection over development programs, approvals, trials, publications, SOC, epidemiology, and commercial facts

These are read models, not an app API. They must obey 07-sql-query-layer.md: visible in generated q_catalog, explainable through q_provenance where provenance is required, additive evolution, SELECT-only access.

Domain Model Boundary

Concept	Core data repo owns?	Downstream owns?
Disease/indication canonical facts	yes	consumes
Population/incidence/prevalence facts	yes, owned by 34 when sourced/quality-passing	consumes
Therapeutic development programs/landscapes	yes, owned by 33	consumes
Emerging clinical evidence observations	yes, owned by 33 over trial/publication facts	consumes
Source-reported product sales	yes, owned by 35	consumes
Treatment line/SOC context	yes	consumes
Forecast variable readiness	yes, if needed as SQL diagnostics	consumes
Forecast model scenario/saved model	no by default	yes
Forecast engine/math	no by default	yes
Revenue/patient-flow projections	no	yes
TPP report narrative/layout	no by default	yes
Evidence summary for TPP	optionally as a query projection over 33 and source-owning slices	consumes/augments

Slice-Local Entity Resolution

This boundary slice should not introduce new identity rules. It consumes identities from other slices:

• disease and segment context from the disease/biomarker spine (resolved_disease_key, segment_key, resolved_biomarker_keys, treatment_line_key from 30-slice-disease-biomarker-identity.md);
• regulatory approved-use context from approval_indication_key / resolved_approval_key in 22-slice-regulatory-approvals.md when readiness is tied to an approval source;
• SOC context from soc_key / approach_key in 25-slice-standard-of-care.md when readiness is tied to standard-of-care assertions;
• drug/product from drug/regulatory/SOC models;
• organisation/ownership from organisation intelligence;
• pricing/product identifiers from regulatory/NDC/provider sources if retained;
• evidence from trials/publications/news/SOC.
• development-program state and emerging clinical evidence from 33;
• epidemiology observations and selected series from 34;
• source-reported sales from 35 and regulator-owned exclusivity context from 22.

Any new “forecasting variable name” mapping belongs in a variable dictionary, not in global entity resolution.

There is deliberately no standalone indication_key namespace in this boundary doc. An indication-like context is represented by the owner keys above: disease/segment/biomarker/line from 30, approval indication from 22, and SOC assertion from 25. This keeps forecasting readiness diagnostic rather than a hidden domain model.

Curation Override Subjects

Subject kind	Why overrideable
forecasting_variable_definition	Required variable semantics must be stable and documented.
forecasting_input_assertion	Population/pricing/line variables may be sourced/derived and need provenance.
forecasting_readiness_override	Rare reviewed readiness override may be needed but should be auditable.
tpp_evidence_summary_selection	TPP summaries may need reviewed evidence selection, not generated blindly.

Optional q_forecasting_readiness contract seed

This support model exists only if downstream agents need SQL diagnostics. It is not an API and not a forecasting engine.

Contract field	Required meaning
Purpose	Answer: “Do we have enough provenance-backed input facts for a downstream forecasting/TPP consumer to begin work?”
Grain	One disease/indication/geography/line/context + readiness profile.
Stable row key	forecasting_readiness:{resolved_disease_key}:{segment_key}:{treatment_line_key}:{region}:{profile}.
Required columns	readiness_key, resolved_disease_key, segment_key, resolved_biomarker_keys, treatment_line_key, treatment_line, region, approval_indication_key, resolved_approval_key, soc_key, profile_name, required_variable_count, available_variable_count, missing_variables, blocking_missing_variables, ready_state, last_refreshed_at, provenance_key.
Search affordances	filters/facets on disease, segment, biomarker, treatment line, approval/SOC context, region, ready state, and missing variable names.
Provenance rule	provenance_grain=row for readiness diagnostics; bundle only for input facts in q_forecasting_inputs.
Blocking checks	schema_contract, downstream_boundary, provenance_coverage for input facts, and no API/saved-scenario fields.

Readiness is deliberately diagnostic. It may say “missing prevalence for region X”; it must not store a downstream forecast value, scenario, model run, or HTTP payload shape.

Checks and Quality Gates

Blocking for optional SQL support models:

• every readiness row has variable dictionary provenance;
• every disease/segment/biomarker/line/approval/SOC key resolves to an active row in its owning q_* model when present (referential_integrity gate in 08-contracts-and-quality.md);
• every input fact has source provenance and unit/currency/period where relevant;
• no downstream saved-model/scenario shape appears in core data tables;
• no HTTP/API contract is introduced;
• q_forecasting_* or q_tpp_* schemas match generated q_catalog.

Warning:

• readiness missing high-priority variables;
• epidemiology or commercial source facts stale or source-mismatched;
• variable dictionary changed since downstream last validated;
• downstream-only fields creeping into core docs/tables.

Deferred Decisions

• Build q_forecasting_readiness only when a named downstream consumer adopts its SQL contract.
• Build q_tpp_evidence_summary only when a named agent workflow needs a standardized projection that cannot cleanly query the owner models.