# Extraction acceptance record

Use this for one dataset supporting one bounded decision. A successful response, parsed file, or completed job does not establish that the required records arrived. This record grants no data-access, action, or release authority.

## Start with these questions

1. Which records should have arrived for this decision, and which are excluded?
2. Which independently obtained source can confirm their identities and current values?
3. What evidence shows you fetched every required page or range?
4. What must stay unresolved if the source cannot prove completeness or currentness?

## Name the decision and population

- Decision the extract supports:
- Accountable workflow owner and decision deadline:
- Source owner, permitted account/tenant, object type, and interface:
- Which records belong in the list, filters, what one row represents, and identifiers that stay attached to each business record:
- Exclusions, reasons, and who accepts them:
- Required fields and their meanings:
- Snapshot time or observation window, including timezone:
- Maximum permitted age when the decision is made:

## Establish the source contract

- Does the source provide a fixed snapshot or export ID? If so, which one?
- How do you request the next page or range, know there are no more, and recover if the continuation token expires?
- Which independent list defines the expected population, and how was it obtained?
- Who owns and reviews that reference, which revision is it, and when was it observed?
- What does a source revision mean, and does the source guarantee the order in which revisions arrive?
- Which timestamp says when a change took effect, and which says when it arrived?
- What happens with late arrivals, backdated corrections, deleted records, and restored records?
- Which permission changes or source filters could remove records from the result?
- What can the available interface not establish?

Do not invent a snapshot guarantee or reference. Record a missing guarantee as unknown and identify the decision that cannot yet rely on this extract.

## Reconcile the candidate extract

| Check             | Result and evidence                                                                              |
| ----------------- | ------------------------------------------------------------------------------------------------ |
| Response or batch | Requested pages/ranges, returned status, failures, and retries                                   |
| Scope             | Source account, tenant, population filters, fields, and permitted purpose match                  |
| Pages/ranges      | Required continuation or range evidence; where fetching stopped                                  |
| Counts            | Expected and received counts, unique counts, declared exclusions, differences                    |
| Identities        | Missing, unexpected, duplicated, or unmatched business keys                                      |
| Critical fields   | Revision, effective time, and values compared with a trustworthy reference                       |
| Amendments        | Gap, stale arrival, conflicting revision, deletion, correction, and replay results               |
| Freshness         | What proves updates have arrived through the required time, and how old records may be when used |
| Lineage           | Source/export revision, adapter build, transformation version, and run identity                  |
| Unknowns          | Gaps preserved; candidate records not silently treated as complete                               |

A matched count alone cannot establish matching identities or current state. A reference created from the candidate extract cannot independently prove that candidate's completeness.

## Filled hypothetical check

- Decision: prepare a coordinator review list; no dispatch write.
- Population: active west-region orders at 2026-10-12 09:00 UTC.
- Fixed exercise reference: `orders-west`, `snapshot-0900`, scope `active-west-orders`.
- Expected eligible keys: O-101, O-102, O-103. O-900 is archived and explicitly excluded.
- Expected decision-critical state: O-103 revision 1 has `hold: true`.
- Candidate A: only page 1 arrived, with status 200. O-103 and its hold are missing.
- Candidate A disposition: reject; accept no rows for the bounded review result.
- Candidate B: three unique keys, but O-999 replaced O-103. Count matches; identities fail.
- Amendment case: revision 3 arrives while revision 1 is stored. Consecutive revision 2 is missing, so reconcile before applying revision 3 under this fixture's contract.
- Later stale arrival: after revisions 2 and 3 apply, repeated revision 2 must not clear revision 3's hold.
- No reference: unknown, with no accepted rows. These are fixed teaching assertions, not a live freshness or source-quality result.

The exercise assumes consecutive per-order revisions and nondecreasing effective times. It excludes deletions and concurrency. Establish the target source's actual contract before adapting those rules.

## Make a bounded decision

- Checks passed and exact evidence:
- Checks failed or remain unknown:
- Disposition: accept this bounded extract / reject / constrain / pause:
- Decision owner, independent reviewer, and recorded time:
- Permitted fallback and who runs it:
- Correction, reconciliation, and replay owner:
- Test case preserving the failure:
- Trigger for invalidating this acceptance:
- Next review date:

Acceptance of an extract does not authorize a business action. Recheck current source state, identity, scope, policy, and approval at any consequential write boundary, then verify the actual destination result separately.