{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp06_four_proposal_generalization60_20260803","cell_id":"representation_independent_interface_contract__chemistry_materials","arm":"COMPLETE_PROPOSAL_PORTFOLIO","candidate_id":"thermophysical-property-surface-contract","proposal_index":2,"version":0,"title":"Representation-Independent Contract for Thermophysical Property Surfaces","problem":"A materials or process simulator consumes a released thermophysical property surface through its concrete encoding: polynomial coefficients, temperature-segment indexes, tabulation knots, interpolation objects, surrogate weights, or database columns. Client code may select segments, extrapolate, convert reference states, or calculate derivatives using assumptions about that encoding. Re-expressing the same assessed property surface in a table, spline, polynomial, or optimized evaluator can consequently alter boundary behavior, errors, derivatives, or client compatibility even though no scientific model change was intended.","actors":["Curators who release assessed thermophysical-property packages","Developers of materials and process simulators","Maintainers of property databases and evaluation libraries","Researchers interpreting simulation results produced from those properties","Safety or quality reviewers who distinguish model revisions from software substitutions"],"observable_state":"For the same released material-property model, changing coefficient layout, segment partitioning, interpolation storage, evaluation library, or cache strategy changes values at segment boundaries, unit-converted results, derivative queries, extrapolation behavior, error types, or solver acceptance. Some clients directly read coefficients or grid knots, and two evaluators advertising the same dataset disagree on unsupported phases, reference states, or out-of-domain requests.","consequence":"A representation-only change can require solver modifications or appear as a scientific revision; clients can silently extrapolate or apply inconsistent reference-state corrections; and investigators may be unable to attribute changed simulation output to the physical model, its encoded representation, or the evaluator.","affected_objective":"Allow a released thermophysical property model to be re-encoded or evaluated by different implementations while preserving its declared domain, physical reference state, observable values, error behavior, uncertainty metadata, and provenance.","intervention":"Define an immutable `ThermophysicalSurface` contract for one identified scientific-model release. Its abstract value is a set of named material properties as functions of declared state variables over explicit phase and validity domains, together with units, reference states, numerical acceptance tolerances, uncertainty metadata, and provenance. Public operations validate a release, report supported properties and domains, evaluate scalar or batch queries, request contractually supported derivatives, convert declared units, and return provenance. Stable typed errors cover out-of-domain states, ambiguous phases, unavailable properties, and unsupported derivatives; extrapolation is forbidden unless separately declared. Polynomial coefficients, knots, segment trees, interpolation algorithms, surrogate weights, caches, and database rows remain hidden. Every encoding must map to the same abstract surface and pass one black-box oracle covering values, boundaries, derivatives, units, batches, and errors before it is eligible to replace another implementation. A changed physical surface, validity domain, tolerance, reference state, or uncertainty statement is a new contract release rather than an internal substitution.","structural_mapping":[{"archetype_element":"Abstract component","domain_realization":"A versioned thermophysical surface defined by property functions, domains, phases, reference states, tolerances, uncertainty metadata, and provenance rather than by coefficients or table layout."},{"archetype_element":"Observable operation surface","domain_realization":"Domain and capability queries, scalar and batch property evaluation, supported derivatives, explicit unit conversion, validation, and provenance retrieval."},{"archetype_element":"Behavioral laws and invariants","domain_realization":"Scalar and singleton-batch agreement, batch-permutation consistency, declared unit-conversion equivalence, deterministic typed errors, complete coverage of declared domains, and any release-specific relations such as consistency between enthalpy and heat-capacity surfaces."},{"archetype_element":"Hidden representation","domain_realization":"Polynomial order, coefficient arrays, interval indexes, grid knots, spline basis, surrogate parameters, compression, caches, and database schema."},{"archetype_element":"Representation invariant and abstraction mapping","domain_realization":"Each concrete package must have valid units, nonoverlapping phase rules, covered domains, resolvable reference states, and a total mapping from every valid stored evaluator state to the declared abstract property surface within preregistered tolerances."},{"archetype_element":"Error and side-effect limits","domain_realization":"Unsupported or invalid queries return stable error categories without extrapolation, partial mutation, hidden file writes, or changes to the released surface."},{"archetype_element":"Conformance oracle and substitution rule","domain_realization":"One implementation-parameterized suite compares only public observations; passing is required for an offline substitution trial, while scientific-model changes cannot qualify as representation substitutions."},{"archetype_element":"Versioned stewardship","domain_realization":"The property-release steward approves observable contract changes, while conforming changes to storage and evaluation algorithms remain private to implementers."}],"mechanism_mapping":[{"mechanism_slug":"abstract_data_type_specification","role":"Model the released property functions and metadata independently of storage, then define executable validity predicates and semantic mappings for polynomial, tabular, spline, or surrogate representations.","counterfactual_removal":"Without an abstract surface and mappings from concrete encodings, agreement could only mean matching coefficient layouts rather than preserving the released property meaning."},{"mechanism_slug":"design_by_contract_clause","role":"Specify state-variable, phase, unit, and derivative preconditions; value, metadata, and no-mutation postconditions; and typed policies for invalid or unsupported queries.","counterfactual_removal":"Without operation-level clauses, implementations could share signatures while silently disagreeing about extrapolation, phase ambiguity, reference states, and derivative availability."},{"mechanism_slug":"interface_definition_language","role":"Publish a machine-readable operation and result schema from which simulator and evaluator bindings are generated, exposing property queries without exposing evaluator internals.","counterfactual_removal":"Without a compiled boundary, hand-written bindings could reintroduce coefficient fields, segment indexes, or implementation-specific result types into client code."},{"mechanism_slug":"opaque_type_or_module_boundary","role":"Expose an opaque surface handle and deliberate metadata operations while withholding coefficient arrays, knots, model objects, and mutable caches.","counterfactual_removal":"Without opacity, clients could continue selecting polynomial segments or calculating directly from hidden parameters, defeating substitutability despite a nominal interface."},{"mechanism_slug":"black_box_contract_test_suite","role":"Apply the same fixtures, boundary cases, derivative checks, unit conversions, and error assertions to every property-surface implementation using only public operations.","counterfactual_removal":"Without a reusable behavioral oracle, an evaluator could be described as compatible without evidence that its values, boundaries, and errors conform."},{"mechanism_slug":"metamorphic_behavior_test","role":"Check relations such as scalar-versus-batch agreement, batch permutation, reversible unit conversion, reference-state transformations explicitly permitted by the release, and release-specific property relations.","counterfactual_removal":"Without relational tests, the suite would depend mainly on sampled expected values and could miss systematic inconsistencies that appear across related queries."},{"mechanism_slug":"reference_implementation_differential_test","role":"Use a deliberately simple, independently coded evaluator of the released mathematical specification as an offline comparison oracle at sampled and boundary states.","counterfactual_removal":"Without an independent reference, exact corner behavior could be derived from the candidate implementation itself, allowing a shared encoding defect to define the expected answer."},{"mechanism_slug":"representation_leakage_probe","role":"Inspect generated bindings, metadata, errors, serialization, identifiers, ordering, and timing for unpromised clues about coefficient segments, knots, caches, or evaluator type.","counterfactual_removal":"Without leakage auditing, clients could infer and depend on the hidden evaluator representation even while all promised numerical checks pass."},{"mechanism_slug":"semantic_versioning_and_deprecation_gate","role":"Classify changes to domains, tolerances, properties, reference states, uncertainties, errors, and supported operations separately from private evaluator changes, with staged deprecation for public removals.","counterfactual_removal":"Without explicit evolution rules, a changed scientific surface or validity domain could be shipped as an internal optimization and mistaken for a compatible substitution."}],"causal_chain":["Simulation clients currently reach into coefficients, grids, segment rules, or evaluator-specific objects.","Those details determine how clients select domains, handle boundaries, convert references, and calculate derived quantities.","Re-encoding the same intended scientific release therefore changes client-visible behavior or forces coordinated client modifications.","An abstract property-surface contract moves domains, units, reference states, tolerances, errors, and supported operations onto the explicit behavioral surface.","Opaque generated bindings prevent ordinary clients from using evaluator internals.","Independent mappings connect different concrete encodings to the same declared property functions.","Black-box, metamorphic, and differential checks test those mappings at ordinary states, boundaries, transformed queries, and invalid inputs.","A representation can then change only when public behavior remains within the preregistered contract; a changed scientific model is recorded as a new release instead.","This separates evaluator substitution from scientific revision and provides a traceable basis for attributing changed simulation results."],"baseline":"The assumed comparison baseline is a simulator linked to a particular coefficient schema or evaluation library. Clients select polynomial intervals, read coefficient arrays or knots, perform their own unit and reference-state corrections, and use evaluator-specific exceptions. Regression tests cover selected numeric outputs but do not define one implementation-independent acceptance boundary. This is an inferred test setting, not a claim about prevalence.","nearest_rivals":["Mandate one polynomial or tabular encoding for all released properties. This reduces representation variety but makes that encoding, segmentation, and interpolation policy part of every client dependency.","Standardize a database schema containing coefficients and domains. This aligns stored fields but does not specify evaluation semantics, boundary behavior, derivatives, errors, or side effects.","Convert every release to one dense common grid. This creates a shared representation but introduces a chosen interpolation and resolution policy instead of governing multiple representations by observable behavior.","Pin the existing evaluator version and archive its inputs. This can reproduce the incumbent path but does not provide criteria for accepting an independently implemented evaluator.","Add pairwise regression tests between each property package and each simulator. This checks selected integrations but leaves no single abstract definition of a conforming property provider.","Expose raw coefficients plus provenance and require clients to interpret them correctly. This improves traceability while retaining the coupling and semantic duplication that cause representation-only changes to propagate."],"remaining_contrastive_claim":"Compared with a mandated coefficient format, common grid, or shared database schema, this intervention makes the released property surface and its query behavior the binding object. Its discriminating test is whether independently structured evaluators can satisfy the same domains, values, transformations, derivatives, errors, and metadata obligations without exposing or sharing coefficient layouts.","authority_safety":{"decision_authority":"The thermophysical-data release steward owns the scientific surface, domain, reference-state, tolerance, uncertainty, and provenance definitions. The evaluation-library owner may authorize a sandbox implementation, while each simulator owner retains authority over integration or production replacement. Safety-critical use additionally requires the existing domain review authority.","authorized_first_step":"Implement two offline evaluators for a preregistered synthetic single-phase property release and run them against copied test queries in an isolated harness; no production property package or simulation result may be altered.","excluded_actions":["Changing assessed property values, uncertainty statements, phase assignments, or reference states","Treating two different scientific models as substitutable merely because they share an interface","Enabling undeclared extrapolation or silently clamping out-of-domain states","Replacing a production evaluator or changing archived simulation inputs","Using sandbox outputs for process-control, safety, regulatory, or materials-selection decisions","Running synthesis, equipment control, or physical experiments","Deleting or rewriting incumbent property packages or provenance records"],"halt_rollback":"Stop if the abstract release cannot be stated without coefficient-specific concepts, if either evaluator loses provenance or uncertainty metadata, if tolerance rules conceal a directional discrepancy, if a declared relation fails, or if an out-of-domain request returns a plausible value rather than the required error. Discard the sandbox evaluators, retain the preregistered specification and divergence log, and continue using the unchanged incumbent path pending scientific review."},"negative_tests":{"strongest_counterevidence":"Evaluator disagreements may reflect genuinely different physical models, phase conventions, reference states, source assessments, or numerical accuracy requirements rather than dependence on representation. If those scientific differences cannot be held fixed, substitutability is neither the correct diagnosis nor an appropriate goal.","problem_falsifier":"The proposed problem is falsified in the bounded setting if dependency inspection finds that clients use only documented property queries and metadata, and replaying representation-only changes produces identical values, derivatives, errors, provenance, and client decisions within predeclared tolerances.","intervention_falsifier":"The intervention is falsified for the initial scope if a contract written before implementation comparison cannot distinguish scientific-model changes from encoding changes, if its tolerance relation yields inconsistent acceptance classifications, or if an independently coded evaluator violates a preregistered obligation while still passing the proposed oracle.","risks":["Numerical tolerances may mask systematic bias or make acceptance dependent on comparison order.","Tolerance-based agreement does not prove physical correctness.","Sparse sampling may miss narrow boundary, phase, or interpolation failures.","Derivative checks can amplify numerical noise or unintentionally prescribe an algorithm.","A trusted reference evaluator may reproduce an error in the mathematical specification.","Uncertainty covariance or provenance detail may be lost when reduced to simple public fields.","Over-specification can freeze rounding, call ordering, or interpolation behavior that clients do not need.","Under-specification can admit evaluators whose values agree at fixtures but diverge between them.","Generated bindings or debug exports may leak coefficient structure despite an opaque handle.","A semantically conforming evaluator may still have unacceptable latency, memory use, or numerical conditioning.","Users may mistake implementation substitutability for equivalence between distinct scientific models."]},"next_evidence_step":"Before coding either evaluator, preregister one synthetic, single-phase thermophysical release over a bounded temperature interval with analytic enthalpy and heat-capacity functions, explicit units, a reference state, typed out-of-domain behavior, and separate value and derivative tolerances. Implement an independent direct analytic evaluator and a table/spline-backed evaluator. Test 30 fixed points including every boundary, 500 seeded interior queries, scalar-versus-batch equivalence, batch permutation, reversible unit conversions, the declared enthalpy/heat-capacity relation, provenance preservation, and invalid requests. Add one deliberately corrupted evaluator to check that the suite rejects a known coefficient, domain, and error-policy defect. Record divergences without changing production software. This step tests whether the contract is executable and discriminating; it does not estimate operational benefit or scientific accuracy.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Proposal 1 addressed identity and invariant handling of ordered periodic crystal structures across coordinate, cell, atom-order, and file representations. This proposal instead addresses evaluation of a fixed thermophysical property surface across polynomial, tabular, spline, or surrogate implementations. Its intervention contracts functional queries, domains, reference states, derivatives, tolerances, and errors rather than material-structure equivalence; its causal path runs from coefficient-level client coupling through evaluator-independent behavioral conformance, not from equivalent crystal encodings through stable structure identity. It can be adopted by a property-library and simulator ecosystem without adopting or modifying Proposal 1's structure object.","revision_record":{"parent_version":null,"progress_targets_addressed":["Materially different problem from proposal 1","Distinct independently adoptable intervention and causal path","Complete mechanism, rival, authority, safeguard, falsifier, and evidence specification"],"conceptual_changes":["Initial version; defines a released thermophysical property surface as the abstract component while keeping scientific-model substitution explicitly out of scope."],"operational_changes":["Initial version; bounds first evidence to a synthetic single-phase release, two independent offline evaluators, seeded queries, and deliberately corrupted controls."],"evidence_changes":["Initial version; prior art remains unsearched and no prevalence, demand, novelty, or effect claim is made."],"claim_changes":["Initial version; limits the contrastive claim to evaluator representation-independence for one fixed scientific-model release."]}}