@1aboveio/skills 1.0.10 → 1.0.11

package/skills/risk-compliance/{fraud-analysis → fraud-detection}/references/feature-engineering.md

@@ -1,18 +1,19 @@
 # Shared feature engineering
 
-Read this in Step 4 after pre-flight passes, the analysis profile is selected,
-and its packs are loaded.
-This file defines invariants. Archetype, mechanism, and context packs supply the
-actual feature families and operational constraints.
-
-The goal is a small set of interpretable, decision-time-valid inputs that can
-become rules. Build thresholds, lists, rates, and graph artifacts on train only.
+Read this after pre-flight and selection of the analysis profile and packs.
+Choose interpretable features supported by the data and decision workflow; the
+catalogs are candidates, not a required feature grid. Rapid rule discovery on
+recent data is acceptable without a mandatory split. Label same-sample selection
+and evaluation as exploratory, not independent performance.
 
 ## 1. Declare grain and decision point
 
-Name what one scored row represents and when the rule fires. Examples include a
-login, card authorization, collection receipt, beneficiary creation, transfer
-instruction, payout request, or investigation case.
+Real-time scoring evaluates one transaction at its decision point. Current
+transaction attributes and transaction-triggered velocity include that transaction.
+History contains only records available at that decision. Other journey events
+supply prior context, not alternative real-time scoring units. A post-transaction entity or period
+review is separate; completed-period aggregates are not available at an earlier
+decision.
 
 A feature is usable only if its value existed at that decision point in the live
 workflow. Correlation with the eventual label is insufficient.
@@ -54,28 +55,57 @@ Use only families supported by the selected packs and source data:
 - Current-event attributes: amount, currency, channel, product, state available
   at decision time
 - Entity history: customer, account, instrument, beneficiary, device, session,
-  IP, email, phone, merchant, or counterparty
-- Velocity: prior counts, amounts, distinct entities, and elapsed time over
-  operational windows
+  IP, email, phone, company, person, bank account, address, merchant, or counterparty
+- Velocity: counts, amounts, distinct entities, and elapsed time over
+  operational windows, including the current transaction. For counterparty
+  velocity, declare direction, entity type, and pair versus entity grouping;
+  never mix company counts with bank-account counts.
 - Novelty and deviation: new entity, behavior unlike the entity's prior history,
   amount relative to prior behavior
 - Sequences: explicit prior-event patterns across the money or access journey
+- Fund lots: stateful allocation of available incoming funds to the current
+  outgoing transaction; FIFO is the default for collection/payout analysis.
+  Preview the current debit against pre-debit state, not a completed payout
+  outcome. Domain rules and conservation checks are in
+  [collection/payout features](collection-payout-features.md).
 - Networks: fan-in, fan-out, shared identifiers, clusters, and risky-neighbor
   evidence from a point-in-time graph
-- Train-fit lists: entities or segments with minimum support and elevated rate
+- Lists: entities or segments with sufficient support and elevated rate, using
+  only outcomes available at the decision when deployed
 
 ## 4. Point-in-time history
 
-- Sort events deterministically by time within each identity key.
-- Use timestamps strictly before the current event. Define tie behavior.
-- Holdout rows may use train-era history that predates the row.
+- Use event times in (t − window, t], including the current transaction, and
+  only records available at decision time. Equal timestamps need a deterministic
+  known arrival order. A later arrival is not history even if its event time is earlier.
+- Holdout rows, if used, may use history available at their decision.
 - Never use the current row's outcome in its own features.
 - Graph nodes, edges, labels, and aggregates must be snapshots as of the event.
 - Outcome labels become historical evidence only after they would have been known
   operationally, not merely after the underlying transaction occurred.
 
