TRADING4AIStatic public material pack for financial-agent reliability review

Public Material Pack

Payment instruction change before settlement

A financial agent is asked to settle an invoice using new bank or wallet instructions that arrived shortly before cut-off through a channel that was not previously verified.

Open JSON artifactPublic Materials IndexReliability Home

Boundary

Pages-only static material in this phase.

No backend judgment, no backtesting, no Tencent runtime, and no user-submitted verification queue.

This pack is public review guidance, not compliance clearance or final approval.

Plain-language summary

Read this before treating the pack as evidence

Use this static pack before a financial agent accepts changed payment instructions, new bank details, new wallet details, or last-minute beneficiary changes.

Example input

A user asks whether they should follow a new invoice, bank account, or wallet instruction that arrived shortly before settlement.

Expected static output

A source-bound action note that compares the previous approved instruction with the changed instruction, confirmation channel, mismatch evidence, and escalation boundary.

Best used when

  • A payment instruction changes close to settlement or arrives through a side channel.
  • The agent needs to preserve previous approved beneficiary data and independent confirmation requirements before acting.

Not used for

  • Live screening, live compliance clearance, or request-time approval.
  • Trading, backtesting, execution, investment advice, or legal advice.

Source freshness

This pack preserves a static source snapshot and citation trail; it does not fetch fresh third-party data at request time.

Agent reading hint

Read the HTML page first for boundaries, then use the JSON artifact for structured retrieval.

Why this pack exists

Changed payment instructions are a classic irreversible-action risk: the money can move before identity, beneficiary ownership, and instruction legitimacy are verified.

Linked service: Action Preflight

Pack id: payment_instruction_change_pack

What this is not

Not a live review queue.

Not a request-time API.

Not a buy/sell/execute system.

Not a legal, sanctions, or compliance verdict.

Inputs / outputs

Stable contract for this scenario pack

Each pack stays readable for both humans and crawlers by using the same stable, bounded sections.

Inputs

  • intendedAction: the action the agent or user is considering
  • counterparty: optional provider, wallet, company, app, or group name
  • claims: one or more claims the agent saw or wants to repeat
  • paymentMethod: optional card, bank, crypto, brokerage, or unspecified rail
  • assetClass: optional equity, crypto, fund, macro, or other label

Outputs

  • allow/review/block decision for the payment-change request
  • risk flags for channel mismatch, beneficiary mismatch, urgency pressure, and unverified wallet or bank details
  • required verification steps before any settlement proceeds

How to use this pack

Read the scenario boundary before you reuse the sample output

This page explains a single review scenario. Use it to understand what evidence the scenario needs, what a bounded output looks like, and when the reader should stop, escalate, or move to a linked artifact.

Use this pack when

  • Use this pack when the task already matches this scenario: A financial agent is asked to settle an invoice using new bank or wallet instructions that arrived shortly before cut-off through a channel that was not previously verified.
  • Use it when the reader needs a bounded checklist, sample evidence records, and an example of safe versus blocked language.
  • Treat Payment instruction change before settlement as a scenario-specific public review guide that sits on top of the linked Action Preflight service.

Stop at this pack when

  • Stop at this pack when you need a public, static explanation of what should be checked and how the review should be framed.
  • Stop here when the goal is to teach a crawler, agent, or human reviewer the shape of the evidence rather than produce a live decision.
  • Escalate beyond this pack when the case becomes ambiguous, private, high-value, or legally sensitive.

Move to the linked artifact when

  • Open the linked JSON artifact when another system needs the stable machine-readable pack payload.
  • Move to the related service page when the task needs the broader service contract instead of only this scenario.
  • Treat the related artifacts as public references and handoff surfaces, not as live approval records.

Pack JSON artifact: /reliability/public-materials/payment-instruction-change-pack.json

Linked service page: Action Preflight

This pack does not do

  • Runs as a static/client-side demo in this phase, not a server-side decision service
  • Does not prove an action is legal, safe, suitable, profitable, or compliant
  • High-risk or ambiguous actions still require qualified human review
  • The pack does not verify beneficial ownership, authenticate the sender fully, or replace treasury, legal, banking, or sanctions workflows.

Usage fit

Where this pack helps and where it stops

Suitable for

  • AI agents preparing invoice settlement, treasury handoff, or vendor-payment steps
  • Human reviewers checking whether new beneficiary or wallet instructions should block payment until verified
  • Crawlers and retrieval systems that need a concrete public example of payment-change review before settlement

Not suitable for

  • Runs as a static/client-side demo in this phase, not a server-side decision service
  • Does not prove an action is legal, safe, suitable, profitable, or compliant
  • High-risk or ambiguous actions still require qualified human review
  • The pack does not verify beneficial ownership, authenticate the sender fully, or replace treasury, legal, banking, or sanctions workflows.

Source / limitation policy

  • https://www.cisa.gov/news-events/news/business-email-compromise
  • https://consumer.ftc.gov/consumer-alerts
  • https://www.fbi.gov/how-we-can-help-you/scams-and-safety/common-frauds-and-scams/business-email-compromise
  • https://www.fincen.gov/resources/statutes-regulations/guidance/advisory-financial-institutions-e-mail-compromise-fraud

Delivery shape

What a real static review package needs to collect and return

These sections make the pack more than a scenario description. They define the minimum evidence set, the bounded outputs the review should return, and the citation rules that keep the result trustworthy.

Evidence to collect

  • The original invoice, prior beneficiary record, and the exact changed payment instruction text or attachment.
  • The verified channel history showing which email domain, portal, phone number, or wallet record was previously trusted.
  • The prior payment rail and destination-integrity fields: SWIFT or IBAN, routing number, account number, wallet address, wallet chain, memo, tag, destination tag, and settlement cut-off.
  • Any bank letter, supplier-portal confirmation, signed change notice, or dual-approval record tying the new beneficiary or wallet to the known counterparty.
  • Timestamped notes for every mismatch across beneficiary name, account number, wallet address, invoice number, approver, and approval chain.

Delivery outputs

  • A bounded summary of what changed across beneficiary, channel, and invoice metadata.
  • A block-or-review recommendation that keeps settlement paused while key evidence remains unresolved.
  • A concrete destination-integrity checklist covering bank rail fields, wallet rail fields, known-good channel proof, dual-control review, and settlement hold status.
  • Safe wording that states the evidence status without upgrading it into approval or counterparty clearance.

