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 Financial Crime Investigation Workload Prioritization Dispatcher

Format
Code-aware
Lines
133
Sections
11
Linked challenge
Build a Financial Crime Investigation Workload Prioritization Dispatcher

Prompt source

Original prompt text with formatting preserved for inspection.

133 lines
11 sections
No variables
1 code block
## Build
Score and prioritize financial crime investigative queues using configurable fictional business rules. Map case attributes to investigator specialization and capacity to produce transparent operational rosters.

## User
AML Investigation Team Lead

## Workflow
1. Ingest batches of pending fictional financial crime case files containing entity risk, value, and alert types.
2. Calculate deterministic priority scores using weighted factors for corporate exposure, cross-border tags, and statutory SLA limits.
3. Evaluate investigator roster metrics including active load, jurisdiction certifications, and current backlog.
4. Generate a balanced investigation dispatch roster with explicit routing rationales and escalation markers.

## Interface
Investigative operations dispatch console showing backlog queues, investigator capacity gauges, and assignment logs.

## Data
Construct a synthetic JSON fixture of fictional alert records and investigator profiles.
Starter examples below are synthetic. They are not downloaded records.

## Source
[OpenSanctions data toolkit](https://raw.githubusercontent.com/opensanctions/yente/main/README.md)
Employ FollowTheMoney entity property types (jurisdiction, amount, currency, entity schema) for uniform alert attributes.

## Tools
langgraph, pydantic, fastapi.
LangGraph manages stateful queue routing loops and conditional dispatcher nodes efficiently.
Local or hosted LLM with tool-calling capabilities for routing decisions.

## 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
- Calculates deterministic priority rank adhering to SLA deadline and multi-factor risk weighting.
- Respects investigator caseload caps during automated assignment passes.
- Provides clear reason codes explaining why a case was routed to a specific analyst.
- Returns full priority queue JSON payload with valid ISO timestamps and routing keys.

## Starter Examples
```json
[
  {
    "input": {
      "cases": [
        {
          "case_id": "CASE-901",
          "entity_type": "Company",
          "jurisdiction": "ky",
          "aggregate_amount": 750000,
          "days_to_sla": 2
        },
        {
          "case_id": "CASE-902",
          "entity_type": "Person",
          "jurisdiction": "us",
          "aggregate_amount": 12000,
          "days_to_sla": 14
        }
      ],
      "investigators": [
        {
          "id": "inv_1",
          "name": "Elena Vance",
          "active_cases": 2,
          "max_capacity": 5,
          "specialties": [
            "offshore",
            "corporate"
          ]
        },
        {
          "id": "inv_2",
          "name": "Marcus Reid",
          "active_cases": 4,
          "max_capacity": 5,
          "specialties": [
            "retail",
            "structuring"
          ]
        }
      ]
    },
    "expected_output": {
      "dispatches": [
        {
          "case_id": "CASE-901",
          "assigned_to": "inv_1",
          "priority_tier": "critical",
          "score": 95,
          "routing_reason": "SLA expiring in 2 days and offshore corporate jurisdiction match."
        },
        {
          "case_id": "CASE-902",
          "assigned_to": "inv_2",
          "priority_tier": "low",
          "score": 30,
          "routing_reason": "Low value domestic person alert within safe SLA threshold."
        }
      ],
      "unassigned_cases": []
    }
  },
  {
    "input": {
      "cases": [
        {
          "case_id": "CASE-903",
          "entity_type": "Company",
          "jurisdiction": "pa",
          "aggregate_amount": 1500000,
          "days_to_sla": 1
        }
      ],
      "investigators": [
        {
          "id": "inv_3",
          "name": "Sarah Chen",
          "active_cases": 5,
          "max_capacity": 5,
          "specialties": [
            "offshore"
          ]
        }
      ]
    },
    "expected_output": {
      "dispatches": [],
      "unassigned_cases": [
        {
          "case_id": "CASE-903",
          "priority_tier": "critical",
          "score": 98,
          "status": "queued_capacity_exceeded",
          "routing_reason": "Investigator capacity full; requires supervisor rebalancing."
        }
      ]
    }
  }
]
```

## Safety
Utilizes purely synthetic scenarios with no real names, simulated routing only, and no automated regulatory reporting.
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.