/build-fpas — Build FPAS

Category: Build · Primary agent: fpas-modeler

Designs and builds a forecasting and policy analysis system: core model, nowcasts, judgment layer, forecast process.

Arguments: $ARGUMENTS

Purpose

Design and build a forecasting and policy analysis system: not only a core model but the process around it, including nowcasting tools for the near term, a judgment layer with an overlay log, forecast-story templates, a calendar with roles and sign-offs, and the training that lets a counterpart team run it. The output is a system that completes a full forecast round from a frozen data vintage.

Use it when an institution needs a regular, documented forecast process tied to policy decisions, or an existing process needs a model core, a judgment layer or better documentation.

Do not use it when only a model is needed (/build-semi-structural, /build-dsge) or a single forecast is needed (/forecast-round).

Before you start

1. Check required inputs. For each input below record FOUND or ABSENT (never 'assumed'):
   • Core model or approved model-spec
   • Data pipeline If a required input is ABSENT, that part is NOT ASSESSED — NO DATA: do not estimate or invent it; name what is missing and which skill produces it. If all required inputs are absent, stop and say so.
2. Check confidentiality. Identify the data classification level of the inputs (.claude/docs/confidentiality-and-ai-use.md). Do not proceed with restricted or confidential data in a way the policy does not allow.
3. Collaboration. Follow .claude/docs/collaboration-protocol.md: ask questions first, present options, get approval before writing files, and update production/session-state/active.md after each approved section.

Agents

• fpas-modeler — primary agent; coordinates the work and integrates results
• dfm-nowcasting-specialist — Builds dynamic factor models and nowcasts
• stakeholder-liaison-specialist — Interfaces with stakeholders and counterparts
• visualization-dashboard-specialist — Designs charts and dashboards

Run these agents as subagents (the Task tool), in parallel where the steps are independent. Subagents only write to the paths named in your instructions.

Key design decisions (present options, let the user choose)

Decision	Typical options	What it changes
Core model	semi-structural gap model, small DSGE, suite	Transparency versus structure
Near-term tools	bridge equations, DFM nowcasts, expert judgment	Accuracy of initial conditions
Judgment layer	add-factors, tuned shocks, conditioning on paths	Traceability of overlays
Cycle	monthly, quarterly; number of meetings per round	Workload and timeliness
Outputs	forecast report, risk scenarios, fan charts, policy rate path	Communication

Workflow

1. Define the forecast process calendar, roles and sign-offs
   • Data cut-off, nowcast, model runs, judgment meetings, sign-off, publication
2. Integrate core model, near-term nowcast tools and judgment-overlay log
   • Overlays recorded with reason, evidence and owner
3. Build the shock-decomposition and forecast-story templates
   • Templates link every story element to a decomposition or overlay
4. Run a mock forecast round on historical data and review lessons
   • Use a frozen vintage; evaluate the mock forecast against outturns
5. Prepare training material for the counterpart team
   • Hands-on exercises on the core model and the process (/design-training)
6. Register the model as a lego set (/lego-map): a baseplate plus bricks with declared studs (variables, units, timing) and stubs, so components can later be attached, detached or swapped

Checkpoints with the user

• After the process design: confirm calendar and roles with the institution
• After integration: confirm the overlay rules
• After the mock round: agree changes before handover

Common pitfalls

• A model without a process, or a process without documentation
• Overlays that are not recorded
• Near-term tools inconsistent with the core model's initial conditions
• Training that ends at the workshop with no follow-up

Output

models/fpas/<name>/ and docs/models/<name>/fpas-design.md (+ model.lego.json)

The model folder holds the core model, nowcast tools, templates and run scripts; the design document covers the calendar, roles, overlay rules and the mock-round review; the lego manifest registers the model and its satellites. Every run saves its results to output/<run-id>/ in the model folder, with a run log (.claude/rules/model-code.md).

Gate / verdict

• A full mock round runs end-to-end from a frozen data vintage
• Lego manifest passes python tools/lego.py check
• The overlay log is in place and used in the mock round
• Training material exists for the counterpart team

Suggested next steps

• /forecast-round
• /design-training
• /lego-map