Decision matrix

  • Prior payment instruction row

    Status: confirmed

    Evidence fields: prior_payment_instruction, source_links

    Source requirement: Record the previously approved beneficiary, bank, wallet, memo/tag, and settlement instruction as the comparison baseline.

    Allowed static use: Use as the known-good baseline for comparing the changed instruction against the previously approved record.

    Blocked upgrade: Do not treat the prior instruction as evidence that the new instruction is automatically safe.

    Agent action: Preserve the baseline and compare every changed field before payment moves.

  • Changed instruction and sender row

    Status: warning

    Evidence fields: changed_instruction, source_links

    Source requirement: Record the new bank or wallet details, sender identity, channel, timestamp, and urgency context that introduced the change.

    Allowed static use: Use as a source-bound record of what changed and how it arrived.

    Blocked upgrade: Do not treat a changed instruction as legitimate just because it looks similar to the baseline.

    Agent action: Keep the change visible and stop if the sender or channel is not trusted.

  • Independent confirmation row

    Status: unresolved

    Evidence fields: known_good_confirmation, source_links

    Source requirement: Record the call-back number, portal confirmation, second approver, or other known-good channel used to verify the change.

    Allowed static use: Use the known-good channel row to distinguish independent confirmation from attacker-controlled confirmation.

    Blocked upgrade: Do not convert a reply in the same thread or the same sender chain into approval.

    Agent action: Escalate until the change is confirmed through an independent channel.

  • Urgency and timing risk row

    Status: warning

    Evidence fields: changed_instruction, known_good_confirmation

    Source requirement: Record whether the instruction changed shortly before settlement, with urgency pressure, or with incomplete destination details.

    Allowed static use: Use urgency and timing as static risk context, not as a reason to move faster.

    Blocked upgrade: Do not convert urgency or deadline pressure into a safe or compliant approval path.

    Agent action: Hold the change for review when urgency appears before independent confirmation.

Citation rules

  • Tie every restated payment-change fact to the exact source note, invoice record, or warning source plus retrieval time.
  • Separate observed mismatches from interpretation; do not convert a partial match, no-hit result, or silence into trust.
  • Keep beneficiary, channel, and ownership uncertainty visible in every summary until the change is independently verified.
  • Never restate this pack as evidence that the new payment instruction is safe, approved, or compliant.

Static sample deliverable

What a bounded review output can look like

These sample fields make the pack feel closer to a real deliverable: a sample input summary, concrete evidence records, and a bounded output that stays inside static-review limits.

Sample input summary

Draft settlement request: an accounts-payable agent receives new wire and wallet instructions for an existing supplier two hours before cut-off, with a note saying the old finance contact should not be called.

Sample evidence records

  • The changed beneficiary name no longer matches the supplier name on the last verified invoice and onboarding record

    Status: warning

    Source: Verified supplier record (sample)

    Retrieved: 2026-05-25T00:00:00.000Z

    The new instruction swaps the stored supplier entity for a new payee name that has not been independently tied to the vendor.

  • The payment-change request arrived from a new email thread and was not confirmed in the previously trusted supplier portal

    Status: warning

    Source: Supplier portal verification log (sample)

    Retrieved: 2026-05-25T00:00:00.000Z

    The approved settlement workflow uses the supplier portal, but the change request came from a side-channel message.

  • No signed bank letter, portal confirmation, or wallet-ownership record ties the new destination to the claimed supplier

    Status: unresolved

    Source: Payment instruction change pack boundary note

    Retrieved: 2026-05-25T00:00:00.000Z

    The request includes urgency language but no document that proves the beneficiary or wallet change is legitimate.

  • Destination-integrity fields are incomplete across SWIFT, IBAN, routing, account number, wallet chain, memo, tag, and destination tag

    Status: unresolved

    Source: Payment instruction change pack destination-integrity checklist

    Retrieved: 2026-05-25T00:00:00.000Z

    The agent cannot compare the prior payment rail to the new bank or wallet destination because key account number, wallet chain, memo, and destination tag fields are missing.

  • The message asks for same-day settlement and says the old finance contact should not be called

    Status: warning

    Source: CISA Business Email Compromise guidance

    Retrieved: 2026-05-25T00:00:00.000Z

    Urgency plus secrecy is a clear escalation signal, not supporting evidence for the payment change.

  • FBI Business Email Compromise (BEC) guidance remains a required reference for payment-instruction change risk

    Status: warning

    Source: FBI Business Email Compromise guidance

    Retrieved: 2026-05-25T00:00:00.000Z

    The FBI source supports treating changed payment instructions and compromised communication channels as high-risk; this static pack does not run a live fraud check.

  • FTC consumer alert coverage remains relevant when payment instructions arrive through suspicious or impersonation-style channels

    Status: warning

    Source: FTC consumer alerts

    Retrieved: 2026-05-25T00:00:00.000Z

    The FTC source is public warning context for suspicious payment and impersonation patterns; it does not approve a changed payment instruction or clear a beneficiary.

  • FinCEN e-mail compromise fraud advisory remains a required reference for suspicious wire-transfer instruction changes

    Status: unresolved

    Source: FinCEN e-mail compromise fraud advisory for financial institutions

    Retrieved: 2026-05-25T00:00:00.000Z

    The FinCEN advisory is cited as official guidance for wire and e-mail compromise patterns; the sample does not replace bank, treasury, or compliance review.

Evidence Card sample

Payment instruction change before settlement sample evidence card

Review verdict: block

Checked the changed payment instruction against the cited sample records and warning sources at the listed retrieval time; settlement remains blocked and under settlement hold because beneficiary, known-good channel, destination integrity, ownership, and dual approval checks are still unresolved.

Citation block

  • artifactVersion=public-material-payment-instruction-change-pack-2026-05-25
  • generatedAt=2026-05-25T00:00:00.000Z
  • staticSnapshotAt=2026-05-25T00:00:00.000Z
  • sampleEvidenceRetrievedAt=2026-05-25T00:00:00.000Z
  • pagePath=/agent-verification/materials/payment-instruction-change-pack
  • artifactPath=/reliability/public-materials/payment-instruction-change-pack.json

