Skip to main content
Back to Prompt Library
implementation

Build the application

Inspect the original prompt language first, then copy or adapt it once you know how it fits your workflow.

Linked challenge: Build a Disaster Declaration Administrative Frequency Auditor

Format
Code-aware
Lines
76
Sections
11
Linked challenge
Build a Disaster Declaration Administrative Frequency Auditor

Prompt source

Original prompt text with formatting preserved for inspection.

76 lines
11 sections
No variables
1 code block
## Build
Correlate municipal asset portfolios against OpenFEMA disaster declarations to measure regional declaration frequency. Quantify historical administrative disaster frequencies to guide municipal infrastructure adaptation grant planning and funding applications.

## User
Municipal Adaptation Planner

## Workflow
1. Filter OpenFEMA DisasterDeclarationsSummaries by state, county, and incidentType 'Flood'.
2. Ingest municipal facility locations and match to county FIPS codes.
3. Calculate historical administrative declaration frequencies and mean intervals between declarations.
4. Produce a capital improvement grant prioritization list based on administrative declaration frequency.

## Interface
Streamlit application displaying county administrative disaster timelines, declaration metrics, and facility grant priority tables.

## Data
Query OpenFEMA API endpoint /v2/DisasterDeclarationsSummaries with $filter or download historical CSV extract using $allrecords=true.
Starter examples below are synthetic. They are not downloaded records.

## Source
[FEMA OpenFEMA](https://www.fema.gov/about/openfema/api)
Queries OpenFEMA DisasterDeclarationsSummaries using $filter parameters state, incidentType, and declarationDate specified in OpenFEMA docs.

## Tools
mastra-ai, requests, pandas.
Mastra AI provides deterministic workflow orchestration and schema validation for API aggregation pipelines.
Local or hosted LLM to generate narrative adaptation grant summaries based on historical administrative declaration counts.

## Deliverables
Submit runnable source, pinned dependencies, setup commands, a working interface, example outputs, and a recorded end-to-end demo. Include tests and an action log.

## Acceptance
- Correctly formats OData query parameters including ISO-8601 timestamps.
- Aggregates flood declarations per county over specified multi-decade windows.
- Ranks public assets by county administrative disaster declaration counts for grant planning.

## Starter Examples
```json
[
  {
    "input": {
      "_record_type": "simplified synthetic app record",
      "county_fips": "12086",
      "state": "FL",
      "declarations": [
        {
          "disasterNumber": 4001,
          "incidentType": "Flood",
          "declarationDate": "2015-01-01T00:00:00.000Z"
        },
        {
          "disasterNumber": 4200,
          "incidentType": "Flood",
          "declarationDate": "2020-01-01T00:00:00.000Z"
        }
      ],
      "asset_count": 12
    },
    "expected_output": {
      "county_fips": "12086",
      "flood_declaration_count": 2,
      "mean_declaration_interval_years": 5,
      "grant_priority_level": "MODERATE_FREQUENCY"
    }
  },
  {
    "input": {
      "_record_type": "simplified synthetic app record",
      "county_fips": "12001",
      "state": "FL",
      "declarations": [],
      "asset_count": 3
    },
    "expected_output": {
      "county_fips": "12001",
      "flood_declaration_count": 0,
      "mean_declaration_interval_years": null,
      "grant_priority_level": "LOW_FREQUENCY"
    }
  }
]
```

## Safety
Does not calculate physical flood risk or provide engineering guarantees; outputs strictly reflect administrative grant declaration history for funding evaluation.
Use mock external writes. Require human review before any real deployment.

Adaptation plan

Keep the source stable, then change the prompt in a predictable order so the next run is easier to evaluate.

Keep stable

Hold the task contract and output shape stable so generated implementations remain comparable.

Tune next

Update libraries, interfaces, and environment assumptions to match the stack you actually run.

Verify after

Test failure handling, edge cases, and any code paths that depend on hidden context or secrets.