Build a Delayed Fraud Outcome and Label-Maturity Ledger — Implementation planning and evidence-linked development

## User
A fraud analytics team preparing training and monitoring data.

## Build
Track when fraud outcomes become known and when they are sufficiently mature for analysis. Prevent recent unresolved transactions from being mislabeled as legitimate activity.

## Input Contract
- Key: transaction_id + label_version.
- Fields: transaction_at, outcome_known_at, outcome, review_state, observation_cutoff, censoring_reason.
- Label unknown, legitimate, and confirmed-synthetic-fraud separately. Preserve superseded labels.

## Workflow
1. Build a versioned outcome event ledger.
2. Apply an explicit fictional observation-window policy.
3. Produce as-of training snapshots and mature monitoring cohorts.
4. Export censoring summaries and label-revision histories.

## Interface
An outcome timeline with maturity cohorts, unresolved records, and training-snapshot controls.

## Deliverables
- A point-in-time label store.
- A data-quality report quantifying unknown and revised outcomes.
- 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
- Unknown outcomes never become negative labels by default.
- A label arriving after the training cutoff is excluded.
- A maturity rule alone does not establish that all fraud was observed.
- Report monitoring results separately for mature and unresolved cohorts.

## Contrast Case
A known outcome and an unknown outcome with the same elapsed age have different training eligibility.

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

Full target: Use synthetic transaction, dispute, adjudication, and observation-window events. Public fraud datasets do not automatically supply real dispute timing or maturity guarantees.

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

## Tools
DuckDB, PyArrow, pandas

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 maturity period is a fictional fixture policy, not a universal chargeback deadline.

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