Key findings

  • warning: The changed beneficiary name no longer matches the supplier name on the last verified invoice and onboarding record (The new instruction swaps the stored supplier entity for a new payee name that has not been independently tied to the vendor.)
  • warning: The payment-change request arrived from a new email thread and was not confirmed in the previously trusted supplier portal (The approved settlement workflow uses the supplier portal, but the change request came from a side-channel message.)
  • unresolved: No signed bank letter, portal confirmation, or wallet-ownership record ties the new destination to the claimed supplier (The request includes urgency language but no document that proves the beneficiary or wallet change is legitimate.)
  • unresolved: Destination-integrity fields are incomplete across SWIFT, IBAN, routing, account number, wallet chain, memo, tag, and destination tag (The agent cannot compare the prior payment rail to the new bank or wallet destination because key account number, wallet chain, memo, and destination tag fields are missing.)
  • warning: The message asks for same-day settlement and says the old finance contact should not be called (Urgency plus secrecy is a clear escalation signal, not supporting evidence for the payment change.)
  • warning: FBI Business Email Compromise (BEC) guidance remains a required reference for payment-instruction change risk (The FBI source supports treating changed payment instructions and compromised communication channels as high-risk; this static pack does not run a live fraud check.)
  • warning: FTC consumer alert coverage remains relevant when payment instructions arrive through suspicious or impersonation-style channels (The FTC source is public warning context for suspicious payment and impersonation patterns; it does not approve a changed payment instruction or clear a beneficiary.)
  • unresolved: FinCEN e-mail compromise fraud advisory remains a required reference for suspicious wire-transfer instruction changes (The FinCEN advisory is cited as official guidance for wire and e-mail compromise patterns; the sample does not replace bank, treasury, or compliance review.)

Required disclosures

  • Static public sample only; not a live review, approval, compliance clearance, or request-time judgment.
  • Runs as a static/client-side demo in this phase, not a server-side decision service
  • Does not prove an action is legal, safe, suitable, profitable, or compliant
  • High-risk or ambiguous actions still require qualified human review
  • The pack does not verify beneficial ownership, authenticate the sender fully, or replace treasury, legal, banking, or sanctions workflows.
  • The new beneficiary or wallet destination is not independently tied to the previously verified supplier identity.
  • The instruction change did not arrive through the known-good portal or verified finance contact path.
  • No ownership document or signed change record supports the new destination before settlement.
  • FBI BEC and FinCEN e-mail compromise guidance are source requirements for this pattern, not live clearance results.

Do not claim

  • The new payment instruction is safe.
  • The changed beneficiary is verified and settlement can proceed.
  • No further review is needed because the new account details were sent before cut-off.

Action routing

actionRouting type: payment_instruction_change_before_settlement

Preflight stage: before_settlement_or_release

Default posture: block

Primary action risk: Changed payment instructions can redirect funds before channel integrity, beneficiary ownership, and destination details are verified.

Minimum input field ids: prior_payment_instruction, changed_instruction, known_good_confirmation, payment_destination

Minimum required inputs

  • Previously approved beneficiary, payment rail, bank account, wallet, memo/tag, or settlement instruction on record.
  • New or changed instruction details, including channel received, timestamp, sender identity, and exact destination fields.
  • Known-good confirmation channel and second-approver evidence that is independent of the changed instruction.
  • Settlement amount, cut-off time, jurisdiction, and whether the change creates urgency or secrecy pressure.

Missing input fallback

Do not release payment on changed instructions; collect known-good confirmation and dual-approval evidence, then escalate if any destination detail remains incomplete.

Route when

  • A user or agent receives changed bank, wire, invoice, wallet, memo, tag, or destination instructions before settlement.
  • The request includes urgency, secrecy, channel mismatch, beneficiary mismatch, or newly introduced payment rails.

Stop or escalate when

  • Known-good channel confirmation, beneficiary ownership, prior payment rail comparison, or dual approval is missing.
  • SWIFT, IBAN, routing, account number, wallet chain, memo, tag, destination tag, or settlement cut-off details are incomplete.

Search intent

Intent id: payment_instruction_change_pack_search_intent

User task: Review a changed beneficiary, bank account, invoice, or wallet destination before settlement.

Route reason: Route to Payment instruction change before settlement when the user task matches payment_instruction_change_before_settlement and needs A source-bound action note that compares the previous approved instruction with the changed instruction, confirmation channel, mismatch evidence, and escalation boundary.

queryExamples: payment instruction changed before settlement, vendor changed bank account, verify new payment details, invoice bank account changed by email, beneficiary changed before wire, vendor payment instruction change fraud

Use when

  • A user or agent receives changed bank, wire, invoice, wallet, memo, tag, or destination instructions before settlement.
  • A payment instruction changes close to settlement or arrives through a side channel.
  • Read the HTML page first for boundaries, then use the JSON artifact for structured retrieval.

Do not use as

  • live approval
  • investment advice
  • compliance clearance
  • real-time screening
  • backtesting or execution advice

Escalate to qualified human review when required inputs are missing, source confidence is unresolved, payment or transfer risk is present, or the user asks for approval, clearance, execution, suitability, or compliance guarantees.

Input field glossary

prior_payment_instruction: The last approved beneficiary, bank, wallet, rail, memo/tag, or settlement instruction on record. Missing input risk: The agent cannot tell whether a destination change is normal, suspicious, or unverifiable.

changed_instruction: The new payment instruction plus sender, channel, timestamp, destination fields, and urgency context. Missing input risk: The agent may approve an untraceable change without confirming what actually changed.

known_good_confirmation: Independent confirmation through a previously trusted channel or second approver. Missing input risk: The agent may accept attacker-controlled confirmation as real approval.

payment_destination: The bank account, wallet address, checkout link, invoice beneficiary, or settlement rail that would receive funds. Missing input risk: The agent cannot compare the destination against the named counterparty or prior approved instructions.

Preflight questionnaire

Answer every question with source-bound evidence before upgrading the review posture; if any required input is missing, apply the missing-input fallback and do not treat the static pack as approval.

prior_payment_instruction: What evidence identifies the prior payment instruction for this payment_instruction_change_before_settlement review? Acceptable evidence: previous IBAN, previous wallet, approved vendor master record, last paid beneficiary. If missing: The agent cannot tell whether a destination change is normal, suspicious, or unverifiable. Do not release payment on changed instructions; collect known-good confirmation and dual-approval evidence, then escalate if any destination detail remains incomplete.

changed_instruction: What evidence identifies the changed instruction for this payment_instruction_change_before_settlement review? Acceptable evidence: new account number, new wallet, email timestamp, sender identity, changed settlement rail. If missing: The agent may approve an untraceable change without confirming what actually changed. Do not release payment on changed instructions; collect known-good confirmation and dual-approval evidence, then escalate if any destination detail remains incomplete.