-Use windows operations can implement, such as 10m, 1h, 24h, or 7d. Avoid exact
-sequences and fine windows selected only because they maximize train fit.
+Standard elapsed windows are 1m, 5m, 15m, 30m, 1h, 2h, 6h, 24h, 2d,
+7d, 14d, 21d and 30d; a day is 86,400 seconds, not a calendar day.
+Standard names are `<entity>_txn_count_<window>`,
+`<entity>_amount_sum_<window>`, and `<entity>_<other_entity>_distinct_count_<window>`.
+For example: `email_txn_count_5m`, `pan_amount_sum_24h`, and
+`email_pan_distinct_count_7d`. Keep `24h` canonical, not `1d`. A nonstandard
+window needs an explicit operational reason; do not generate all combinations.
+
+For mismatch, compare normalized like-for-like attributes; missing inputs return
+unknown. For frequency encoding, define the reference population, count versus
+share, reference period/version, null/unseen behavior, and availability. A frozen
+historical frequency encoding differs from a rolling count. Neither may use
+future observations. See [feature SQL](feature-sql.md) for both patterns.
+
+For every shortlisted feature record its formula, inputs, entity key, window,
+null behavior, currency, source/version, and update semantics. Replay cold starts,
+limited lookback, late arrivals, duplicate delivery, and timestamp ties. Missing
+history is not proof of zero prior activity.
+
+See [feature SQL](feature-sql.md), [entities](entities.md), and
+[enrichment](enrichment.md). Avoid sequences and fine windows selected only
+because they maximize sample fit.
 
 ## 5. Identity-link quality
 
@@ -103,21 +133,26 @@ account restrictions often mature after the event.
   value exists. State this assumption and preserve those explicit states as
   unlabeled.
 - For a user-defined positive condition, require a separate user-defined
-  negative condition. Rows outside the positive condition are not automatically
-  negative.
+  negative condition before computing metrics that need negatives. Discovery
+  continues with remaining rows unlabeled. Rows outside the positive condition
+  are not automatically negative.
 - Verify positive and negative conditions are disjoint. Exclude rows matching
   neither or both from supervised metrics and report their count.
-- Fit label-rate lists on mature train outcomes only.
+- Use only outcomes mature and available before each decision in deployed
+  label-rate lists or encodings; never use current or future outcomes.
 - Do not use an operational action as both label and feature.
 - Do not blend separate archetypes into a single positive label.
 
-## 7. Train-fit thresholds and lists
+## 7. Discovery and optional validation
 
-- Propose thresholds from business meaning or train distributions.
-- Require minimum support for entity, graph, or segment lists.
-- Freeze conditions and memberships before holdout scoring.
-- Apply frozen artifacts to holdout without reranking on holdout outcomes.
-- Small-N spikes remain monitoring candidates.
+- Propose thresholds from business meaning or observed distributions.
+- Require appropriate support for entity, graph, or segment lists.
+- If using a holdout, freeze conditions and memberships before holdout scoring;
+  apply them without reranking on holdout outcomes.
+- If the same sample selects and evaluates rules, label results same-sample and
+  exploratory. Optional temporal or other validation can measure generalization.
+- Small-N spikes remain monitoring candidates. Discovery choices never relax
+  decision-time availability of encoding sources.
 
 ## 8. Rule-ready conditions
 
@@ -130,9 +165,9 @@ event grain + decision point + fields + operator + threshold/list + units + wind
 Prefer:
 
 - `amount >= <currency threshold>` over “high amount”
-- `prior_attempts_1h >= 3` over “high velocity”
+- `attempts_including_current_1h >= 3` over “high velocity”
 - `beneficiary_age_minutes <= 30` over “new beneficiary”
-- `entity in train_fit_watchlist_v1` over a holdout-ranked list
+- `entity in decision_time_watchlist_v1` with its availability documented
 
 ## 9. Universal do-not list
 
@@ -140,7 +175,7 @@ Prefer:
 - Do not use future events, current outcomes, or investigation results.
 - Do not treat technical authentication as proof of customer consent.
 - Do not infer victim, perpetrator, mule, or facilitator role from behavior alone.
-- Do not fit thresholds, rates, graph lists, or watchlists on holdout.
+- Do not rerank on holdout outcomes when reporting holdout performance.
 - Do not present proxy labels as confirmed fraud or loss avoided.
 - Do not invent missing fields, identity links, currencies, or event semantics.
 
