Build a Supplier Payment-Change Verification Workspace — Implementation planning and evidence-linked development

## User
An accounts payable fraud analyst.

## Build
Review fictional supplier bank-detail changes using trusted verification records and document history. Keep convincing email text separate from independently authenticated payment instructions.

## Input Contract
- Key: change_request_id + evidence_id.
- Fields: requested_payee_reference, trusted_supplier_reference, independent_confirmation, source_channel, approval_state.
- A contact number supplied in the change request is not an independent trusted contact.

## Workflow
1. Compare requested changes with the approved supplier record.
2. Separate requester-supplied content from trusted verification evidence.
3. Apply a fictional verification workflow with explicit unresolved states.
4. Export a reviewer packet without changing payment instructions.

## Interface
A supplier-change diff with trusted-source labels, verification evidence, and a reviewer checklist.

## Deliverables
- A payment-change evidence reconciliation module.
- A mock approval workflow with an immutable decision record.
- 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
- Email urgency cannot override missing independent verification.
- A reply to the same compromised channel is not independent confirmation.
- Unresolved requests never update a supplier master record.
- The interface states that review readiness is not payment authorization.

## Contrast Case
Keep every email and invoice field identical. Change only independently recorded confirmation to test whether evidence changes the route.

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

Full target: Author synthetic invoices, supplier master records, email messages, and verification logs. Do not include real bank details or send verification messages.

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
No payments, supplier-master writes, impersonation, or external contact.

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