{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","cell_id":"formal_derivation_system_design__accounting_auditing","arm":"BREADTH_PROBE_ONE_SHOT","candidate_id":"formal_derivation_system_design__accounting_auditing__P1","proposal_index":1,"version":0,"title":"Proof-Carrying Intercompany Elimination Kernel","problem":"During consolidation, subsidiary ledgers encode intercompany sales, purchases, receivables, payables, profit, and settlement events differently. Accountants therefore infer required eliminations from policy prose, account mappings, spreadsheet formulas, and experience. A transaction pair may be matched correctly yet still receive inconsistent elimination treatment because the accepted facts, valid record combinations, and rules connecting those facts to elimination entries are implicit.","actors":["Subsidiary controllers who submit ledger records and counterparty identifiers","Group consolidation accountants who determine and post elimination entries","Accounting-policy owners who interpret the reporting framework","Internal auditors who test consolidation controls","External auditors who evaluate evidence supporting consolidated balances","Consolidation-system owners who maintain mappings and calculation logic"],"observable_state":"For the same class of linked intercompany transactions, different preparers or periods produce different elimination entries; spreadsheet cells or system code provide no rule-level explanation; unmatched or partially matched records are resolved through undocumented assumptions; and reviewers cannot reconstruct whether an elimination follows from submitted facts, an external accounting judgment, or a manual exception.","consequence":"Intra-group amounts or unrealized profit can remain in consolidated balances, valid external amounts can be over-eliminated, and the close and audit can be delayed by repeated reconstruction of undocumented reasoning.","affected_objective":"Produce accurate, reproducible, and reviewable consolidated financial statements while preserving clear responsibility for accounting judgments.","intervention":"Create a versioned, bounded formal kernel that accepts normalized intercompany facts and derives proposed elimination obligations and entries. Define a symbol vocabulary for entities, transaction identities, accounts, amounts, currencies, dates, ownership relations, inventory disposition, and settlement states; reject records that violate an explicit grammar; separate accepted ledger facts, policy assumptions, and external judgments; encode inference rules for permitted elimination transformations; and emit a machine-checkable derivation trace or an explicit non-derivable status for every proposed treatment. Route ambiguous facts and reporting-framework interpretations outside the kernel to authorized accountants, then record any approved external input through a controlled gateway.","structural_mapping":[{"archetype_element":"Symbol Vocabulary","domain_realization":"Typed symbols for reporting entities, counterparties, transaction IDs, account classes, amounts, currencies, dates, ownership links, inventory states, and elimination-entry components."},{"archetype_element":"Well-Formed Expression Grammar","domain_realization":"Rules specifying valid transaction facts and elimination expressions, including required entity pairing, currency and period tags, balanced entry legs, and stable transaction identity."},{"archetype_element":"Axiom Base","domain_realization":"Versioned accepted premises such as group membership, submitted ledger facts, approved account classifications, and explicitly authorized policy assumptions."},{"archetype_element":"Inference Rule Set","domain_realization":"Rules deriving elimination obligations and balanced proposed entries from well-formed premises, such as deriving reciprocal-balance elimination only when entity, counterparty, period, account-class, and transaction-link predicates are satisfied."},{"archetype_element":"Derivation Trace Record","domain_realization":"A proof tree linking each proposed elimination entry to source records, accepted premises, rule identifiers, exceptions, and kernel version."},{"archetype_element":"Closure Boundary","domain_realization":"The kernel can determine derivability under declared inputs but cannot determine disputed transaction substance, authoritative accounting interpretation, fraud, or whether submitted facts reflect reality."},{"archetype_element":"Consistency Guardrail","domain_realization":"Checks for contradictory entity relationships, incompatible transaction states, duplicate source identities, unbalanced derived entries, and mutually inconsistent elimination conclusions."},{"archetype_element":"Interpretation Boundary","domain_realization":"Accounting-policy owners decide disputed classifications and reporting-framework interpretations; the formal kernel records those decisions as external premises rather than silently inferring them."},{"archetype_element":"Revision and Versioning Rule","domain_realization":"Every axiom or inference-rule change creates a new kernel version and reruns exemplar and historical derivations to expose changed conclusions."},{"archetype_element":"External Fact Gateway","domain_realization":"A controlled interface admits approved evidence such as inventory disposition or ownership status, with provenance, approver, effective period, and expiration or review condition."}],"mechanism_mapping":[{"mechanism_slug":"formal_grammar_specification","role":"Defines which submitted transaction facts and proposed elimination expressions are syntactically admissible before accounting derivation begins.","counterfactual_removal":"Without it, malformed, incomplete, or ambiguously typed records enter the rule process and apparent derivations can depend on accidental field interpretation."},{"mechanism_slug":"inference_rule_calculus","role":"Expresses each licensed transformation from accepted transaction premises to an elimination obligation or proposed entry.","counterfactual_removal":"Without it, conclusions remain embedded in spreadsheet formulas, code branches, or reviewer intuition rather than following from inspectable rules."},{"mechanism_slug":"proof_tree_or_derivation_log","role":"Carries source facts, intermediate conclusions, rule applications, external inputs, and system version with every result.","counterfactual_removal":"Without it, a proposed entry may be reproducible computationally but cannot be reconstructed or challenged at the level of accounting reasoning."},{"mechanism_slug":"mechanical_proof_checker","role":"Verifies that every step uses well-formed premises and an authorized rule and that the resulting entry satisfies balancing and consistency conditions.","counterfactual_removal":"Without it, the formal specification becomes documentation only, leaving implementation drift and illicit transformations undetected."},{"mechanism_slug":"formal_system_change_control_workflow","role":"Versions rule changes and tests their effects on known derivations, non-derivations, and exception cases.","counterfactual_removal":"Without it, a policy or software change can silently alter prior treatment and obscure which rule set supported a period's consolidation."}],"causal_chain":["Subsidiaries submit intercompany records whose fields are normalized into declared symbols.","The well-formedness linter rejects or quarantines records that do not satisfy the transaction grammar.","Accepted ledger facts, approved assumptions, and externally supplied judgments enter distinct premise classes.","The inference-rule calculus applies only licensed transformations to those premises.","The proof checker verifies each derivation, consistency condition, and balanced proposed entry.","The system emits either a proof-carrying elimination proposal, a contradiction, or a non-derivable/out-of-scope result.","Authorized accountants review proposals and resolve routed cases without converting their judgments into hidden rules.","Versioned traces let preparers and auditors reproduce the basis of each accepted elimination and detect consequences of later rule changes."],"baseline":"A consolidation accountant matches counterparty balances, consults policy documents, copies or modifies prior-period spreadsheet formulas, investigates residual differences, and records reviewer sign-off. The files may preserve source references and approvals but usually do not distinguish grammar, premises, inference rules, external judgments, and derivation boundaries in a mechanically checkable form.","nearest_rivals":["Intercompany transaction matching: links reciprocal records and flags differences but does not itself derive whether a particular elimination treatment follows from explicit accounting premises and inference rules.","Reconciliation and exception workflow: routes mismatches for resolution but can accept a resolution without a formal trace showing which rules license the resulting entry.","Spreadsheet control and formula review: tests calculations and approvals inside a workbook but leaves the workbook's formulas and conventions as the implicit rule system.","Rule-based consolidation software: automates mappings and entries but is a rival only if its independent specification, accepted premises, inference rules, version boundary, and per-entry derivations are not explicit.","Audit checklist or decision tree: prompts consistent review of known cases but ordinarily records answers rather than a machine-checkable derivation from typed premises."],"remaining_contrastive_claim":"The intervention's distinguishing testable feature is not automation or transaction matching; it is that every proposed elimination must be generated as a valid derivation from separately declared, well-formed premises through named rules under a named system version, while unresolved interpretation is returned as non-derivable or routed through an external fact gateway.","authority_safety":{"decision_authority":"Group management retains authority for accounting policies, classifications, consolidation entries, and financial statements; qualified accounting personnel approve all entries, while external auditors retain independent authority over audit procedures and conclusions.","authorized_first_step":"Run a read-only shadow derivation on a bounded historical sample and compare its outputs and traces with already approved eliminations; the kernel may flag cases but may not post entries or change the historical record.","excluded_actions":["Automatically posting, reversing, or approving journal entries","Treating derivability as proof that source facts are true or that treatment complies with every applicable requirement","Resolving disputed transaction substance, ownership, fraud indicators, or accounting interpretations without authorized review","Replacing management review, internal controls, or independent audit judgment","Changing axioms or inference rules without versioning, impact tests, and named approval"],"halt_rollback":"Halt the pilot if it produces unbalanced entries, merges distinct source identities, applies rules outside the declared sample, or presents out-of-scope cases as definitive. Disable its output from the review workflow, preserve logs for diagnosis, and return to the unchanged approved consolidation process; no ledger rollback is required because the pilot is read-only."},"negative_tests":{"strongest_counterevidence":"Historical disagreements may arise mainly from missing or false source data and genuinely judgment-dependent accounting questions; if explicit rules cannot resolve cases without repeatedly importing expert conclusions, formal derivation is not the operative remedy.","problem_falsifier":"In a blinded replay, qualified preparers using the current process produce the same treatment and reconstruct the same basis for nearly all sampled transactions, with explicit source assumptions and no material dependence on hidden formulas or undocumented inference moves.","intervention_falsifier":"Given agreed normalized premises, the kernel cannot reproduce accepted exemplar treatments, cannot distinguish non-derivable cases from false conclusions, or requires case-specific rules that merely encode each desired answer.","risks":["A formally valid derivation may confer false confidence when ledger facts, entity links, or external judgments are wrong.","Rule authors may embed contested accounting interpretations as neutral axioms.","Exceptions may accumulate until the rule kernel becomes opaque or non-terminating.","Normalization may collapse economically distinct transactions into the same symbolic form.","Rule changes may alter prior-period conclusions unless versions and effective dates remain attached.","Preparers may defer excessively to machine-checked outputs, weakening substantive review.","Detailed traces may expose sensitive transaction information beyond appropriate access boundaries."]},"next_evidence_step":"Select one closed historical consolidation period, one pair of group entities, and at most 30 intercompany inventory transactions spanning exact matches, timing differences, partial settlement, and unrealized-profit cases. With two consolidation accountants, define a draft vocabulary, grammar, premise classes, and no more than ten inference rules; encode five approved exemplar derivations and five expected non-derivations; then conduct a read-only blinded replay. Record well-formedness failures, contradictions, proof-check failures, differences from approved entries, rule-specific explanations, and cases requiring external judgment. Stop after this sample and use the observations only to decide whether a larger controlled evaluation is warranted.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Not assessed; this is an isolated one-shot proposal generated solely from the supplied archetype record and domain card.","revision_record":{"parent_version":null,"progress_targets_addressed":[],"conceptual_changes":[],"operational_changes":[],"evidence_changes":[],"claim_changes":[]}}