@@ -149,10 +184,11 @@ Prefer:
 - [ ] Analysis profile loaded
 - [ ] Event grain and decision point stated
 - [ ] Outcome maturity defined
-- [ ] Label provenance and positive/negative/unlabeled definitions recorded
+- [ ] Label provenance and known positive/negative/unlabeled definitions recorded;
+  unavailable classes limit metrics, not discovery
 - [ ] Positive and negative conditions are disjoint
 - [ ] Fields classified into allowed/excluded/context-only lists
 - [ ] History and graph features are point-in-time
 - [ ] Identity-link strength documented
-- [ ] Thresholds and lists fit on train only
+- [ ] Same-sample results labeled; any holdout artifacts frozen before evaluation
 - [ ] Candidates expressed as operable conditions

package/skills/risk-compliance/fraud-detection/references/feature-sql.md

@@ -0,0 +1,150 @@
+# Decision-time feature SQL
+
+This PostgreSQL reference demonstrates semantics, not a production implementation
+or performance recommendation. It scores each transaction independently. Assume
+`transactions` has one immutable decision-time snapshot per transaction with:
+
+```text
+id bigint primary key, event_time timestamptz not null,
+arrival_seq bigint unique not null, email text, pan text,
+amount numeric, currency text, bin_country text, ip_country text
+```
+
+The sequence is a globally unique, monotonically assigned decision-availability
+order; a row and its attributes are available by its own sequence. It must reflect
+what the scorer actually knew, not a sequence assigned retrospectively in event
+time. Corrections, late enrichments and delayed outcomes need separate versioned
+availability data; this snapshot alone cannot reconstruct them. Keys and country
+codes are already normalized, with empty/invalid values converted to null. The
+query uses a 1-hour elapsed window; substitute any standard window in
+[feature engineering](feature-engineering.md), with days as 86,400 seconds.
+
+The lateral query is authoritative for eligibility: event time is strictly above
+the lower bound and at or below current event time, and availability sequence is
+at or below the current sequence. Thus the current row is included, equal-time
+later arrivals are excluded, and an earlier event arriving later is excluded.
+Email transaction count includes current; distinct PAN excludes null.
+The PAN amount sum uses the current currency only, but is unknown if the current
+currency is unknown or any eligible PAN event has unknown currency or an unknown
+amount in that currency. Known other currencies are not added. This conservative
+rule avoids treating missing amounts or currencies as zero. Null entity keys return
+null features rather than pooling unrelated records. Country mismatch is null when
+either country is unknown. These features use no outcome labels.
+
+```sql
+SELECT c.id,
+       CASE WHEN c.email IS NULL THEN NULL ELSE e.email_txn_count_1h END AS email_txn_count_1h,
+       CASE WHEN c.email IS NULL THEN NULL ELSE e.email_pan_distinct_count_1h END AS email_pan_distinct_count_1h,
+       CASE WHEN c.pan IS NULL THEN NULL ELSE p.pan_txn_count_1h END AS pan_txn_count_1h,
+       CASE WHEN c.pan IS NULL OR c.currency IS NULL
+                  OR p.unknown_currency_count > 0 OR p.missing_amount_count > 0
+            THEN NULL ELSE p.same_currency_sum END AS pan_amount_sum_1h,
+       CASE WHEN c.bin_country IS NULL OR c.ip_country IS NULL THEN NULL
+            ELSE c.bin_country <> c.ip_country END AS bin_ip_country_mismatch
+FROM transactions AS c
+LEFT JOIN LATERAL (
+    SELECT count(*) AS email_txn_count_1h,
+           count(DISTINCT h.pan) AS email_pan_distinct_count_1h
+    FROM transactions AS h
+    WHERE c.email IS NOT NULL AND h.email = c.email
+      AND h.event_time > c.event_time - interval '3600 seconds'
+      AND h.event_time <= c.event_time
+      AND h.arrival_seq <= c.arrival_seq
+) AS e ON true
+LEFT JOIN LATERAL (
+    SELECT count(*) AS pan_txn_count_1h,
+           count(*) FILTER (WHERE h.currency IS NULL) AS unknown_currency_count,
+           count(*) FILTER (WHERE h.currency = c.currency AND h.amount IS NULL) AS missing_amount_count,
+           sum(h.amount) FILTER (WHERE h.currency = c.currency) AS same_currency_sum
+    FROM transactions AS h
+    WHERE c.pan IS NOT NULL AND h.pan = c.pan
+      AND h.event_time > c.event_time - interval '3600 seconds'
+      AND h.event_time <= c.event_time
+      AND h.arrival_seq <= c.arrival_seq
+) AS p ON true
+ORDER BY c.id;
+```
+
+For a same-PAN, amount and currency retry count, require all three current values
+to be non-null and add equality predicates on all three to the same lateral
+eligibility conditions. A missing value yields unknown, not a match. For historical
+label-rate encodings, the outcome itself needs an availability sequence no later
+than the current decision and must be mature; exclude the current outcome. Do not
+use today's known fraud list as though it existed at earlier decisions.
+
+## Frequency encoding
+
+This PostgreSQL example assumes `reference_transactions(mcc, address_key)` is an
+explicitly chosen historical population available before scoring begins. Build
+and version the reference once; do not refit it on later scoring transactions.
+Use a separate earlier population for discovery rows if replaying their features.
+The denominator includes non-null values only, separately for each attribute.
+
+```sql
+CREATE TEMP TABLE attribute_frequency_reference AS
+WITH attribute_values AS (
+    SELECT 'mcc' AS attribute, mcc AS value
+    FROM reference_transactions
+    UNION ALL
+    SELECT 'address', address_key
+    FROM reference_transactions
+), frequencies AS (
+    SELECT attribute, value, count(*) AS txn_count
+    FROM attribute_values
+    WHERE value IS NOT NULL
+    GROUP BY attribute, value
+)
+SELECT attribute, value, txn_count,
+       txn_count::double precision
+           / sum(txn_count) OVER (PARTITION BY attribute) AS txn_share
+FROM frequencies;
+
+SELECT t.id,
+       coalesce(m.txn_share, 0.0) AS mcc_frequency,
+       t.mcc IS NULL AS mcc_missing,
+       t.mcc IS NOT NULL AND m.value IS NULL AS mcc_unseen,
+       coalesce(a.txn_share, 0.0) AS address_frequency,
+       t.address_key IS NULL AS address_missing,
+       t.address_key IS NOT NULL AND a.value IS NULL AS address_unseen
+FROM scoring_transactions AS t
+LEFT JOIN attribute_frequency_reference AS m
+    ON m.attribute = 'mcc' AND m.value = t.mcc
+LEFT JOIN attribute_frequency_reference AS a
+    ON a.attribute = 'address' AND a.value = t.address_key;
+```
+
+`scoring_transactions` adds `mcc text` and normalized `address_key text` to the
+snapshot schema above. Zero is the declared fallback for missing/unseen values;
+retain both flags rather than making the states indistinguishable. This frozen
+encoding is not transaction velocity; current inclusion applies to rolling
+features, not mutation of a frozen reference.
+
+## Standard intervals
+
+Use seconds to avoid timezone/DST-dependent calendar-day arithmetic.
+
+| Suffix | PostgreSQL interval |
+|---|---|
+| `1m` | `interval '60 seconds'` |
+| `5m` | `interval '300 seconds'` |
+| `15m` | `interval '900 seconds'` |
+| `30m` | `interval '1800 seconds'` |
+| `1h` | `interval '3600 seconds'` |
+| `2h` | `interval '7200 seconds'` |
+| `6h` | `interval '21600 seconds'` |
+| `24h` | `interval '86400 seconds'` |
+| `2d` | `interval '172800 seconds'` |
+| `7d` | `interval '604800 seconds'` |
+| `14d` | `interval '1209600 seconds'` |
+| `21d` | `interval '1814400 seconds'` |
+| `30d` | `interval '2592000 seconds'` |
+
+A simple `RANGE ... CURRENT ROW` frame is not equivalent: it can include all
+same-time peers and includes the lower boundary. PostgreSQL also does not support
+`COUNT(DISTINCT ...) OVER (...)`. Optimize for the target engine only after
+proving parity with the lateral eligibility definition.
+
+For cross-currency sums, first derive `amount_local` in a declared common currency
+using a decision-time FX rate, then apply the same window eligibility. Return
+unknown if any contributing amount lacks a valid conversion; never sum original
+amounts from different currencies or silently omit missing conversions.