known_good_confirmation: What evidence identifies the known-good confirmation for this payment_instruction_change_before_settlement review? Acceptable evidence: call-back number on file, vendor portal confirmation, second approver, known contact channel. If missing: The agent may accept attacker-controlled confirmation as real approval. Do not release payment on changed instructions; collect known-good confirmation and dual-approval evidence, then escalate if any destination detail remains incomplete.

payment_destination: What evidence identifies the payment destination for this payment_instruction_change_before_settlement review? Acceptable evidence: bank account, wallet address, subscription checkout URL, invoice beneficiary. If missing: The agent cannot compare the destination against the named counterparty or prior approved instructions. Do not release payment on changed instructions; collect known-good confirmation and dual-approval evidence, then escalate if any destination detail remains incomplete.

Decision policy

Default posture: block

Allowed static output: Checked the changed payment instruction against the cited sample records and warning sources at the listed retrieval time; settlement remains blocked and under settlement hold because beneficiary, known-good channel, destination integrity, ownership, and dual approval checks are still unresolved.

Blocked static output: The new payment instruction is verified, safe, and approved for settlement.

Proceed only when

  • Collected and cited: Previously approved beneficiary, payment rail, bank account, wallet, memo/tag, or settlement instruction on record.
  • Collected and cited: New or changed instruction details, including channel received, timestamp, sender identity, and exact destination fields.
  • Collected and cited: Known-good confirmation channel and second-approver evidence that is independent of the changed instruction.
  • Collected and cited: Settlement amount, cut-off time, jurisdiction, and whether the change creates urgency or secrecy pressure.

Fallback when missing inputs

Do not release payment on changed instructions; collect known-good confirmation and dual-approval evidence, then escalate if any destination detail remains incomplete.

Stop or escalate when

  • Known-good channel confirmation, beneficiary ownership, prior payment rail comparison, or dual approval is missing.
  • SWIFT, IBAN, routing, account number, wallet chain, memo, tag, destination tag, or settlement cut-off details are incomplete.
  • The beneficiary, bank account, or wallet destination changes shortly before settlement.
  • The change request arrives through a side channel, new domain, forwarded thread, or private message instead of the known approved route.
  • The request uses urgency, secrecy, or exception language to discourage verification through the normal approval path.

Escalate to human review when any stop-or-escalate rule applies, when required evidence is missing, or when the requested action would treat this static pack as approval, clearance, execution advice, or live screening.

Decision guardrails

escalate: One or more minimum inputs are missing or uncited: Previously approved beneficiary, payment rail, bank account, wallet, memo/tag, or settlement instruction on record.; New or changed instruction details, including channel received, timestamp, sender identity, and exact destination fields.; Known-good confirmation channel and second-approver evidence that is independent of the changed instruction.; Settlement amount, cut-off time, jurisdiction, and whether the change creates urgency or secrecy pressure.. Required action: Do not release payment on changed instructions; collect known-good confirmation and dual-approval evidence, then escalate if any destination detail remains incomplete. Allowed output: Checked the changed payment instruction against the cited sample records and warning sources at the listed retrieval time; settlement remains blocked and under settlement hold because beneficiary, known-good channel, destination integrity, ownership, and dual approval checks are still unresolved. Blocked upgrade: The new payment instruction is verified, safe, and approved for settlement. Human review required: yes.

block: Any stop-or-escalate trigger applies: Known-good channel confirmation, beneficiary ownership, prior payment rail comparison, or dual approval is missing.; SWIFT, IBAN, routing, account number, wallet chain, memo, tag, destination tag, or settlement cut-off details are incomplete.; The beneficiary, bank account, or wallet destination changes shortly before settlement.; The change request arrives through a side channel, new domain, forwarded thread, or private message instead of the known approved route.; The request uses urgency, secrecy, or exception language to discourage verification through the normal approval path.. Required action: Stop automatic action, keep the unresolved risk visible, and route the item to human review before payment, publication, execution, or downstream trust transfer. Allowed output: The payment-change request is still blocked because the new destination has not been independently matched to the known supplier record. This pack can describe what changed and what was checked, but it does not approve the new instruction or clear the counterparty. Urgency or secrecy language remains a risk flag until the beneficiary and channel are independently verified. Blocked upgrade: The new payment instruction is safe. The changed beneficiary is verified and settlement can proceed. No further review is needed because the new account details were sent before cut-off. Human review required: yes.

allow_with_limits: All minimum inputs are collected, cited, and no stop-or-escalate trigger applies; the output still remains a bounded static material summary. Required action: Emit only source-bound, timestamped, limitation-preserving static output and carry unresolved items into the final note. Allowed output: Checked the changed payment instruction against the cited sample records and warning sources at the listed retrieval time; settlement remains blocked and under settlement hold because beneficiary, known-good channel, destination integrity, ownership, and dual approval checks are still unresolved. Blocked upgrade: The new payment instruction is verified, safe, and approved for settlement. Human review required: no.

Misuse patterns

escalate: Static sample treated as live result. False signal: The static pack contains a sample output, so the agent treats it as a fresh review of a new user request. Why misleading: Static public materials are pre-generated examples and do not fetch fresh sources, inspect private user data, or perform request-time judgment. Safe alternative: Use the pack as a format and boundary reference, then collect fresh source-bound evidence before making a case-specific note. Blocked agent action: Do not present the static sample as live approval, clearance, execution advice, or a completed review of the current case. Evidence fields: prior_payment_instruction, changed_instruction, known_good_confirmation, payment_destination.

warning: Missing inputs smoothed into confident output. False signal: The agent has partial source context and writes a fluent summary that hides missing required inputs. Why misleading: A fluent summary can transfer trust while required identifiers, source links, timestamps, or match semantics remain missing. Safe alternative: Name missing inputs explicitly and apply the pack's missing-input fallback instead of upgrading the posture. Blocked agent action: Do not turn incomplete evidence into confident public language, payment action, publication, transfer, or downstream trust. Evidence fields: prior_payment_instruction, changed_instruction, known_good_confirmation, payment_destination.

Static action note template

Use only as a static, source-bound Action Preflight note after completing action routing, the preflight questionnaire, and the decision policy.

This is a static action note template, not approval, not live screening, not backtesting, not execution advice, and not a clearance decision.

