{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp06_four_proposal_generalization60_20260803","cell_id":"representation_independent_interface_contract__environmental_climate","arm":"COMPLETE_PROPOSAL_PORTFOLIO","candidate_id":"p04-drought-stage-determination-contract","proposal_index":4,"version":0,"title":"Representation-Independent Contract for Drought-Stage Recommendations","problem":"A watershed drought plan may operationalize its response stages through one spreadsheet, dashboard, indicator vendor, or rules-engine implementation. Operators can begin depending on cell locations, dashboard colors, raw score scales, evaluation order, undocumented rounding, missing-value defaults, or model-specific reason labels instead of a complete behavioral definition of stage determination. Replacing the implementation can then change when a stage is recommended even though the approved policy and abstract evidence are intended to remain unchanged.","actors":["Hydrologists who define admissible evidence quantities","Drought-program analysts who run assessment cycles","Water-utility and watershed staff who consume stage recommendations","Software and data teams who maintain calculation implementations","Drought-program lead who stewards the behavioral contract","Watershed board or other designated body that authorizes official stages","Legal, equity, and public-communication reviewers who assess policy consequences","Independent reviewers who audit recommendation reproducibility"],"observable_state":"For a bounded assessment workflow, inventory whether clients read spreadsheet cells, dashboard colors, proprietary score fields, evaluation traces, or undocumented rounding behavior. Express one frozen evidence packet in contract-level quantities and replay it, boundary-value variants, missing-data cases, corrected-input cases, and sequential assessments through two implementations. The problem is observable if they disagree on recommendation stage, effective assessment time, evidence-sufficiency state, pending-transition state, stable reason category, or error outcome—or if a client cannot consume the second implementation without learning its internal formula or display representation.","consequence":"A software migration, indicator-provider change, formula refactor, or evaluation-order change can produce an escalation, de-escalation, or indeterminate result for representational reasons rather than because hydrologic evidence or approved policy changed. Decision-makers may be unable to reconstruct why a recommendation changed, and downstream procedures can become tied to a particular dashboard or calculation artifact.","affected_objective":"Keep drought-stage recommendations reproducible and auditable across implementation changes while preserving the designated authority's control over official declarations and policy revisions.","intervention":"Create an opaque Drought Stage Recommender whose abstract state consists of current recommended stage, assessment timestamp, evidence-sufficiency status, pending escalation or de-escalation condition, applicable policy and parameter versions, and stable reason categories. Public operations are: initialize under a named policy version; assess a typed evidence snapshot; advance with a later snapshot; invalidate an assessment whose inputs were withdrawn; query the current recommendation and contracted reasons; and export a reproducible assessment receipt. Preconditions require declared units, time windows, geographic support, source eligibility, freshness, and coverage for each required evidence quantity. Postconditions require a valid stage or explicit INDETERMINATE result, deterministic evaluation for the same abstract state and evidence, application of declared hysteresis and persistence rules, no silent substitution for missing evidence, stable reason categories, and an immutable receipt containing input identities and contract versions. Invalid or temporally inconsistent calls return stable errors and do not change recommender state. Spreadsheet layout, formula order, database schema, indicator-provider fields, cache strategy, user-interface colors, and internal rule representation are non-contractual. A shared black-box oracle tests boundary cases, generated assessment sequences, missingness, corrections, hysteresis, receipts, and observable leakage. A replacement may run in shadow and become eligible only if it conforms to the same policy and parameter versions. The recommender issues no restriction, allocation, emergency declaration, or public message; the authorized body retains those decisions.","structural_mapping":[{"archetype_element":"Clients needing stable component behavior","domain_realization":"Water agencies and drought-program staff require a reproducible recommendation without depending on a particular spreadsheet, dashboard, or rules engine."},{"archetype_element":"Representation-independent operation surface","domain_realization":"Initialize, assess, advance, invalidate, query, and export-receipt operations define the public recommender."},{"archetype_element":"Abstract state model","domain_realization":"Recommendation stage, evidence sufficiency, pending transition, assessment time, reason categories, and policy versions describe the component independently of its formulas or storage."},{"archetype_element":"Hidden representation","domain_realization":"Cell layout, formula evaluation order, proprietary indicator fields, rule-tree structure, database schema, caching, and display colors are non-contractual."},{"archetype_element":"Behavioral laws and invariants","domain_realization":"Only declared stages are returned, identical abstract histories are deterministic, hysteresis follows the approved state-transition rules, receipts are immutable, and missing required evidence cannot silently become a normal stage."},{"archetype_element":"Error and side-effect limits","domain_realization":"Malformed, stale, incomplete, or temporally inconsistent inputs produce stable error or indeterminate outcomes without changing state, issuing restrictions, or sending public notifications."},{"archetype_element":"Abstraction function","domain_realization":"Each valid spreadsheet, rules-engine, or service state maps to the same public stage, sufficiency, transition, time, reason, and version state."},{"archetype_element":"Conformance oracle","domain_realization":"One black-box suite exercises policy examples, boundaries, missingness, assessment histories, invalidation, receipts, and leakage against every implementation."},{"archetype_element":"Substitutability rule","domain_realization":"Implementations are substitutable only when they conform under identical policy and parameter versions; a policy change is not an implementation substitution."},{"archetype_element":"Stewardship and versioning","domain_realization":"The drought-program lead stewards the technical contract, while the designated decision body authorizes policy changes and official drought stages."}],"mechanism_mapping":[{"mechanism_slug":"abstract_data_type_specification","role":"Defines the recommender through abstract stage and transition state, representation invariants, and mappings from spreadsheet, decision-table, or rules-engine states to the same public meaning.","counterfactual_removal":"Without the abstract state and mapping, implementations could expose similarly named outputs while differing on pending transitions, sufficiency, invalidation, or assessment history."},{"mechanism_slug":"design_by_contract_clause","role":"Specifies caller obligations for units, coverage, freshness, time order, and source eligibility and component obligations for stages, indeterminate results, hysteresis, receipts, and state-preserving errors.","counterfactual_removal":"Without operation-level clauses, missing data, late corrections, stale snapshots, and broken preconditions could be handled differently by each implementation."},{"mechanism_slug":"interface_definition_language","role":"Declares typed evidence quantities, stage and sufficiency enums, assessment operations, opaque state handles, receipts, reasons, and error categories separately from every dashboard and calculation engine.","counterfactual_removal":"Without a compiled surface, clients could continue importing vendor-specific score fields or spreadsheet structures despite a prose behavioral contract."},{"mechanism_slug":"opaque_type_or_module_boundary","role":"Prevents ordinary clients from reading formula cells, proprietary rule objects, caches, or internal transition counters and requires them to use contracted stages, reasons, and receipts.","counterfactual_removal":"Without opacity, undocumented calculations and display artifacts could remain load-bearing dependencies and make later substitution unsafe."},{"mechanism_slug":"black_box_contract_test_suite","role":"Provides a reusable acceptance battery for boundary evidence, normal assessments, missingness, corrections, hysteresis, invalidation, receipts, and stable errors.","counterfactual_removal":"Without a common oracle, a replacement could be accepted because familiar examples look right while important state sequences and edge cases diverge."},{"mechanism_slug":"property_based_conformance_test","role":"Generates valid and invalid evidence histories to test legal stage transitions, persistence rules, determinism, receipt consistency, state preservation after errors, and explicit handling of insufficient evidence.","counterfactual_removal":"Without generated histories, defects caused by unusual sequences of escalation, partial recovery, correction, invalidation, and reassessment could remain untested."},{"mechanism_slug":"metamorphic_behavior_test","role":"Checks contract-derived relations such as invariance to equivalent unit encodings, irrelevant input ordering, repeated assessment of an identical snapshot, and renaming of non-semantic source fields.","counterfactual_removal":"Without relational tests, representation-independence would be asserted without directly testing whether harmless encoding changes leave the abstract recommendation unchanged."},{"mechanism_slug":"reference_implementation_differential_test","role":"Uses a deliberately simple decision-table implementation of the approved contract to compare observable recommendations, reasons, transitions, and receipts with a candidate engine on shared inputs.","counterfactual_removal":"Without an independent reference, exact boundary and hysteresis disagreements would be harder to detect, though every divergence must still be resolved against the approved contract rather than presumed to indict the candidate."},{"mechanism_slug":"representation_leakage_probe","role":"Examines ordering, raw scores, reason text, receipt contents, timing, identifiers, and user-interface signals for useful but unpromised implementation details.","counterfactual_removal":"Without leakage probing, clients could couple to dashboard colors, proprietary scales, evaluation traces, or decodable receipt internals even while promised behaviors passed."},{"mechanism_slug":"semantic_versioning_and_deprecation_gate","role":"Separates compatible implementation changes from breaking changes to evidence meaning, thresholds, hysteresis, stage semantics, reasons, or missing-data policy and inventories affected consumers.","counterfactual_removal":"Without version governance, an approved policy change could masquerade as a software update, or an implementation refactor could silently reinterpret historical receipts."},{"mechanism_slug":"substitutability_trial_or_canary","role":"Runs a candidate recommender in non-authoritative shadow mode beside the incumbent for preselected assessment packets and compares semantic outputs against thresholds fixed before the trial.","counterfactual_removal":"Without a reversible shadow trial, offline cases would not test the actual input packaging, call ordering, and downstream receipt consumption used by the assessment workflow."}],"causal_chain":["The approved drought policy is embodied incompletely in a particular spreadsheet, dashboard, or calculation engine.","Operators and downstream procedures depend on observable implementation details such as cell positions, raw scores, colors, rounding, and evaluation order.","A refactor or provider replacement changes one of those details while nominal stage names and policy intent remain unchanged.","The calculation then produces a different stage, transition timing, sufficiency outcome, or reason, or forces coordinated changes in every client.","The intervention extracts the policy-facing recommender into abstract state, public operations, transition laws, errors, reasons, receipts, and side-effect limits.","Opaque access and a shared oracle prevent clients and replacement implementations from treating accidental representation as policy.","Conforming engines can then substitute under the same approved policy version, while a genuine threshold, hysteresis, or evidence-rule change must proceed as an explicit policy-version change under the proper authority."],"baseline":"Continue using the incumbent spreadsheet or dashboard as both calculator and informal specification, preserve familiar cells and colors during changes, manually compare selected assessment reports, and have analysts explain discrepancies case by case. This baseline retains tacit knowledge but does not distinguish approved policy behavior from implementation accidents.","nearest_rivals":["Standardize permanently on one drought index, spreadsheet, or dashboard; this avoids immediate translation but makes its representation and failure behavior the continuing dependency.","Publish the formulas and permit every client to implement them; this improves transparency but creates multiple drifting implementations without one stateful conformance gate.","Standardize only the input-data schema; this aligns field names and units but does not specify hysteresis, missingness, errors, invalidation, reasons, or assessment transitions.","Use a human committee without a formal recommender; human judgment may be appropriate for official decisions but does not make the repeatable calculation component substitutable or testable.","Compare new and old recommendations manually for several past periods; this supplies examples but not a reusable oracle for boundaries, generated histories, or future representation changes.","Require white-box validation of every engine; this can inspect scientific and policy correctness but does not itself prevent clients from depending on internal representation."],"remaining_contrastive_claim":"The proposal's contrast is a stateful, policy-versioned behavioral contract for recommendation transitions, insufficiency, errors, and receipts, enforced by one representation-independent oracle. It is not merely an input standard, transparent formula publication, dashboard redesign, or delegation of official drought authority to software.","authority_safety":{"decision_authority":"The drought-program lead may authorize a sandbox specification and shadow comparison. Hydrologists and policy owners must approve the interpretation of evidence quantities and transition rules. Only the watershed board or other already-designated authority may declare an official drought stage, impose restrictions, allocate water, or approve a policy-version change.","authorized_first_step":"Using one authorized, non-live assessment packet, inventory implementation-specific dependencies, draft the abstract state and operation contract from the currently approved policy, and compare an incumbent adapter with a simple independent decision-table implementation on frozen and synthetic cases. All outputs must be labeled non-authoritative.","excluded_actions":["Issuing or changing an official drought declaration","Triggering water restrictions, allocation changes, emergency procedures, or public notifications","Changing approved thresholds, persistence rules, indicator eligibility, or missing-data policy","Connecting the prototype to automatic operational controls","Using confidential or live evidence without data-owner approval","Treating software conformance as validation of hydrologic indicators or drought policy","Adjusting expected outputs or tolerances after examining candidate results","Replacing the incumbent calculation workflow based solely on the bounded first test"],"halt_rollback":"Stop if a prototype output is mistaken for an official recommendation, the draft cannot distinguish approved policy from incumbent implementation behavior, protected evidence is exposed, the sandbox sends a notification or control signal, or an implementation changes state after a rejected call. Disable shadow outputs, restore the frozen incumbent workflow, retain only authorized test cases and discrepancy records, and refer policy ambiguities to the designated authority without resolving them in code."},"negative_tests":{"strongest_counterevidence":"The selected drought program may already maintain an implementation-independent, versioned transition specification with explicit missingness, errors, reasons, and receipts, while clients consume only that surface and independently implemented engines agree across boundary and sequence tests. That would undermine the inferred problem for the selected workflow.","problem_falsifier":"The problem is falsified for the bounded case if the dependency inventory finds no reliance on spreadsheet, dashboard, provider, rounding, ordering, or display details and a second independent implementation can replace the calculation engine without client changes or divergence in contracted outputs.","intervention_falsifier":"The intervention fails if two implementations pass the complete draft suite yet disagree on a contracted recommendation, sufficiency state, transition, reason, or receipt for an in-scope history, or if expressing the approved policy requires exposing the incumbent representation so completely that meaningful substitution is impossible.","risks":["The contract may formalize an unintended spreadsheet behavior as approved policy.","A finite suite may miss a boundary or history that produces a decision-relevant divergence.","Behavioral equivalence does not establish that indicators, thresholds, or drought policy are scientifically or legally appropriate.","Opacity may conceal distributional or procedural consequences unless policy review remains separate and transparent.","Stable reason categories may omit nuance that human decision-makers require.","Generated cases may fail to cover correlated missingness or unusual evidence revisions.","A shadow comparison may encourage automation beyond the recommender's authorized advisory role.","Version proliferation may make historical receipts difficult to interpret if governance records are incomplete."]},"next_evidence_step":"Select one completed assessment packet and one approved policy version. Before running either implementation, record the contract-level evidence quantities, stage set, sufficiency rules, transition and persistence laws, error categories, reason categories, receipt fields, and expected outcomes for ordinary and boundary cases. Build an adapter around the incumbent calculator and a separate decision-table reference, then replay the frozen packet plus generated sequences covering threshold boundaries, equivalent units, reordered inputs, missing evidence, stale evidence, repeated snapshots, escalation persistence, de-escalation persistence, invalidation, and correction. Classify every discrepancy as an implementation dependency, contract omission, policy ambiguity, adapter defect, or evidence against the inferred problem. Produce no operational recommendation and send no output outside the authorized review group.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Proposal 1 addressed a wetland monitoring evidence ledger: its problem was client dependence on record storage, revision, quality-control, and aggregation representations, and its intervention governed observation lineage and as-of queries. Proposal 2 addressed a snowpack simulation component: its problem was host-model reach-through into numerical layers and solvers, and its intervention governed thermodynamic timestep transitions, conservation, fluxes, and checkpoints. Proposal 3 addressed physical stormwater buffer units: its problem was construction-prescriptive procurement and incomplete hydraulic ratings, and its intervention governed inlet, outlet, recovery, fault, and maintenance behavior of physical infrastructure. Proposal 4 instead addresses an advisory governance calculation that converts already-approved evidence quantities into a versioned drought-stage recommendation history. Its causal path runs from policy being incompletely embodied in spreadsheet or dashboard behavior, through downstream dependence on those artifacts, to unintended recommendation changes during calculator replacement. It stores neither monitoring evidence, simulates no environmental process, and substitutes no physical asset. It can be adopted independently by a drought-governance program without implementing any earlier proposal.","revision_record":{"parent_version":null,"progress_targets_addressed":["Generated a fourth complete proposal materially distinct from proposals 1, 2, and 3.","Preserved the archetype through an opaque, stateful, versioned recommendation component with a shared conformance oracle."],"conceptual_changes":["Initial version; no parent revision.","Applied representation independence to a policy-facing drought-stage state machine rather than an evidence store, physical-process solver, or infrastructure unit."],"operational_changes":["Specified a non-authoritative sandbox, an incumbent adapter, an independent decision-table reference, generated assessment histories, and a shadow-only substitution gate."],"evidence_changes":["Defined observable implementation dependencies, boundary and sequence comparisons, strongest counterevidence, and separate problem and intervention falsifiers."],"claim_changes":["Restricted substitutability to implementations of the same approved policy and parameter versions.","Explicitly retained official decision authority outside the component and made no novelty, prevalence, demand, policy-validity, or effect-size claim."]}}