package/skills/risk-compliance/{fraud-analysis → fraud-detection}/references/report-rationale.md

@@ -20,14 +20,16 @@ and collection controls.
 | Choice | Reason |
 |---|---|
 | Profile before label | The same status can represent different actors and outcomes across archetypes |
-| Explicit negative class | Precision, recall, and lift are undefined or misleading when “not positive” silently mixes genuine negatives with unknown outcomes |
+| Explicit negative class | Precision, false-positive rates, and lift need justified negatives; unknown outcomes are not negatives, but discovery can continue |
 | Consent separate from authentication | Compromised credentials can pass technical checks |
 | Reader order differs from workflow | Operators need decisions before methodology |
 | Standalone strategy impact | Portfolio friction and exposure determine whether rules should ship |
 | Count/rate and amount/share | Both operational volume and value matter |
 | Context-specific impact | Authorization, completion, delay, review, and exposure use different denominators |
 | Proxy and maturity disclosure | Delayed outcomes and operational actions are not confirmed fraud by default |
-| Point-in-time graphs | Future counterparties and investigations otherwise leak into earlier events |
+| Point-in-time features | Current inputs and known history permit real-time replay; future counterparties and investigations do not |
+| Optional validation | Recent catches can support rapid discovery without proving future performance |
+| Multiple rule hits | Package coverage is a transaction union, not a sum of overlapping rule counts |
 | No review process in report | Review metadata is not business content |
 
 ## Domain examples

