Problem
policyengine-household-api is the simplest downstream consumer of the country packages, which also means its provenance story is currently the thinnest.
Today it:
- instantiates the installed country package
Simulation(...) directly
- reports or logs API version metadata for analytics
- does not expose model/data bundle identity in household calculation responses
- does not let callers observe which immutable dataset/model release actually produced a result
Relevant code paths:
- installed package metadata and direct simulation construction:
policyengine_household_api/country.py
- persisted analytics/version fields:
policyengine_household_api/data/models.py, policyengine_household_api/decorators/analytics.py
- household endpoint response surface:
policyengine_household_api/endpoints/household.py
- OpenAPI spec currently documents API versioning, not full execution-bundle provenance:
policyengine_household_api/openapi_spec.yaml
Desired contract
Even for household-level calculations, the API should expose the resolved immutable execution bundle.
At minimum that means returning or persisting:
- country model package version
- country data package version when relevant
- resolved dataset or release-manifest identity if household calculations rely on default package data
- a structured bundle field rather than only API version metadata
This is important both for user trust and for debugging when results drift across releases.
What should change
- Resolve and surface the runtime model/data bundle used for each calculation.
- Extend response schemas and OpenAPI docs to expose structured provenance.
- Persist the bundle identity anywhere cached or saved household results are stored.
- Keep existing
api_version analytics if useful, but do not rely on it as the only provenance field.
- Ensure future automated country-package bumps preserve or update bundle metadata rather than just package versions.
Acceptance criteria
- Household responses expose structured model/data bundle provenance.
- OpenAPI documentation includes the new provenance fields.
- Saved or cached household calculations can be tied back to the resolved execution bundle.
- Existing analytics/version fields remain optional metadata, not the sole execution identity.
- The service can reconstruct which model/data bundle produced a historical household result.
Upstream dependencies
This should consume the release contracts from:
And stay aligned with:
Problem
policyengine-household-apiis the simplest downstream consumer of the country packages, which also means its provenance story is currently the thinnest.Today it:
Simulation(...)directlyRelevant code paths:
policyengine_household_api/country.pypolicyengine_household_api/data/models.py,policyengine_household_api/decorators/analytics.pypolicyengine_household_api/endpoints/household.pypolicyengine_household_api/openapi_spec.yamlDesired contract
Even for household-level calculations, the API should expose the resolved immutable execution bundle.
At minimum that means returning or persisting:
This is important both for user trust and for debugging when results drift across releases.
What should change
api_versionanalytics if useful, but do not rely on it as the only provenance field.Acceptance criteria
Upstream dependencies
This should consume the release contracts from:
And stay aligned with:
policyengine.pythe immutable release boundary for country model and data versions policyengine.py#270