PF_MULTI_007 — Reconciled sales-order and AR-invoice trial migration before cutover

This proof tests one bounded slice of a buyer's own authorized incumbent extract. It requires a manifest fixed before any load, a dry-run that surfaces unmatched records before execution, and reconciliation of counts, financial control totals, and sampled document links against that manifest, with a migrated, excluded, or unresolved status recorded for every record type before cutover is approved. It does not establish export rights, attachment or history migration, coverage for record types outside the two named import hooks, or throughput at production migration volume.

kind: proof_catalog
schema_version: 2
proofs:
  - id: PF_MULTI_007
    vertical_ids:
      - M1_V1
      - M1_V2
      - M1_V3
      - M1_V4
      - M1_V5
      - M1_V6
      - M1_V7
    name: 'Reconciled sales-order and AR-invoice trial migration before cutover'
    status: approved
    proof_type: 'workflow test'
    safe_artifact: >-
      One sanitized, permissioned slice of the buyer's own authorized incumbent
      extract: an in-progress sales-order file and a matching item-level
      accounts-receivable file in the "Sales by Item Detail" shape, with
      customer-identifying and unnecessary commercial data masked. It is
      accompanied by a predeclared manifest stating the expected sales-order and
      invoice counts, the source financial control total, the sampled
      source-to-target document links to be checked, and the record types
      knowingly excluded from this slice. No live incumbent or customer database
      access is required.
    procedure:
      - >-
        Fix the manifest before any load: expected counts, the source financial
        control total, the specific source invoice-to-order links to be sampled,
        the sample size, and the exclusions.
      - >-
        Import the sales-order slice through
        data-import-ai/import-in-progress-sales-orders and record its Phase 0
        diagnostic report.
      - >-
        Run the accounts-receivable import in dry-run mode and inspect
        diagnosticReport for unmatched accounts, contacts, sales orders, items,
        packagings, and warehouses.
      - >-
        Correct the source data and repeat the dry-run until the remaining
        diagnostic entries are either zero or recorded as accepted exclusions.
      - >-
        Execute the load and record the resulting insertErrors list.
      - >-
        Reconcile counts: compare the imported sales-order and invoice counts
        with the manifest and itemize every difference.
      - >-
        Reconcile value: compare the summed data.amountGrossTotal of the
        imported invoices with the manifest control total and itemize every
        variance with its cause.
      - >-
        Reconcile relationships: for the predeclared sample, confirm that
        data.salesOrderId, data.orderLines.salesOrderId, and
        data.orderLines.lineItemId resolve to the sales order and line the
        source specified.
      - >-
        Record a migrated, excluded, or unresolved status for every record type
        and relationship in the manifest.
      - >-
        Reset with data-import-ai/cleanup-imported-ar-invoices in dry-run, then
        mode='delete', and repeat the affected trial if any criterion fails.
    expected_observation: >-
      The buyer can inspect a dry-run diagnosticReport, an insertErrors list
      from the executed load, imported sales orders and invoices whose counts
      and summed data.amountGrossTotal can be compared line by line with the
      predeclared manifest, sampled invoice lines whose salesOrderId and
      lineItemId resolve to the specified source documents, and a
      per-record-type migrated, excluded, or unresolved status recorded before
      cutover approval.
    acceptance_criterion: >-
      Every record type and relationship in the predeclared manifest carries a
      documented migrated, excluded, or unresolved status; imported sales-order
      and invoice counts equal the manifest counts or every difference is
      itemized with its cause; the summed data.amountGrossTotal of the imported
      invoices equals the manifest financial control total or every variance is
      itemized with its cause; every link in the predeclared relationship sample
      resolves through data.salesOrderId and data.orderLines.lineItemId to the
      source-specified sales order and line; and the final dry-run
      diagnosticReport and the executed load's insertErrors are empty or contain
      only entries the buyer recorded as accepted exclusions before cutover
      approval. This criterion is objectively testable rather than
      buyer-defined: EV_MULTI_008 reports that buyers accepted their
      reconciliation result but supplies no numeric threshold.
    owner: sales
    capability_boundaries:
      - >-
        EV_MULTI_008 is buyer-interview evidence relayed by Gabriel Paunescu in
        an authoring session; buyers did not answer directly here. The reported
        basis is production usage analytics, not a controlled trial.
      - >-
        The reported 25 accounts of 20 to 100 employees on a single site span
        M1_V1 through M1_V7 collectively. Per-vertical counts, account
        identities, interview dates, and the observation period were not
        supplied, so vertical membership is reported rather than separately
        observed in each vertical.
      - >-
        No measured value was supplied. Counts, financial control totals,
        relationship match rates, exception tolerances, and the number of trial
        repeats were reported as measured and accepted, but none of their values
        is established by this proof.
      - >-
        Scope is limited to in-progress sales orders and accounts-receivable
        invoices and credit memos through the two named import hooks. MCP server
        d8189168 does not establish import coverage for every operating record a
        buyer may require.
      - >-
        All four S_00011 capabilities are classified configured. Column
        mappings, identifiers, units, statuses, document numbers, source
        formats, dependency order, and error handling require customer-specific
        configuration and testing.
      - >-
        Diagnostic-first behavior and dry-run were verified for the
        accounts-receivable import specifically.
        data-import-ai/import-routings throws instead of collecting diagnostics,
        so this behavior must not be assumed across other record types.
      - >-
        The import runs no cross-document transaction. A failing document is
        recorded in insertErrors and leaves a partially loaded batch rather than
        rolling the migration back; the cleanup hook is the reset path.
      - >-
        Imported invoices and credit memos are tagged with
        suppressedJournalStages and post no journal entries, so this proof
        establishes nothing about general-ledger posting after cutover.
      - >-
        data-import-ai/import-in-progress-sales-orders bypasses audit-trail
        processing through skipEvent() and writes placeholder shipping and
        billing addresses that must be corrected after import. Whether the
        accounts-receivable import writes audit-trail entries was not
        established. This proof does not measure anything through target audit
        trails.
      - >-
        revisionsEnabled is false on both finance/invoice and sales/order, and
        dataReportMaxRows is 1000, so reconciliation above 1,000 report rows
        requires a separately configured retrieval path.
      - >-
        This proof does not measure attachment migration, incumbent audit or
        revision history, contractual export rights, extraction feasibility from
        the incumbent system, throughput or response time at production
        migration volume, implementation effort, cutover duration, downtime, or
        cost.
    transfer:
      level: prohibited
      from_vertical_ids: []
      conditions:
        - >-
          Use is limited to M1_V1, M1_V2, M1_V3, M1_V4, M1_V5, M1_V6, and M1_V7.
          Any future or otherwise unlisted vertical requires separately
          validated evidence and an explicit applicable canonical transfer rule.
    evidence_ids:
      - EV_MULTI_008
      - EV_PRODUCT_007

Outstanding

1. No measured value backs this proof. EV_MULTI_008 establishes that counts, control totals, relationship samples, and tolerances were reported as measured and accepted, not what any of them equalled. Obtain the values before making any quantified claim.
2. The manifest is a declared test input. Fix the record types, counts, control total, sample, and exclusions before execution; this proof does not supply them.
3. Seven-vertical applicability is reported collectively. Obtain per-vertical account counts before treating each listed vertical as separately observed.
4. Product coverage is partial. Only the sales-order and AR-invoice import hooks and the AR cleanup path were verified through MCP server d8189168.
5. status: approved does not close lifecycle review. Execution against a real buyer extract and evidence review remain required.