Build the complete application

## User
A bank fraud investigator reviewing account-access alerts.

## Build
Combine synthetic authentication, device, session, and transaction evidence into a reviewable case timeline. Distinguish verified customer activity from unresolved account takeover indicators.

## Input Contract
- Key: case_id + event_id.
- Fields: event_time, observed_at, device_reference, verification_state, transaction_reference, evidence_source.
- Risk routing and confirmed fraud are separate fields. Unknown evidence is not a negative finding.

## Workflow
1. Assemble evidence in event and observation order.
2. Identify conflicts between account activity and verification records.
3. Apply a transparent fictional review-routing policy.
4. Export an investigator packet with uncertainty and missing evidence.

## Interface
A case timeline with evidence provenance, conflicting-verification alerts, and analyst review actions.

## Deliverables
- A case assembly service with reproducible decision snapshots.
- A review interface that distinguishes facts, hypotheses, and unresolved evidence.
- Runnable local application, setup commands, and a dependency lockfile.
- Versioned input data, data dictionary, acquisition instructions, and rights notes.
- Calculation traces, source references, assumption records, and exported review artifacts.
- A deterministic baseline and tests for normal, incomplete, contradictory, and failure-recovery cases.
- A recorded complete workflow with a reproducible manifest and explicit limitations.

## Acceptance Criteria
- A verified challenge result and an unverified note are not equivalent evidence.
- Later evidence cannot alter the original decision snapshot.
- A new device or location alone cannot establish fraud.
- All recommendations remain review proposals without account actions.

## Contrast Case
Two identical sessions differ only in independently verified customer confirmation. The fictional review route changes, not a criminal label.

## Dataset Scope
The attached starter files are prototype inputs. Expected starter answers are visible. They are not independent holdouts.

Full target: Author synthetic session and verification events because BAF does not supply the required complete account-takeover timeline. Keep identity, device, and transaction evidence provenance separate.

Complete target contracts and expert review remain pending. Public observations are not historical release vintages.

## Tools
DuckDB, Pydantic, Streamlit

Use an available model appropriate to the task. Record provider, model identifier, version or retrieval date, settings, cost, and latency. Use deterministic code for calculations. Models may extract, retrieve, or explain evidence. They must not invent missing records, override approval rules, or claim professional authority.

## Constraints
No account freezing, customer contact, or fraud accusation. These fixtures are not practitioner-adjudicated bank cases.

- No fabricated records, source citations, professional endorsements, or expert-adjudication claims.
- No future-data leakage into dated decisions, model fitting, or historical valuation inputs.
- No unauthorized payments, account restrictions, regulatory filings, or production changes.
- No automated appraisal certification, tax-compliance determination, or unsupported fraud accusation.
- No concealed uncertainty or silently invented inputs required for a numerical conclusion.

## Scoring
- Correct domain calculations and justified methods with documented assumptions. Weight: 30.
- Source lineage, temporal integrity, rights checks, and explicit synthetic-data labels. Weight: 25.
- A working application with review, export, error handling, and reproducible state. Weight: 20.
- Adversarial cases, uncertainty, missing-data behavior, and sensitivity analysis. Weight: 15.
- Evidence-linked conclusions that distinguish facts, assumptions, and unresolved judgments. Weight: 10.
Score each dimension from zero to two. Weighted score = sum(weight * score / 2). A failed safety gate blocks acceptance.