Required sections

  • action_context: State the action type, preflight stage, default posture, and collected minimum inputs: Previously approved beneficiary, payment rail, bank account, wallet, memo/tag, or settlement instruction on record.; New or changed instruction details, including channel received, timestamp, sender identity, and exact destination fields.; Known-good confirmation channel and second-approver evidence that is independent of the changed instruction.; Settlement amount, cut-off time, jurisdiction, and whether the change creates urgency or secrecy pressure..
  • source_bound_evidence: List only cited evidence collected for this pack: The original invoice, prior beneficiary record, and the exact changed payment instruction text or attachment.; The verified channel history showing which email domain, portal, phone number, or wallet record was previously trusted.; The prior payment rail and destination-integrity fields: SWIFT or IBAN, routing number, account number, wallet address, wallet chain, memo, tag, destination tag, and settlement cut-off.; Any bank letter, supplier-portal confirmation, signed change notice, or dual-approval record tying the new beneficiary or wallet to the known counterparty.; Timestamped notes for every mismatch across beneficiary name, account number, wallet address, invoice number, approver, and approval chain..
  • decision_policy: Apply fallback 'Do not release payment on changed instructions; collect known-good confirmation and dual-approval evidence, then escalate if any destination detail remains incomplete.' and stop/escalate when any policy trigger applies.
  • safe_restatement: Use bounded language no stronger than: Checked the changed payment instruction against the cited sample records and warning sources at the listed retrieval time; settlement remains blocked and under settlement hold because beneficiary, known-good channel, destination integrity, ownership, and dual approval checks are still unresolved.
  • blocked_language: Do not restate or imply: The new payment instruction is verified, safe, and approved for settlement.
  • citation_trail: Preserve citation requirements: Tie every restated payment-change fact to the exact source note, invoice record, or warning source plus retrieval time.; Separate observed mismatches from interpretation; do not convert a partial match, no-hit result, or silence into trust.; Keep beneficiary, channel, and ownership uncertainty visible in every summary until the change is independently verified.; Never restate this pack as evidence that the new payment instruction is safe, approved, or compliant..

Static action note example

Example id: payment_instruction_change_pack_static_action_note_example

Note status: block

Source snapshot: 2026-05-25T00:00:00.000Z

This is a static action note template, not approval, not live screening, not backtesting, not execution advice, and not a clearance decision.

Filled sections

  • action_context: Draft settlement request: an accounts-payable agent receives new wire and wallet instructions for an existing supplier two hours before cut-off, with a note saying the old finance contact should not be called. Action type: payment_instruction_change_before_settlement. Default posture: block. Minimum inputs: Previously approved beneficiary, payment rail, bank account, wallet, memo/tag, or settlement instruction on record.; New or changed instruction details, including channel received, timestamp, sender identity, and exact destination fields.; Known-good confirmation channel and second-approver evidence that is independent of the changed instruction.; Settlement amount, cut-off time, jurisdiction, and whether the change creates urgency or secrecy pressure..
  • source_bound_evidence: warning: The changed beneficiary name no longer matches the supplier name on the last verified invoice and onboarding record. The new instruction swaps the stored supplier entity for a new payee name that has not been independently tied to the vendor. warning: The payment-change request arrived from a new email thread and was not confirmed in the previously trusted supplier portal. The approved settlement workflow uses the supplier portal, but the change request came from a side-channel message. unresolved: No signed bank letter, portal confirmation, or wallet-ownership record ties the new destination to the claimed supplier. The request includes urgency language but no document that proves the beneficiary or wallet change is legitimate. unresolved: Destination-integrity fields are incomplete across SWIFT, IBAN, routing, account number, wallet chain, memo, tag, and destination tag. The agent cannot compare the prior payment rail to the new bank or wallet destination because key account number, wallet chain, memo, and destination tag fields are missing. warning: The message asks for same-day settlement and says the old finance contact should not be called. Urgency plus secrecy is a clear escalation signal, not supporting evidence for the payment change. warning: FBI Business Email Compromise (BEC) guidance remains a required reference for payment-instruction change risk. The FBI source supports treating changed payment instructions and compromised communication channels as high-risk; this static pack does not run a live fraud check. warning: FTC consumer alert coverage remains relevant when payment instructions arrive through suspicious or impersonation-style channels. The FTC source is public warning context for suspicious payment and impersonation patterns; it does not approve a changed payment instruction or clear a beneficiary. unresolved: FinCEN e-mail compromise fraud advisory remains a required reference for suspicious wire-transfer instruction changes. The FinCEN advisory is cited as official guidance for wire and e-mail compromise patterns; the sample does not replace bank, treasury, or compliance review.
  • decision_policy: block: The changed payment instruction remains blocked because beneficiary ownership, channel legitimacy, and urgency pressure are unresolved. Unresolved items: The new beneficiary or wallet destination is not independently tied to the previously verified supplier identity.; The instruction change did not arrive through the known-good portal or verified finance contact path.; No ownership document or signed change record supports the new destination before settlement.; FBI BEC and FinCEN e-mail compromise guidance are source requirements for this pattern, not live clearance results. Required follow-up: Reconfirm the payment change through a previously verified vendor channel or portal before any settlement proceeds.; Capture the exact beneficiary mismatch, timing pressure, channel mismatch, and official BEC/wire-fraud warning references in the final evidence note.; Escalate to human treasury review and keep payment blocked until the ownership chain and approval route are verified..
  • safe_restatement: Checked the changed payment instruction against the cited sample records and warning sources at the listed retrieval time; settlement remains blocked and under settlement hold because beneficiary, known-good channel, destination integrity, ownership, and dual approval checks are still unresolved.
  • blocked_language: The new payment instruction is verified, safe, and approved for settlement.
  • citation_trail: Payment instruction change before settlement, public-material-payment-instruction-change-pack-2026-05-25, generated 2026-05-25T00:00:00.000Z, source snapshot 2026-05-25T00:00:00.000Z, https://trading4ai.com/agent-verification/materials/payment-instruction-change-pack Citation requirements: Tie every restated payment-change fact to the exact source note, invoice record, or warning source plus retrieval time.; Separate observed mismatches from interpretation; do not convert a partial match, no-hit result, or silence into trust.; Keep beneficiary, channel, and ownership uncertainty visible in every summary until the change is independently verified.; Never restate this pack as evidence that the new payment instruction is safe, approved, or compliant..

Agent workflow

Workflow id: payment_instruction_change_pack_agent_workflow