package/skills/risk-compliance/{fraud-analysis → fraud-detection}/references/report-template.md

@@ -20,13 +20,14 @@ Do not title chapters as analysis steps. Keep review details out of the report.
 
 Use no more than five top-level findings:
 
-1. Analysis profile, sample span, and positive-label baseline
+1. Analysis profile, sample span, and positive-label baseline where available
 2. Adopted rule classes and domain-appropriate actions
 3. Adopted strategy package impact
 4. Material attribution or validation limitation, only when decision-critical
 
 For strategy impact, report triggered count/rate and amount/share, followed by
-precision and recall. Add the selected contexts' main customer, operations,
+precision and recall where supported. Mark unsupported metrics unavailable and
+state why. Add the selected contexts' main customer, operations,
 conversion, delay, exposure, or loss measure.
 
 Nested numbered lists use three-space indentation and `1.`, `2.`, `3.` markers.
@@ -36,7 +37,8 @@ Do not use Markdown bold markers in the report body.
 
 ### 2.1 样本范围
 
-Data source, event grains, time span, currencies, and portfolio constants.
+Data source, transaction scoring grain, supporting event grains, time span,
+currencies, and portfolio constants.
 
 ### 2.2 分析画像与归因
 
@@ -57,8 +59,9 @@ Explain unresolved attribution. Do not imply consent from authentication.
 
 ### 2.3 标签定义
 
-State label provenance (`file-column` or `user-defined`), confirmed versus proxy,
-and maturity window. Define and count all three populations:
+State label provenance (`file-column`, `user-defined`, or `absent`), confirmed
+versus proxy, and maturity window where applicable. Define and count all known
+populations; state unavailable definitions explicitly rather than inventing them:
 
 | Population | Required content |
 |---|---|
@@ -66,20 +69,25 @@ and maturity window. Define and count all three populations:
 | Negative | Exact values/conditions and count |
 | Unlabeled | Pending, immature, unknown, overlapping, or out-of-scope conditions and count |
 
