Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Integrate OG-USA through the common OLG adapter contract

未关闭
#77 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
冷清
技术栈
python

调研方向

首先阅读 integration/src/policyengine_macro/core.py 中现有的 OG-UK 部分,以及 integration/tests/test_og.py 中的结构测试。在设计适配器之前,验证文档所述的 ogusa 安装和公开的 CPS baseline。完成要求包括:明确的路由、来源、收敛和单位元数据、经过审查的改革处理、公共数据测试,以及保持 OG-UK 行为不变。

由索引模型根据 Issue 内容生成。

描述

Objective

Add OG-USA as a separate US overlapping-generations member, following the integration pattern already established for OG-UK while preserving the differences in policy vocabulary, calibration data, units, runtime, and validation.

This is not a fork or reimplementation. The model stays upstream at PSLmodels/OG-USA; PolicyEngine Macro supplies a thin, tested adapter, common result metadata, CLI/MCP discovery, and documentation.

Upstream feasibility baseline

  • Package: ogusa 0.4.0, Python 3.12–3.13.
  • Source: PSLmodels/OG-USA, CC0-1.0.
  • Core solver: PSLmodels/OG-Core.
  • Public packaged calibration assets include default parameter JSON, CPS, SCF and PSID files.
  • Optional/restricted profiles include PUF/TMD inputs; some calibration paths require a FRED API key.
  • Upstream states that a full baseline/reform transition-path run can exceed two hours. Hosted synchronous execution must not be promised before measurement.
  • Documentation: https://pslmodels.github.io/OG-USA/content/intro/intro.html

Integration design

1. Keep the UK and US models distinct
  • Add canonical registry ID og-us; retain og-uk.
  • Let score_reform(country="us", model="og") route explicitly to OG-USA and country="uk" to OG-UK, or expose unambiguous og-us / og-uk selectors. Test whichever public contract is chosen.
  • Never label OG-UK as UK + US or treat the two calibrations as interchangeable.
  • Record ogusa, ogcore, adapter, tax-calculator and calibration-data versions separately in provenance.
2. Start with a public-data profile
  • Establish a clean installation using pip install ogusa==0.4.0 (or a reviewed commit pin).
  • Run the baseline from packaged/public CPS calibration without PUF, TMD or private credentials.
  • State exactly which CPS, SCF, PSID, demographic, FRED and Tax-Calculator inputs are read, including dates and hashes where feasible.
  • Keep PUF/TMD profiles optional and local; tests requiring restricted data must be separated from the public acceptance gate.
  • Fail with actionable errors when an optional API key or restricted dataset is requested.
3. Build the adapter beside the OG-UK adapter

Use the existing OG-UK section in integration/src/policyengine_macro/core.py and integration/tests/test_og.py as the structural reference, not as code to generalize prematurely.

  • Add lazy _import_ogusa() loading with an exact installation error.
  • Add a cached US baseline keyed by every result-changing input: start year, dataset profile, model dimensions, solver configuration, policy baseline and source revision.
  • Implement an initial steady-state-only adapter; expose transition paths only after runtime, storage and schema review.
  • Return baseline and reform solver residuals/convergence status. A non-converged solve must fail, not serialize a plausible-looking result.
  • Map OG-USA/OG-Core outputs into the common ScoreResult without dropping native output.
  • Declare USD units, price basis, annual/steady-state time basis, geography, baseline definition, uncertainty and comparability on every quantity.
  • Preserve GDP, consumption, investment, wages, interest rates, government debt and tax-revenue outputs where supported; do not invent a quantity merely to match OG-UK.
4. Use a reviewed reform bridge

OG-USA currently calibrates federal taxes through Tax-Calculator, while PolicyEngine Macro accepts PolicyEngine reform objects. Similar names do not establish equivalent definitions.

  • Create a small, versioned catalogue of reviewed PolicyEngine-US → OG-USA/Tax-Calculator mappings.
  • For each mapping, declare source path, destination parameter, units, effective date, federal/state scope, transformation and tests.
  • Initially support only reforms whose semantics can be shown equivalent. Reject every unsupported path with an explanation and list of supported examples.
  • Do not use an LLM or fuzzy name matching to invent mappings or unit conversions.
  • Provide a separate expert escape hatch for direct OG-Core specification overrides; label these structural scenarios rather than PolicyEngine reform scores.
  • Do not pass state or local tax reforms into a federal OG-USA calibration unless an explicit model channel exists.
5. Access and runtime policy
  • Benchmark cold import, calibration, baseline steady state, reform steady state and full TPI separately on representative hardware.
  • Launch as local/experimental unless a steady-state pair fits hosted limits with safe memory, timeout and cost headroom.
  • If custom hosted runs exceed synchronous limits, use asynchronous jobs or precomputed reviewed scenarios; do not raise Modal timeout indefinitely.
  • Cache only immutable, provenance-keyed baselines. Never share a baseline across vintages or calibration profiles.

Verification and acceptance gates

Fast contract tests
  • Mocked baseline/reform calls verify routing, caching, schema, units and provenance.
  • Tests reject unsupported reforms, wrong geography, missing data, failed convergence and mismatched units.
  • Capability registry, CLI, MCP and website claims are generated from or tested against the same metadata.
  • og-uk behavior remains unchanged.
Real public-data benchmark
  • In a clean Python 3.12 environment, install the documented dependencies and run one CPS-profile baseline plus one small reviewed reform.
  • Reproduce a frozen upstream OG-USA example or published fixture at declared tolerances.
  • Store immutable expected outputs, upstream commit/package versions, data manifests, runtime and solver residuals.
  • Run this benchmark on a scheduled/manual workflow where failure fails rather than skips.
Economic validation
  • Publish achieved-versus-target calibration moments.
  • Label matched targets as calibration by construction, not outcome validation.
  • Add at least one independent published US reform benchmark before promoting beyond experimental.
  • Report sensitivity to closure rule, Frisch elasticity, discount factors, tax-function profile and foreign-capital assumptions.
  • Do not claim forecasting validity: OG-USA is a structural fiscal counterfactual model.

Product and documentation

  • Add OG-USA to the capability registry with US geography, supported questions, unsupported uses, access, runtime, data vintage and validation status.
  • Present OG-UK and OG-USA as two country calibrations in the OLG family, not one cross-country model.
  • Add CLI examples for the public baseline, one reviewed PolicyEngine-US reform and one direct structural scenario.
  • Document private-data boundaries and reproducibility differences between public CPS and restricted PUF/TMD profiles.
  • Update model, comparison, validation and paper surfaces only after the corresponding executable capability exists.

Definition of done

  • A clean public-data installation executes an OG-USA baseline and one reviewed reform.
  • The output satisfies the common result/provenance schema with explicit USD units and steady-state horizon.
  • Unsupported PolicyEngine-US reforms are refused rather than guessed.
  • Solver convergence, calibration targets, source versions and runtime are visible.
  • A frozen upstream replication and an independent US benchmark are published.
  • OG-UK remains intact and country routing is unambiguous.
  • Access is labelled local/experimental unless hosted feasibility is demonstrated.

Related: #69, #71. This implements the OG-USA direction originally suggested during the PolicyEngine Macro architecture review.

主要语言
HTML
星标
3
派生
0
平均合并
22 小时 53 分钟
30 天内合并 PR
1

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

PolicyEngine/macro 的其他 Issue

查看 PolicyEngine/macro 的全部 Issue

相似的 Issue

更多 Backend & API Design Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。