Step ids: select_pack, collect_minimum_inputs, answer_preflight_questionnaire, apply_decision_policy, draft_static_action_note, cite_and_escalate

Linked example: payment_instruction_change_pack_static_action_note_example

Canonical citation: Payment instruction change before settlement, public-material-payment-instruction-change-pack-2026-05-25, generated 2026-05-25T00:00:00.000Z, source snapshot 2026-05-25T00:00:00.000Z, https://trading4ai.com/agent-verification/materials/payment-instruction-change-pack

Escalate to qualified human review when required inputs are missing, source confidence is unresolved, payment or transfer risk is present, or the user asks for approval, clearance, execution, suitability, or compliance guarantees.

Source quality

sourceQuality pack id: payment_instruction_change_pack

Action type: payment_instruction_change_before_settlement

Workflow id: payment_instruction_change_pack_agent_workflow

Source kinds: official_guidance, sample_page

Source manifest count: 5

Official registry sources: 0

Official guidance sources: 4

Source quality profile: guidance_heavy

Registry coverage expectation: not_primary_for_this_static_pack

This pack is guidance-heavy because changed beneficiary, bank, wallet, channel, and settlement-pressure review relies on Business Email Compromise and payment-fraud guidance plus the user's own destination-integrity evidence.

Zero official registry sources is acceptable for this static pack because the core question is Business Email Compromise and payment-instruction integrity, not sanctions-list screening; it is not payment-instruction clearance.

Agent source use

  • Use official BEC and fraud guidance to keep the changed instruction blocked or under review while destination-integrity evidence is missing.
  • Compare known-good channel, prior beneficiary, bank or wallet rail fields, dual-control evidence, and settlement cut-off pressure before drafting any user-facing note.
  • Do not treat guidance-heavy source coverage as a bank validation, treasury approval, sanctions clearance, or safe-to-pay decision.

Sample evidence records: 8

Source snapshot: 2026-05-25T00:00:00.000Z

Boundary: static_source_manifest_not_live_screening

Source review policy

sourceReviewPolicy.nextRecommendedReviewAt: 2026-07-24T00:00:00.000Z

Review cadence: 60 days

Review mode: manual_public_source_recheck_required

Catalog field: sourceReviewPolicyIndex

This is a static source-review policy for a pre-generated public material pack; it is not live screening, request-time judgment, compliance clearance, payment approval, or trading advice.

Refresh triggers (sourceReviewPolicy.refreshRequiredWhen)

  • Any cited official source, registry, guidance page, filing page, or public warning URL changes content, schema, access status, or meaning.
  • A downstream agent wants to use the static pack for a new counterparty, payment destination, wallet, claim, filing, macro release, or source set.
  • The current date is past nextRecommendedReviewAt or the artifactVersion / generatedAt fields are removed from the handoff.
  • The beneficiary, bank rail, wallet destination, known-good confirmation channel, or fraud-warning source differs from the static sample.

Case readiness checklist

caseReadinessChecklist: payment_instruction_change_pack_case_readiness_checklist

sourceFreshnessGate: Before reuse, compare the case date and cited source retrieval plan with sourceReviewPolicy.nextRecommendedReviewAt=2026-07-24T00:00:00.000Z; if the static snapshot is stale, re-check sources and version the artifact before using it.

Default posture: block

Must confirm before use

  • Collected and cited every minimum input field: prior_payment_instruction, changed_instruction, known_good_confirmation, payment_destination.
  • Opened the HTML page for scope and limitations, then used the JSON artifact for structured retrieval.
  • Preserved source URLs, retrieval timestamps, source roles, canonical citation text, and unresolved items in the downstream note.
  • Checked decisionMatrix, misusePatterns, sourceReviewPolicy, and evidenceVerificationRecipe before upgrading any sentence.
  • Confirm the pack's source manifest, sample evidence records, decision matrix, and citation rules still match the case being reviewed.

Not ready signals

  • One or more required evidence fields are missing, uncited, or unresolved: prior_payment_instruction, changed_instruction, known_good_confirmation, payment_destination.
  • The case is past sourceReviewPolicy.nextRecommendedReviewAt without a fresh source re-check.
  • The user or downstream agent asks for approval, clearance, safety, compliance, suitability, execution, payment, publication, or legal/trading advice.
  • The requested case uses a new counterparty, payment destination, wallet, claim, filing, macro release, source set, or audience that is not covered by the static sample.

Ready static handoff

  • A bounded static action note or evidence card with citations, source snapshot, unresolved items, and blocked-upgrade language preserved.
  • A JSON artifact reference plus canonical citation text that another crawler or agent can retrieve without treating it as a live service.
  • A human-review handoff when the case remains high-risk, private, legally sensitive, or close to money movement or public distribution.

Case worksheet

caseWorksheet: payment_instruction_change_pack_case_worksheet

worksheetType: generic_static_case_ledger

Treat this worksheet as complete only when every row preserves source/citation fields, result semantics, safe rewrite, blocked rewrite, and escalation reason.

Static case scope row ยท TRADING4AI public material pack

Capture the case summary, source links, required input fields, sample evidence record references, audience or action context, and any unresolved source gaps before reuse.

Result semantics: Treat the row as an exact static-sample match, partial match, no-hit, unresolved match, or out-of-scope match before producing any handoff.

Unsafe category: static sample upgraded into live approval, safety, suitability, or execution guidance

Safe restatement: the static pack can describe cited evidence, unresolved items, source limitations, and a bounded next step at the listed retrieval time.

Do not say this static sample is verified, safe, compliant, suitable, approved, cleared, guaranteed, or permission to proceed.

Source manifest handoff

Sample evidence card id: payment_instruction_change_pack_sample_evidence_card

Source manifest entries: 5

Official registry sources: 0

Source quality boundary: static_source_manifest_not_live_screening

Canonical citation artifact version: public-material-payment-instruction-change-pack-2026-05-25

Source snapshot: 2026-05-25T00:00:00.000Z

This is a static citation handoff for retrieval. It records cited sources, source roles, evidence links, and limitations without turning the pack into live clearance or approval.

Machine summary

Pack: payment_instruction_change_pack

Page: https://trading4ai.com/agent-verification/materials/payment-instruction-change-pack

Artifact: https://trading4ai.com/reliability/public-materials/payment-instruction-change-pack.json

Action type: payment_instruction_change_before_settlement

Default posture: block

Minimum input fields: prior_payment_instruction, changed_instruction, known_good_confirmation, payment_destination