-Report the positive base rate among labeled rows and its denominator. If an
-existing outcome column supplies the positive label, disclose the assumption
-that its other mature, non-explicitly-unlabeled values are negative. If the user
-defined the positive condition, show the separately supplied negative condition.
-Separate labels for separate archetypes.
+Report the positive base rate among labeled rows only where a meaningful
+positive/negative population exists, with its denominator. If an existing outcome
+column supplies the positive label, disclose the assumption that its other
+mature, non-explicitly-unlabeled values are negative. If the user defined the
+positive condition, show the separately supplied negative condition when present.
+Otherwise keep remaining rows unlabeled and omit unsupported metrics. Absent
+labels do not block a descriptive rule report. Separate archetypes' labels.
 
-### 2.4 时间切分
+### 2.4 证据范围
 
-State cut and train/holdout sizes, or state that metrics are in-sample and
-unvalidated. Name the decision point again in one line.
+State discovery/scoring windows, outcome cutoff, and whether selection and
+measurement use the same transactions. Recent observations and retrospective
+sample metrics do not establish future performance. No train/test/holdout split
+is required; describe subsequent monitoring or optional temporal validation if
+performed. Name the decision point and real-time versus review track.
 
 ## 3. 规则发现
 
-### 3.1 规则清单与验证集指标
+### 3.1 规则清单与观察指标
 
 Suggested columns:
 
@@ -90,7 +98,11 @@ Suggested columns:
 - Group conditions into a few operational rule classes.
 - State explicit windows, units, currency, and frozen-list versions.
 - Use actions supplied by selected context packs.
-- List rules once. Multi-rule unions belong to strategy packages in chapter 4.
+- List rules once. Preserve every transaction-rule hit; a transaction can match
+  several rules. Multi-rule unions belong to strategy packages in chapter 4.
+- Report known-fraud hits, labeled/unlabeled hit counts, and metric denominators.
+  Missing negatives do not prevent discovery; they prevent precision and
+  false-positive claims. Label same-sample selection explicitly.
 
 ### 3.2 稳定性与归因
 
@@ -112,8 +124,13 @@ For every package/action row, report in this order:
 
 1. Triggered count and rate
 2. Triggered amount and amount share, with currency
-3. Precision
-4. Recall
+3. Precision, where labeled hits support it; disclose unlabeled hits separately
+4. Recall, against the explicitly defined known-positive population
+
+Deduplicate package coverage and amount by transaction ID. Show rule overlap and
+incremental coverage against a named base package. Declare action precedence
+before reporting mutually exclusive action totals. Never sum per-rule counts as
+portfolio coverage. Unsupported metrics are unavailable, not zero.
 
 Suggested columns:
 
@@ -147,15 +164,20 @@ assumptions. Keep stricter non-default actions visibly separate.
 
 ### 5.1 入选短名单
 ### 5.2 候选特征集
-### 5.3 训练拟合的观察名单或图谱特征（when applicable）
+### 5.3 参考编码、观察名单或图谱特征（when applicable）
 
-Keep this shorter than rule findings. Name point-in-time construction and weak
-links where material.
+Keep this shorter than rule findings. Name point-in-time construction, current
+transaction inclusion, reference versions, and weak links where material.
+Separate post-transaction entity/period findings from real-time features.
+For collection/payout features, disclose counterparty direction and entity grain,
+FIFO account/currency scope and ledger policy, matched/unmatched funding,
+known-payer coverage, and any enrichment or ownership uncertainty. Matched-only
+fund age and known recent-funds share must retain their coverage qualifiers.
 
 ## 6. 附录
 
 ### A. 决策时点与字段排除
-### B. 标签成熟度、时间切分与训练指标
+### B. 标签成熟度、证据范围与可选验证
 ### C. 仅描述性信号与未入选候选
 ### D. 假设、限制与政策依赖
 
@@ -173,9 +195,9 @@ links where material.
 ### 2.1 样本范围
 ### 2.2 分析画像与归因
 ### 2.3 标签定义
-### 2.4 时间切分
+### 2.4 证据范围
 ## 3. 规则发现
-### 3.1 规则清单与验证集指标
+### 3.1 规则清单与观察指标
 ### 3.2 稳定性与归因
 ### 3.3 可落地运营建议
 ## 4. 策略整体影响

package/skills/risk-compliance/{fraud-analysis → fraud-detection}/references/review-checklist.md

