{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","research_id":"eoa_inverse_innovation_exp09_light_prior_art_20260804","cell_id":"representation_independent_interface_contract__accounting_auditing","search_lanes":{"direct_problem_and_intervention":{"queries":["three-way match ERP migration black-box conformance testing behavioral equivalence","accounts payable three-way match migration control testing edge cases tolerance duplicate invoice"],"source_ids":["SRC1","SRC2","SRC3"],"no_result_note":null},"synonyms_and_historical_terms":{"queries":["invoice matching system replacement parallel testing automated application controls audit","application control baseline benchmarking system migration invoice matching"],"source_ids":["SRC2","SRC3"],"no_result_note":null},"products_practices_and_standards":{"queries":["Oracle Payables three-way match tolerance documentation","SAP Concur purchase order matching rules testing audit trail","PCAOB AS 2201 automated application control benchmarking"],"source_ids":["SRC1","SRC2","SRC3"],"no_result_note":null},"component_combination":{"queries":["stateful model based testing ERP invoice matching","property based testing three way match accounts payable","black box conformance executable behavioral contract stateful API testing primary research"],"source_ids":["SRC2","SRC4"],"no_result_note":"No retained source described the full domain-specific combination of a versioned representation-independent state contract, one legacy/replacement sequence oracle, leakage probes, and a mandatory substitution rule for a three-way-match control."}},"sources":[{"source_id":"SRC1","title":"Match Approval Level Options","publisher":"Oracle","url":"https://docs.oracle.com/en/cloud/saas/procurement/25d/oapro/match-approval-level-options.html","source_type":"FIRST_PARTY_PRODUCT","claims_supported":["Oracle defines three-way matching as requiring purchase-order, receipt, and invoice quantities to agree within tolerance before payment.","The payment decision therefore depends on configured matching semantics rather than merely accepting the same three document types."]},{"source_id":"SRC2","title":"Purchase Order Matching Rules (New Experience)","publisher":"SAP","url":"https://help.sap.com/docs/CONCUR_INVOICE/5d4d01ab28704a4fbfa543f20b66966c/6c8fb80f969d446d88d994c0ed3444cb.html?locale=en-US","source_type":"FIRST_PARTY_PRODUCT","claims_supported":["SAP Concur supports condition-based matching rules, multiple rule groups, two-way and three-way variants, exchange-rate handling, controlled testing, and identification of the applied rule set in the audit trail.","This is domain-close practice for testing matching configurations and retaining observable evidence, but it remains organized around product-specific rule sets."]},{"source_id":"SRC3","title":"AS 2201: An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements","publisher":"Public Company Accounting Oversight Board","url":"https://pcaobus.org/oversight/standards/auditing-standards/details/AS2201","source_type":"OFFICIAL_STANDARD","claims_supported":["Auditors test control design and operating effectiveness and must obtain evidence appropriate to control risk.","AS 2201 recognizes benchmarking of automated application controls but ties it to unchanged controls, effective program-change, access, and operations controls, and dependencies on files, tables, data, and parameters.","New controls must achieve the relevant objectives and operate long enough to support design and operating-effectiveness testing; a sandbox conformance result cannot itself determine audit reliance."]},{"source_id":"SRC4","title":"Systematic API Testing Through Model Checking and Executable Contracts","publisher":"arXiv","url":"https://arxiv.org/abs/2604.08633","source_type":"PRIMARY_RESEARCH","claims_supported":["IcePick models API state evolution and generates stateful test sequences from a behavioral model.","Glacier adds executable semantic contracts for automated black-box behavioral verification beyond interface schemas and status codes.","The evaluated technique supplies strong component-level precedent for stateful executable-contract testing, although it is not directed to accounts-payable controls or legacy-to-replacement audit qualification."]}],"problem_evidence":{"status":"PARTLY_SUPPORTED","finding":"The retained product sources make the underlying behavioral complexity visible: three-way matching depends on tolerances, condition-based rule groups, exchange-rate behavior, testing status, and audit-trail identification. AS 2201 confirms that changes to automated controls require evidence over design and operating effectiveness and that application behavior can depend on parameters and supporting IT controls. The exact asserted pattern—migrations being accepted on ordinary examples while undocumented legacy edge behavior is missed—was not directly documented by a retained source.","source_ids":["SRC1","SRC2","SRC3"]},"closest_prior_art":[{"name":"SAP Concur purchase-order matching rule testing","source_ids":["SRC2"],"overlap":"Provides product-supported two-way and three-way rule groups, conditional variance reactions, exchange-rate behavior, a testing phase, copying of tested rule sets, and audit-trail visibility.","remaining_difference":"Testing and acceptance remain expressed through SAP-specific rules and administration; the source does not define a representation-independent state machine or require one oracle to qualify both a legacy and replacement implementation."},{"name":"PCAOB automated-application-control benchmarking","source_ids":["SRC3"],"overlap":"Establishes a baseline for an automated control, evaluates whether it has changed, considers dependencies on parameters and IT general controls, and requires renewed evidence when appropriate.","remaining_difference":"It benchmarks continuing operation of a defined control rather than declaring two materially different implementations substitutable through a shared behavioral contract; it also preserves broader auditor judgment and IT-control testing."},{"name":"IcePick and Glacier stateful executable-contract testing","source_ids":["SRC4"],"overlap":"Uses an abstract state-evolution model, generated multi-operation sequences, executable semantic contracts, and black-box behavioral verification—the proposal's central technical testing mechanisms.","remaining_difference":"It tests generic APIs, not three-way-match financial controls, and does not address legacy leakage, audit evidence, posting side effects, control ownership, contract versioning, or a migration substitution decision."},{"name":"Oracle three-way-match approval semantics","source_ids":["SRC1"],"overlap":"Defines a payment-relevant observable rule in which purchase order, receipt, and invoice quantities must match within tolerance.","remaining_difference":"It documents one product's behavior rather than a portable contract, comparative oracle, or implementation-substitution procedure."}],"prior_art_disposition":"ADJACENT_PRIOR_ART","contrastive_claim_remaining":"For a declared transaction and currency envelope, a replacement three-way-match control should be accepted as behaviorally substitutable only when both legacy and replacement satisfy the same versioned, implementation-neutral event/state contract covering decisions, transitions, reasons, audit events, idempotence, errors, overrides, and forbidden posting side effects. Product-configuration similarity and sampled reconciliations are neither necessary nor sufficient. The retained art separately supplies domain rule testing, automated-control baselining, and stateful executable-contract testing, but not this combined domain-specific substitution rule.","contrastive_claim_falsifier":"The claim is falsified by an established standard, published implementation method, or product practice that already requires a versioned implementation-independent stateful contract and the same sequence-based black-box oracle to qualify legacy and replacement three-way-match controls, or by a bounded trial in which both systems pass the frozen contract suite yet one violates a mandatory invariant inside the declared envelope.","gates":{"adequate_source_search":{"status":"PASS","rationale":"The bounded search covered direct proposal language, migration and automated-control terminology, official Oracle and SAP product practices, the applicable PCAOB control-testing standard, and generic stateful executable-contract research. Exactly four opened sources from four publishers were retained, including two first-party sources, an official standard, and primary research.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"supported_problem":{"status":"PASS","rationale":"Product documentation demonstrates consequential behavioral variability in matching rules, tolerances, currencies, testing, and audit trails, while AS 2201 establishes the need for evidence when automated controls change. Evidence for undocumented legacy dependencies specifically is indirect, so the problem is only partly supported.","source_ids":["SRC1","SRC2","SRC3"]},"distinct_testable_claim":{"status":"PASS","rationale":"The remaining claim has a discriminating acceptance rule: freeze a representation-independent behavioral contract and require both implementations to pass the same stateful oracle. It can be refuted by close domain prior art or an in-envelope invariant failure after suite passage.","source_ids":["SRC2","SRC3","SRC4"]},"bounded_next_test":{"status":"PASS","rationale":"The proposed 24-sequence synthetic, non-posting sandbox test is finite, freezes expected outcomes before execution, compares both interfaces, and yields a mismatch and leakage log without authorizing production use. The retained sources support testing matching rules, obtaining control evidence, and exercising stateful contracts.","source_ids":["SRC2","SRC3","SRC4"]},"no_obvious_safety_or_authority_stop":{"status":"PASS","rationale":"The authorized step is isolated, synthetic, read-only, and non-posting. Controller and control-owner authority, deployment authority, and independent auditor judgment remain separate. AS 2201 also makes clear that application-control evidence does not eliminate dependencies on access, program-change, operations, data, and parameter controls.","source_ids":["SRC3"]}},"screen_survival":true,"world_novelty_boundary":"This bounded public-web screen found adjacent product-specific matching tests, automated-control benchmarking, and generic stateful executable-contract testing, but no close match to the complete proposed combination. It cannot establish world novelty, patentability, market size, expert acceptance, or realized value; patents, proprietary ERP implementation playbooks, non-indexed audit methods, and additional academic or standards literature may contain closer prior art."}