{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp06_four_proposal_generalization60_20260803","cell_id":"representation_independent_interface_contract__accounting_auditing","arm":"COMPLETE_PROPOSAL_PORTFOLIO","candidate_id":"cand_audit_evidence_capsule_contract_04","proposal_index":4,"version":0,"title":"Repository-Independent Custody Contract for Audit Evidence","problem":"During migration from a shared drive or audit-workpaper system to a document repository, evidentiary meaning can remain entangled with folder paths, filenames, mutable timestamps, vendor identifiers, permission settings, and repository-native activity logs. A copied document may look identical while losing its provenance, transformation history, legal hold, access restrictions, or relationship to the procedure it supports. Without a representation-independent definition of an evidence item, repository replacement is evaluated through storage-specific checklists rather than a reusable rule for preserved custody behavior.","actors":["Accounting process owner supplying evidence","Internal or external auditor consuming and evaluating evidence","Audit-methodology owner defining custody requirements","Records-management owner governing retention and disposition","Legal or compliance officer controlling holds where applicable","Data-security and privacy owner governing access","Repository administrator implementing storage adapters","Controller responsible for accounting-record stewardship"],"observable_state":"The same closed-workpaper artifact appears in an incumbent repository and a migration copy, but the systems expose different identifiers, timestamps, access logs, version structures, redaction mechanisms, and retention states. Existing workpaper links and review procedures refer directly to paths or vendor metadata. Reviewers can compare file contents, yet cannot determine from a shared behavioral specification whether provenance, integrity, authorized retrieval, derived-copy lineage, hold protection, and disposition eligibility were preserved.","consequence":"A repository change can break evidence references, permit silent replacement or unauthorized disclosure, detach a redacted or converted copy from its source, erase custody history, or make retained evidence appear disposable. Conversely, preserving every incumbent storage detail can prevent repository replacement even when evidentiary behavior could be maintained.","affected_objective":"Preserve the integrity, provenance, authorized retrievability, transformation lineage, custody history, and retention protection of audit evidence while allowing storage technology and internal metadata representation to change.","intervention":"Define an opaque, versioned Audit Evidence Capsule by behavior. Its abstract state contains an opaque capsule identity; an evidentiary payload identity; declared media type; provenance receipt naming the source, collection method, and capture event; immutable derivation links; access policy; append-only custody events; retention rule; hold state; and lifecycle of Captured, Sealed, Held, Archived, Eligible for Disposition, Disposed, and Superseded. Public operations capture a payload, attach provenance before sealing, retrieve the original payload under an authorization context, verify integrity, derive a converted or redacted child capsule, append a review annotation, place or release an authorized hold, query custody history, archive, evaluate disposition eligibility, dispose when independently authorized, and supersede a capsule without rewriting it. A sealed capsule’s payload and provenance cannot change; retrieval must reproduce the original payload bytes or a contractually identified derived payload; any conversion or redaction creates a child with a named transformation and parent link; every successful or denied retrieval appends a declared custody event; an active hold blocks disposition; disposition requires the retention condition, absence of a hold, and an authorized disposition instruction; and a disposed capsule retains a non-content tombstone sufficient to distinguish authorized disposition from loss. Typed failures cover missing provenance, failed integrity verification, unauthorized access, stale version, active hold, premature disposition, unsupported transformation, and unavailable payload. Failed operations reveal no payload and leave abstract content state unchanged. Storage paths, bucket names, database rows, compression, encryption layout, replica placement, vendor version identifiers, temporary files, and user-interface presentation remain hidden. Each repository implementation supplies an abstraction mapping from its valid records to capsules and must pass the same black-box lifecycle and custody oracle before substitution. The capsule contract does not replace inspection or certification of repository security controls when those are separately required.","structural_mapping":[{"archetype_element":"Abstract component and state model","domain_realization":"An Audit Evidence Capsule defined by payload identity, provenance, derivation links, access policy, custody events, retention and hold rules, and an explicit custody lifecycle."},{"archetype_element":"Observable operation surface","domain_realization":"Capture, provenance attachment, sealing, authorized retrieval, integrity verification, derivation, annotation, hold placement and release, history query, archival, eligibility evaluation, disposition, and supersession."},{"archetype_element":"Behavioral laws and invariants","domain_realization":"Sealed payload and provenance are immutable; retrieval preserves payload identity; transformations create linked children; custody events are append-only; active holds prevent disposition; and authorized disposition leaves a distinguishable tombstone."},{"archetype_element":"Hidden representation","domain_realization":"Paths, filenames, storage keys, database layout, compression, encryption structure, replicas, caches, vendor version objects, temporary files, and interface presentation are non-contractual."},{"archetype_element":"Abstraction function and representation invariant","domain_realization":"Each repository maps its valid concrete records to exactly defined capsules, and the mapping is valid only when payload identity, provenance, lineage, access, custody, retention, and hold invariants are satisfied."},{"archetype_element":"Error semantics and side-effect limits","domain_realization":"Typed failures govern access, integrity, provenance, transformation, version, hold, and disposition errors; retrieval may append a declared custody event but cannot mutate evidentiary content."},{"archetype_element":"Conformance and substitutability rule","domain_realization":"A repository adapter becomes eligible for substitution only after the shared black-box and generated-sequence oracle verifies the same capsule behavior for the same contract version."},{"archetype_element":"Sanctioned introspection and stewardship","domain_realization":"Authorized consumers may retrieve original content, provenance, derivation, and custody history through named operations, while records, legal, security, and audit authorities retain their separate decision rights."}],"mechanism_mapping":[{"mechanism_slug":"abstract_data_type_specification","role":"Defines evidence custody as abstract capsule values, lifecycle transitions, invariants, and a semantic mapping from each repository’s records to those values.","counterfactual_removal":"Without the abstract model and mapping, migration could establish that files were copied without establishing that provenance, holds, lineage, access behavior, and disposition state retained the same meaning."},{"mechanism_slug":"design_by_contract_clause","role":"Specifies authorization preconditions, content-preserving postconditions, and unchanged-state failure behavior for sealing, retrieval, derivation, holds, archival, and disposition.","counterfactual_removal":"Without per-operation clauses, repositories could handle unauthorized reads, missing provenance, transformation, or active holds differently while claiming equivalent custody."},{"mechanism_slug":"interface_definition_language","role":"Declares repository-neutral capsule operations, opaque identifiers, authorization context, result types, and typed errors so adapters and consumers compile against the published boundary.","counterfactual_removal":"Without a machine-readable surface, hand-built integrations could expose vendor identifiers or omit lifecycle errors, allowing representation details to re-enter consumer dependencies."},{"mechanism_slug":"opaque_type_or_module_boundary","role":"Withholds storage keys and mutable repository records while granting named operations for evidence content, provenance, lineage, and custody inspection.","counterfactual_removal":"Without enforced opacity, workpapers and procedures could continue embedding paths, bucket keys, or vendor version identifiers, making repository replacement disruptive."},{"mechanism_slug":"black_box_contract_test_suite","role":"Runs one reusable custody battery against an in-memory model and each repository adapter using only public capsule operations.","counterfactual_removal":"Without a shared oracle, substitution would depend on repository-specific migration checklists that cannot provide a common behavioral acceptance rule."},{"mechanism_slug":"property_based_conformance_test","role":"Generates authorization contexts, payloads, derivations, holds, releases, version conflicts, and lifecycle sequences to test immutability, lineage, access, and disposition invariants.","counterfactual_removal":"Without generated sequences, example tests could miss paths such as repeated holds, stale releases, derivation after archival, or disposition following a failed integrity check."},{"mechanism_slug":"mock_fake_or_stub_implementation","role":"Provides a small independent capsule model that can inject corruption, access denial, missing provenance, stale versions, and premature disposition without touching real evidence.","counterfactual_removal":"Without an independent controllable implementation, rare failure semantics might remain untested or be defined solely by incumbent repository behavior."},{"mechanism_slug":"representation_leakage_probe","role":"Examines paths, signed links, error text, timestamps, ordering, token contents, vendor metadata, and timing for useful but unpromised repository signals.","counterfactual_removal":"Without leakage probing, consumers could convert storage artifacts into an unofficial interface even though the formal capsule type remained opaque."},{"mechanism_slug":"semantic_versioning_and_deprecation_gate","role":"Governs changes to payload identity, provenance requirements, custody observations, hold behavior, retention evaluation, disposition rules, and typed errors.","counterfactual_removal":"Without version governance, custody semantics could change in place and invalidate earlier conformance evidence or consumer interpretations."}],"causal_chain":["Evidence consumers currently identify and interpret retained artifacts partly through repository-specific paths, metadata, permissions, and lifecycle behavior.","The intervention defines an evidence item through payload identity, provenance, derivation, access, custody, hold, retention, and disposition laws rather than storage layout.","Opaque identifiers and generated interfaces prevent new consumer dependencies on repository internals while preserving sanctioned evidence inspection operations.","Each repository adapter maps concrete records to the same abstract capsule and must preserve immutability, lineage, authorization, and lifecycle invariants.","The shared black-box and property-based oracle exercises normal and adversarial custody sequences, including corruption, denied access, transformations, holds, stale versions, and disposition attempts.","Only an adapter conforming to the same capsule version becomes eligible for repository substitution; leakage audits and version gates govern observable and intentional changes.","If the contract is sufficiently discriminating, evidence can move between storage implementations without treating either a matching file copy or preserved vendor metadata as sufficient proof of custody equivalence."],"baseline":"Copy repository contents and folder structures, preserve filenames where possible, compare file counts and checksums, export vendor activity logs, repair broken links, and manually reconcile permission and retention differences using a migration checklist.","nearest_rivals":["Mandate a standard folder and filename convention. This stabilizes a physical organization but does not define immutable provenance, derivation, authorization, hold, or disposition behavior.","Use checksums and file-count reconciliation during migration. These test content transfer and aggregate completeness but do not establish access semantics, custody history, lineage, or retention protection.","Adopt one approved document-management platform as the permanent evidence repository. This may centralize controls but makes vendor objects and lifecycle behavior load-bearing and supplies no representation-independent replacement rule.","Export each engagement as a static evidence binder. This preserves a view of selected content but can discard native payloads, authorization behavior, transformation lineage, and custody events.","Use a repository-specific migration certification checklist. This can govern one transition but does not create a reusable behavioral oracle applicable to independently represented repositories."],"remaining_contrastive_claim":"Relative to these rivals, the testable contrast is whether defining audit evidence as a capsule with representation-independent integrity, provenance, derivation, access, custody, hold, retention, error, and disposition behavior permits storage substitution without preserving repository paths or vendor metadata. This is a bounded design hypothesis, not a novelty or effect claim.","authority_safety":{"decision_authority":"Records management, data security, and the audit-methodology owner may jointly approve the capsule semantics and a synthetic offline pilot. Only the legally or organizationally designated authority may place or release a binding hold or authorize disposition. Repository owners control deployment, and external auditors independently determine evidentiary sufficiency and whether repository controls require separate inspection.","authorized_first_step":"Implement an in-memory model and a second non-production adapter over fabricated evidence objects. Run predeclared lifecycle and failure scenarios without accessing, moving, relinking, modifying, retaining, or deleting production accounting or audit evidence.","excluded_actions":["Moving, renaming, replacing, redacting, or deleting production evidence","Changing production permissions, retention periods, disposition eligibility, or legal holds","Using real confidential evidence without separate access authorization","Deploying the capsule as a production repository or migration gate","Treating conformance as evidence sufficiency, legal admissibility, security certification, or audit approval","Weakening authorization, provenance, integrity, or hold requirements to make an adapter pass","Using opacity to deny an authorized auditor, legal officer, or security reviewer required underlying-system inspection"],"halt_rollback":"Stop the pilot on any access-control bypass, payload mismatch, unlinked transformation, mutable sealed state, lost custody event, unauthorized hold transition, actual deletion attempt, or evidence that a required custody property cannot be represented independently of repository internals. Preserve only synthetic discrepancy records, revoke test credentials, and remove fabricated test objects under the test protocol; production repositories remain unchanged."},"negative_tests":{"strongest_counterevidence":"The strongest counterevidence would be that evidentiary reliance or legal retention requires repository-native controls, logs, signatures, or certified storage properties that cannot be reduced to observable capsule behavior, making white-box repository qualification—not behavioral substitution—the necessary boundary.","problem_falsifier":"The problem is falsified if a dependency inventory and controlled repository swap show that workpaper references, retrieval, provenance, transformations, access review, holds, retention, and disposition already depend only on documented repository-independent semantics and migrate without vendor-specific mappings or ambiguous custody decisions.","intervention_falsifier":"The intervention is falsified if two independently implemented repositories pass every predeclared capsule test for the same contract version yet differ materially in payload authenticity, authorized availability, derivation lineage, hold protection, custody history, or disposition eligibility; it is also falsified if closing the gap necessarily exposes a specific repository’s internal representation as contractual.","risks":["An incorrect abstraction could give false confidence that evidentiary custody was preserved.","A valid payload checksum does not establish truthful provenance or reliable source controls.","The independent model and adapters could share an erroneous interpretation of retention or authorization rules.","Opaque storage could hinder assurance if sanctioned provenance and custody views are incomplete.","Access logs and provenance receipts may themselves contain confidential or personal information.","A tombstone might reveal sensitive metadata or retain too little information to distinguish disposal from loss.","Over-specified timestamps, identifiers, or event order could freeze incidental repository behavior.","Under-specified canonicalization could make integrity comparisons ambiguous for converted documents.","A conforming adapter could rely on insecure infrastructure outside the black-box contract.","Automated disposition operations create irreversible risk and require authority beyond conformance testing."]},"next_evidence_step":"Predeclare a synthetic fixture matrix covering two different payloads with the same filename, identical payloads in different storage layouts, missing provenance, corruption after sealing, unauthorized retrieval, repeated retrieval logging, redaction and format-conversion derivations, attempted parent mutation, nested holds, unauthorized hold release, stale-version operations, premature disposition, authorized synthetic disposition, tombstone retrieval, and supersession. Implement the contract as an in-memory model and as a structurally different non-production adapter, run the identical black-box and generated-sequence suite, and confirm the suite rejects a deliberately broken fake that mutates sealed content or ignores holds. Have one records reviewer, one security reviewer, and one audit-methodology reviewer classify each observable repository detail as contractual, sanctioned introspection, or leakage. Stop after the fabricated-data evaluation; passing authorizes no production migration or disposition.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Proposal 1 addressed substitutable journal-entry populations for audit procedures. Its abstract object was a scoped set of postings, and its causal path centered on exact-once membership, completeness, control-total reconciliation, and lineage across extraction providers. This proposal instead governs custody of individual evidentiary artifacts across repositories; it does not select, enumerate, or reconcile journal populations and can be adopted without changing any journal extractor. Proposal 2 addressed an account-reconciliation control case. Its central behavior involved accounting equations, preparer-reviewer separation, evidence gates, certification, reopening, and approval history. This proposal does not decide whether an account is reconciled or govern close approval; it protects payload integrity, provenance, authorized retrieval, derivation, holds, retention, and disposition. It can store evidence for many purposes without adopting Proposal 2, while Proposal 2 can retain its existing repository. Proposal 3 addressed cost-allocation calculation engines. Its causal path transformed pools and drivers into recipient amounts using conservation, eligibility, rounding, differential results, and metamorphic calculation laws. This proposal performs no accounting allocation or numerical transformation; derived evidence copies preserve explicit parentage rather than calculate financial outputs. It is independently adoptable as a repository boundary while any incumbent allocation engine remains unchanged. The four proposals therefore concern different abstract objects—a journal population, reconciliation case, allocation plan, and evidence capsule—and rely on different invariants, actors, interventions, hazards, and acceptance evidence.","revision_record":{"parent_version":null,"progress_targets_addressed":["Materially distinct problem from all three sealed proposals","Independently adoptable custody intervention","Representation-independent state, operations, invariants, error semantics, and side-effect limits","Explicit abstraction mapping and reusable conformance oracle","Mechanism-specific counterfactual removals","Baseline, rivals, authority separation, safeguards, and falsifiers","Bounded synthetic first-evidence step","Explicit diversity from proposals 1, 2, and 3"],"conceptual_changes":["Initial version defines an audit evidence item by custody behavior rather than repository location or vendor metadata.","Separates behavioral capsule conformance from evidence sufficiency, legal authority, and white-box repository-control assurance."],"operational_changes":["Initial version limits testing to fabricated payloads and non-production adapters.","Excludes production migration, permission changes, holds, retention changes, and disposition while adding explicit halt conditions."],"evidence_changes":["Prior art remains unsearched.","First evidence is limited to synthetic lifecycle scenarios and a deliberately broken fake used to test oracle discrimination."],"claim_changes":["Makes no claim of novelty, prevalence, demand, or effect size.","Limits the claim to whether the capsule oracle can discriminate repository substitutions that preserve custody behavior without preserving storage representation."]}}