@@ -9,7 +9,7 @@ a fatal issue requires a user-approved restart.
 - Draft report and source paths
 - Analysis profile, event grain, and decision point
 - Label definition, maturity window, and attribution confidence
-- Time cut and train/holdout sizes, or explicit in-sample status
+- Discovery/scoring windows, selection overlap, and optional validation evidence
 - Allowed and excluded fields
 - Rule definitions and metrics with evaluation window
 - Strategy actions, impact measures, denominators, and assumptions
@@ -34,15 +34,15 @@ a fatal issue requires a user-approved restart.
 
 ### Pre-flight
 
-- [ ] Pre-flight status passed before supervised analysis began
+- [ ] Data readiness was established before using affected features or metrics
 - [ ] Input readability, row grain, time field, and label provenance were checked
 - [ ] File-column positives map remaining mature rows to negative only after
   preserving explicit missing/pending/unknown/unlabeled states
-- [ ] User-defined positives received an explicit user-defined negative condition
-  during pre-flight; `NOT positive` was not silently assumed
+- [ ] User-defined positives have explicit negative definitions before metrics
+  requiring negatives; missing negatives do not block rapid discovery
 - [ ] Both/neither/immature rows are unlabeled, or their absence is demonstrated
-- [ ] Descriptive-only analysis is clearly separated from supervised metrics when
-  pre-flight could not establish both classes
+- [ ] Positive-only or unlabeled discovery avoids unsupported precision, lift,
+  false-positive rates, or portfolio recall
 
 ### Analysis profile and attribution
 
@@ -57,40 +57,61 @@ a fatal issue requires a user-approved restart.
 
 ### Label and maturity
 
-- [ ] Label provenance is stated as file-column or user-defined
+- [ ] Label provenance is stated as file-column, user-defined, or absent
 - [ ] Exact positive, negative, and unlabeled definitions and counts are stated
 - [ ] Existing outcome-column labels disclose the assumption used to map other
   mature values to negative and preserve explicit pending/unknown states
-- [ ] User-defined positive labels have a separately user-defined negative class;
-  all other rows are not automatically treated as negative
+- [ ] User-defined positives use separately defined negatives where metrics need
+  them; otherwise negatives are explicitly unavailable and other rows unlabeled
 - [ ] Positive and negative conditions are disjoint; neither/both rows are unlabeled
 - [ ] Confirmed versus proxy status is honest
-- [ ] Positive base rate is factual and uses labeled rows as denominator
+- [ ] Positive base rate, if available, uses labeled rows as denominator;
+  positive-only samples are not presented as a portfolio baseline
 - [ ] Outcome maturity window is defined; immature rows are not clean negatives
 - [ ] Separate archetypes are not blended into one target
 - [ ] Label, synonyms, actions, and later investigation outcomes are excluded
 
-### Temporal validation
+### Evidence basis
 
-- [ ] Earlier train and later holdout cut is stated, or metrics are unvalidated
-- [ ] No random split is presented as temporal validation
-- [ ] Headline metrics come from the claimed window
-- [ ] Thresholds, rate lists, graph lists, and watchlists are fit on train only
-- [ ] Holdout rows may use only history known before each row
+- [ ] Discovery/scoring windows, cutoff, and same-sample selection are disclosed
+- [ ] No mandatory split delays rapid rule discovery
+- [ ] Sample catches are not presented as proof of future performance
+- [ ] Claimed subsequent/temporal validation uses fixed rules and lists, without
+  tuning on the claimed validation outcomes
+- [ ] Reference encodings and graph/list inputs were available at decision time
+- [ ] Missing timestamps disable affected history features rather than invent time
 
 ### Decision-time validity
 
 - [ ] Every rule field exists at the stated decision point
 - [ ] Current response, settlement, return, recall, dispute, reimbursement,
   restriction, and investigation fields do not leak backward
