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 Desalination Intake Sampling and Lab Follow-Up Workspace

Format
Code-aware
Lines
77
Sections
11
Linked challenge
Build a Desalination Intake Sampling and Lab Follow-Up Workspace

Prompt source

Original prompt text with formatting preserved for inspection.

77 lines
11 sections
No variables
1 code block
## Build
Turn unusual intake readings into proposed sampling visits and laboratory evidence requests. Track unresolved samples and prepare review packets without diagnosing algal blooms or recommending chemical doses.

## User
Desalination Environmental Compliance Engineer

## Workflow
1. Import synthetic intake readings and fictional sampling thresholds.
2. Identify exceedances and prepare sampling requests with cited readings.
3. Track sample collection, laboratory evidence, and unresolved follow-up tasks.
4. Export an intake review packet without operational commands.

## Interface
Reading timeline, sample request queue, laboratory attachment panel, and engineer review export.

## Data
Create normalized synthetic readings, fictional sampling thresholds, sample identifiers, and laboratory records. These are not measured GCC data.
Starter examples below are synthetic. They are not downloaded records.

## Source
[WaterTAP treatment modeling](https://raw.githubusercontent.com/watertap-org/watertap/main/README.md)
WaterTAP documents treatment modeling. This application prepares evidence for later modeling, without deriving organic loads or chemical doses.

## Tools
haystack, pydantic, fastapi.
Haystack retrieves linked sample evidence. Deterministic rules create requests from supplied thresholds.
Use a currently available model for evidence-linked summaries, not water-quality diagnosis.

## 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
- Uses thresholds supplied with each fixture.
- Creates a request when either supplied threshold is exceeded.
- Shows missing laboratory evidence instead of diagnosing blooms.
- Exports evidence packets and pending tasks.

## Starter Examples
```json
[
  {
    "input": {
      "intake_id": "A",
      "chlorophyll_ug_l": 15.5,
      "turbidity_ntu": 8,
      "fictional_thresholds": {
        "chlorophyll_ug_l": 10,
        "turbidity_ntu": 5
      },
      "lab_evidence": []
    },
    "expected_output": {
      "sampling_request_proposed": true,
      "exceeded_fields": [
        "chlorophyll_ug_l",
        "turbidity_ntu"
      ],
      "bloom_status": "unverified",
      "chemical_dose_recommendation": null,
      "approval_required": true
    }
  },
  {
    "input": {
      "intake_id": "B",
      "chlorophyll_ug_l": 1.2,
      "turbidity_ntu": 1.5,
      "fictional_thresholds": {
        "chlorophyll_ug_l": 10,
        "turbidity_ntu": 5
      },
      "lab_evidence": []
    },
    "expected_output": {
      "sampling_request_proposed": false,
      "exceeded_fields": [],
      "bloom_status": "unverified",
      "chemical_dose_recommendation": null,
      "approval_required": true
    }
  }
]
```

## Safety
Use synthetic records. Do not diagnose water safety, recommend chemical doses, or operate equipment.
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.