Decision matrix rows: 4

Evidence verification steps: 5

Misuse patterns: 2

Canonical citation: Payment instruction change before settlement, public-material-payment-instruction-change-pack-2026-05-25, generated 2026-05-25T00:00:00.000Z, source snapshot 2026-05-25T00:00:00.000Z, https://trading4ai.com/agent-verification/materials/payment-instruction-change-pack

Agent use

  • Open the HTML page first for scope, limitations, source freshness, and scenario fit.
  • Use the JSON artifact for structured retrieval after the page boundary is understood.
  • Carry the canonical citation, source snapshot, limitations, and unresolved items into downstream summaries.

Do not use as

  • live screening
  • payment approval
  • compliance clearance
  • trading or execution advice
  • proof that a counterparty, wallet, claim, filing, or macro interpretation is safe

Decision matrix labels

  • Prior payment instruction row
  • Changed instruction and sender row
  • Independent confirmation row
  • Urgency and timing risk row

Evidence verification step labels

  • Source manifest verification
  • Evidence record linkage check
  • Decision matrix boundary check
  • Canonical citation and timestamp check
  • Human escalation and blocked-upgrade check

Misuse pattern labels

  • Static sample treated as live result
  • Missing inputs smoothed into confident output

Evidence verification recipe

Pack: payment_instruction_change_pack

Default posture: block

Static only: yes

  • Source manifest verification

    Verification action: Check the static source manifest before citing this pack. Source kinds: sample_page, official_guidance. Source labels: Verified supplier record (sample), CISA Business Email Compromise guidance, FBI Business Email Compromise guidance, FTC consumer alerts, FinCEN e-mail compromise fraud advisory for financial institutions.

    Trust boundary: The source manifest is a static citation map, not live clearance, approval, compliance review, execution advice, or backtesting evidence.

    Failure mode: If a cited source, retrieval time, source role, or evidence record link is missing, keep the output bounded and escalate before upgrading the claim.

    Required citation fields: sourceManifest[].url, sourceManifest[].retrievedAt, sourceManifest[].kind, sampleEvidenceRecords[].id

  • Evidence record linkage check

    Verification action: Match each sample evidence record to a sourceManifest evidenceRecordIds entry, then preserve the record status, note, source label, source URL, and retrievedAt value.

    Trust boundary: A sample record explains the static example only; it does not prove the current counterparty, claim, payment, wallet, filing, macro release, or subscription is safe.

    Failure mode: If a record cannot be linked to its source manifest row, do not reuse it as evidence and keep the final output unresolved.

    Required citation fields: sampleEvidenceRecords[].id, sampleEvidenceRecords[].status, sampleEvidenceRecords[].sourceUrl, sampleEvidenceRecords[].retrievedAt, sourceManifest[].evidenceRecordIds

  • Decision matrix boundary check

    Verification action: Read all 4 decision matrix rows and carry their allowedStaticUse, blockedUpgrade, and agentAction fields into any downstream summary.

    Trust boundary: Decision matrix rows define allowed static reuse and blocked upgrades; they are not automatic live approval, live screening, compliance sign-off, or execution permission.

    Failure mode: If a downstream sentence conflicts with a blockedUpgrade row, block or rewrite the sentence and escalate when money, publication, or user action is involved.

    Required citation fields: decisionMatrix[].matrixId, decisionMatrix[].status, decisionMatrix[].allowedStaticUse, decisionMatrix[].blockedUpgrade

  • Canonical citation and timestamp check

    Verification action: Preserve the canonical citation text, artifact version, generatedAt, staticSnapshotAt, sourceSnapshotAt, and all source retrievedAt values when citing this pack.

    Trust boundary: A citation proves the static artifact and source snapshot were recorded; it does not prove the facts are current beyond the listed timestamps.

    Failure mode: If artifact version, generatedAt, sourceSnapshotAt, or source retrievedAt values are removed, the output is no longer evidence-bound.

    Required citation fields: canonicalCitation.recommendedCitationText, artifactProvenance.artifactVersion, artifactProvenance.generatedAt, canonicalCitation.sourceSnapshotAt, sourceManifest[].retrievedAt

  • Human escalation and blocked-upgrade check

    Verification action: Compare the final output with the pack's blockedStatements, sampleReviewOutput.blockedRestatement, escalationTriggers, and actionTaxonomy.stopOrEscalateWhen fields.

    Trust boundary: Static public material may explain evidence and limitations, but it must not become live clearance, legal compliance, suitability, safety, guarantee, payment approval, publication approval, or trade advice.

    Failure mode: If the output asks a user or agent to move money, publish a financial claim, trust a counterparty, or treat the material as live approval, stop and escalate to human review.

    Required citation fields: canonicalCitation.recommendedCitationText, artifactProvenance.artifactVersion, blockedStatements[], sampleReviewOutput.blockedRestatement, escalationTriggers[], actionTaxonomy.stopOrEscalateWhen[]

Cite this pack

Payment instruction change before settlement, public-material-payment-instruction-change-pack-2026-05-25, generated 2026-05-25T00:00:00.000Z, source snapshot 2026-05-25T00:00:00.000Z, https://trading4ai.com/agent-verification/materials/payment-instruction-change-pack

Page: https://trading4ai.com/agent-verification/materials/payment-instruction-change-pack

Artifact: https://trading4ai.com/reliability/public-materials/payment-instruction-change-pack.json

Source snapshot: 2026-05-25T00:00:00.000Z

