Build a Supplier Payment-Change Verification Workspace

An accounts payable fraud analyst.

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

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.

Compare requested changes with the approved supplier record.

Separate requester-supplied content from trusted verification evidence.

Apply a fictional verification workflow with explicit unresolved states.

Export a reviewer packet without changing payment instructions.

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

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.

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.

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

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.

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.

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.

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.