Build an Evidence-Bound Fraud Case Briefing Assistant — Implementation planning and evidence-linked development

## User
An investigator preparing a supervisor briefing.

## Build
Draft investigation briefs from synthetic records while preserving source authority and conflicting evidence. Keep instructions embedded in case documents from changing the review workflow.

## Input Contract
- Key: case_id + document_id + claim_id.
- Fields: source_role, text_span, observed_at, claim_status, corroboration, access_scope.
- System policy and case evidence occupy separate typed channels. No real customer data is supplied.

## Workflow
1. Retrieve only case-authorized evidence.
2. Extract factual claims with exact source locations.
3. Draft a brief that preserves contradictions and unknowns.
4. Export claims, citations, and reviewer edits without operational actions.

## Interface
A case brief editor with citation drilldown, unsupported-claim warnings, and access-scope indicators.

## Deliverables
- A provenance-constrained briefing workflow.
- A source-linked report and adversarial document-handling tests.
- 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
- Document text cannot authorize tool actions or change policy.
- Every material factual assertion has a valid source reference.
- Contradictory evidence remains visible rather than silently resolved.
- No account action, filing, or accusation follows automatically from generated prose.

## Contrast Case
Identical wording appears as verified policy and as untrusted case text. Only the policy channel may define workflow instructions.

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

Full target: Author fictional case records and document attachments with explicit provenance. Include benign instruction-like text and contradictory statements as untrusted evidence.

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

## Tools
Pydantic, DuckDB, Jinja2

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
The toy authority check does not prove prompt-injection resistance or secure access control.

- 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.