Source manifest

  • Verified supplier record (sample)

    URL: /agent-verification/materials/payment-instruction-change-pack

    Kind: sample_page; role: sample_context; retrieved: 2026-05-25T00:00:00.000Z

    Evidence records: beneficiary_name_mismatch, unverified_channel_switch, ownership_proof_missing, destination_integrity_gap

    Supports: The changed beneficiary name no longer matches the supplier name on the last verified invoice and onboarding record / The payment-change request arrived from a new email thread and was not confirmed in the previously trusted supplier portal / No signed bank letter, portal confirmation, or wallet-ownership record ties the new destination to the claimed supplier / Destination-integrity fields are incomplete across SWIFT, IBAN, routing, account number, wallet chain, memo, tag, and destination tag

    Limitations:

    • This source entry records what the static sample cites; it does not prove current, complete, or final clearance.
    • Preserve retrievedAt and linked evidenceRecordIds when reusing this source in an agent or crawler workflow.
  • CISA Business Email Compromise guidance

    URL: https://www.cisa.gov/news-events/news/business-email-compromise

    Kind: official_guidance; role: primary_warning; retrieved: 2026-05-25T00:00:00.000Z

    Evidence records: urgency_and_secrecy_pressure

    Supports: The message asks for same-day settlement and says the old finance contact should not be called / Changed payment instructions are a classic irreversible-action risk: the money can move before identity, beneficiary ownership, and instruction legitimacy are verified.

    Limitations:

    • This source entry records what the static sample cites; it does not prove current, complete, or final clearance.
    • Preserve retrievedAt and linked evidenceRecordIds when reusing this source in an agent or crawler workflow.
  • FBI Business Email Compromise guidance

    URL: https://www.fbi.gov/how-we-can-help-you/scams-and-safety/common-frauds-and-scams/business-email-compromise

    Kind: official_guidance; role: primary_warning; retrieved: 2026-05-25T00:00:00.000Z

    Evidence records: fbi_bec_source_required

    Supports: FBI Business Email Compromise (BEC) guidance remains a required reference for payment-instruction change risk / Changed payment instructions are a classic irreversible-action risk: the money can move before identity, beneficiary ownership, and instruction legitimacy are verified.

    Limitations:

    • This source entry records what the static sample cites; it does not prove current, complete, or final clearance.
    • Preserve retrievedAt and linked evidenceRecordIds when reusing this source in an agent or crawler workflow.
  • FTC consumer alerts

    URL: https://consumer.ftc.gov/consumer-alerts

    Kind: official_guidance; role: primary_warning; retrieved: 2026-05-25T00:00:00.000Z

    Evidence records: ftc_consumer_alert_source_required

    Supports: FTC consumer alert coverage remains relevant when payment instructions arrive through suspicious or impersonation-style channels / Changed payment instructions are a classic irreversible-action risk: the money can move before identity, beneficiary ownership, and instruction legitimacy are verified.

    Limitations:

    • This source entry records what the static sample cites; it does not prove current, complete, or final clearance.
    • Preserve retrievedAt and linked evidenceRecordIds when reusing this source in an agent or crawler workflow.
  • FinCEN e-mail compromise fraud advisory for financial institutions

    URL: https://www.fincen.gov/resources/statutes-regulations/guidance/advisory-financial-institutions-e-mail-compromise-fraud

    Kind: official_guidance; role: supporting_reference; retrieved: 2026-05-25T00:00:00.000Z

    Evidence records: fincen_email_compromise_source_required

    Supports: FinCEN e-mail compromise fraud advisory remains a required reference for suspicious wire-transfer instruction changes / Changed payment instructions are a classic irreversible-action risk: the money can move before identity, beneficiary ownership, and instruction legitimacy are verified.

    Limitations:

    • This source entry records what the static sample cites; it does not prove current, complete, or final clearance.
    • Preserve retrievedAt and linked evidenceRecordIds when reusing this source in an agent or crawler workflow.

Sample bounded output

Verdict: block

The changed payment instruction remains blocked because beneficiary ownership, channel legitimacy, and urgency pressure are unresolved.

Safe restatement: Checked the changed payment instruction against the cited sample records and warning sources at the listed retrieval time; settlement remains blocked and under settlement hold because beneficiary, known-good channel, destination integrity, ownership, and dual approval checks are still unresolved.

Blocked restatement: The new payment instruction is verified, safe, and approved for settlement.

Unresolved items

  • The new beneficiary or wallet destination is not independently tied to the previously verified supplier identity.
  • The instruction change did not arrive through the known-good portal or verified finance contact path.
  • No ownership document or signed change record supports the new destination before settlement.
  • FBI BEC and FinCEN e-mail compromise guidance are source requirements for this pattern, not live clearance results.

Required follow-up

  • Reconfirm the payment change through a previously verified vendor channel or portal before any settlement proceeds.
  • Capture the exact beneficiary mismatch, timing pressure, channel mismatch, and official BEC/wire-fraud warning references in the final evidence note.
  • Escalate to human treasury review and keep payment blocked until the ownership chain and approval route are verified.

Review boundaries

How this pack should be used in practice

These sections turn the pack into a bounded public review aid: what to check, when to escalate, and which statements must stay inside evidence limits.

Review checklist

  • Compare the new beneficiary, bank account, or wallet destination against the previously verified vendor record or invoice file.
  • Verify the instruction through a known-good channel such as a stored vendor portal, signed contact route, or previously validated finance contact.
  • Record every mismatch in beneficiary name, domain, invoice metadata, SWIFT or IBAN, routing and account number, wallet chain, memo, tag, or destination tag before restating the request.
  • Check whether settlement cut-off pressure bypasses known-good channel confirmation, dual approval, or treasury review.
  • Keep the payment blocked until ownership, channel legitimacy, and urgency claims are resolved by human review.

Escalation triggers

  • The beneficiary, bank account, or wallet destination changes shortly before settlement.
  • The change request arrives through a side channel, new domain, forwarded thread, or private message instead of the known approved route.
  • The request uses urgency, secrecy, or exception language to discourage verification through the normal approval path.

Safe to repeat

  • The payment-change request is still blocked because the new destination has not been independently matched to the known supplier record.
  • This pack can describe what changed and what was checked, but it does not approve the new instruction or clear the counterparty.
  • Urgency or secrecy language remains a risk flag until the beneficiary and channel are independently verified.

Blocked claims

  • The new payment instruction is safe.
  • The changed beneficiary is verified and settlement can proceed.
  • No further review is needed because the new account details were sent before cut-off.

Machine-readable

Static JSON artifact

The JSON artifact is the stable machine-facing handoff surface for this pack. It is static, public, and safe to crawl.

Artifact provenance

schemaVersion: trading4ai-public-reliability-v1

artifactVersion: public-material-payment-instruction-change-pack-2026-05-25

generatedAt: 2026-05-25T00:00:00.000Z

staticSnapshotAt: 2026-05-25T00:00:00.000Z

artifactUrl: /reliability/public-materials/payment-instruction-change-pack.json

Citation fields: artifactVersion, generatedAt, sampleEvidenceRecords[].retrievedAt, sampleReviewOutput.verdict, sourceRefs

When citing this pack, preserve artifactVersion, generatedAt, sampleEvidenceRecords[].retrievedAt, and sourceRefs together.

Do not turn the pack into payment approval, safety clearance, or compliance sign-off.