-- [ ] History uses prior events and defines timestamp ties
+- [ ] Real-time scoring is one transaction; duplicates/retries/lifecycle rules
+  and stable transaction IDs are defined
+- [ ] Current transaction contributes by default; first eligible count is one
+- [ ] Windows use the standard vocabulary, elapsed durations, and `(t-window,t]`
+- [ ] Timestamp ties, arrival availability, and late/duplicate processing are defined
+- [ ] Null entity keys are not pooled; distinct counts ignore missing target keys
+- [ ] Amount sums use a declared common currency and explicit missing-FX behavior
+- [ ] Cold-start history and incomplete lookbacks are disclosed
+- [ ] Completed entity/period aggregates remain post-transaction review findings
 - [ ] Graph features are point-in-time snapshots
 - [ ] Zero-variance, timing, leakage, and context-only exclusions are listed
+- [ ] Company/person/account roles and address roles remain distinct; uncertain
+  name, account, or ownership links are not silently merged
+- [ ] Phone/ID geography means documented numbering/document geography, not
+  current residence; unsupported lookups remain unknown
+- [ ] Platform/PSP/holder classifications declare their object, source, timing,
+  and confidence; unknown is not false and independent flags may overlap
 - [ ] Weak entity links are not presented as unique identities
 
 ### Metrics and actions
 
-- [ ] Rule metrics use occurrence → precision → recall
+- [ ] Multiple rule hits per transaction remain intact
+- [ ] Package count/value uses transaction unions, with overlap and incremental
+  coverage; action-level totals declare precedence
+- [ ] Partial-label metrics expose denominators and unlabeled hits
+- [ ] Rule metrics use occurrence → precision → recall where supported
 - [ ] Count metrics remain present when value metrics are added
 - [ ] Small-N, unstable, or attribution-uncertain segments are monitored or dropped
 - [ ] Actions come from selected contexts and match precision/evidence severity
@@ -104,7 +125,7 @@ a fatal issue requires a user-approved restart.
 - [ ] Analysis profile and attribution table appears near the start
 - [ ] Strategy impact is a standalone chapter
 - [ ] Every package/action has triggered count/rate and amount/share with currency,
-  followed by precision and recall
+  followed by precision and recall where supported; unavailable metrics explain why
 - [ ] Mixed currencies are not summed without documented FX conversion
 - [ ] Domain impact measures and denominators come from selected context packs
 - [ ] Observed results are distinct from scenario estimates
@@ -143,8 +164,15 @@ Read and check each selected pack. At minimum:
 
 ### Card payment
 
+- Reported-fraud labels union available DART/network reports and fraud-category
+  disputes, including pre-disputes, by transaction ID; any explicit override is
+  stated. Source-only/overlap/union and lifecycle coverage reconcile.
+- Non-fraud disputes and duplicate lifecycle rows do not inflate positives;
+  reversal/recovery is separate from the existence of a fraud allegation.
+- Scheme-monitoring ratio exclusions do not silently narrow detection labels.
 - Current CVV, AVS, authorization response, and 3DS result respect timing.
-- BIN lists are train-fit; issuer name is live-operable if used.
+- BIN lists state discovery/version and causal availability; issuer name is
+  live-operable if used.
 - 3DS failures are outside subsequent authorization denominator.
 
 ### Collection, transfer, and payout
@@ -152,6 +180,18 @@ Read and check each selected pack. At minimum:
 - Settlement, reversibility, completion, return, and recall timing are correct.
 - Sequence and graph features are point-in-time.
 - Completion, abandonment, delay, workload, and exposure denominators are stated.
+- For collection/payout, apply
+  [collection/payout feature checks](collection-payout-features.md): FIFO stays
+  within ledger account/currency, uses available lots and deterministic order,
+  and conserves each lot across partial allocations.
+- Current payout is previewed once against pre-debit state; pre-debit rejected
+  attempts do not consume funds and reservations cannot be spent twice. A failure
+  after debit does not restore funds without an explicit ledger reversal/return.
+- Unmatched balance and missing counterparty history are disclosed; allocation
+  shares use the stated denominator and are not silently renormalized.
+- Fees, reversals, refunds and FX use explicit ledger semantics; FIFO is an
+  attribution convention, not proof of money provenance.
+- Counterparty features declare direction, identity grain, and pair/entity scope.
 
 ## Finding format