{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp06_four_proposal_generalization60_20260803","cell_id":"representation_independent_interface_contract__religious_studies_theology","arm":"COMPLETE_PROPOSAL_PORTFOLIO","candidate_id":"ric-authority-scoped-observance-resolver-002","proposal_index":2,"version":0,"title":"Authority-Scoped Contract for Religious Observance Calendars","problem":"Comparative-religion projects, publishers, chaplaincy planners, and teaching tools obtain observance dates from calendar engines or maintained schedules whose outputs are entangled with hidden lookup tables, precedence rules, astronomical calculations, day-boundary conventions, and authority assumptions. Consumers consequently depend on vendor-specific identifiers, unexplained ordering, or the current engine’s treatment of disputed dates. Replacing or updating an engine can silently change observance dates, ranks, labels, or conflict resolution even though the nominal query surface remains unchanged. Because religious calendars can differ legitimately by community, jurisdiction, lineage, or rule-set edition, a universal date table is not an adequate substitute for an explicit behavioral contract.","actors":["Religious-studies researchers maintaining comparative timelines","Publishers and educators consuming observance schedules","Chaplaincy or interfaith-program staff using calendars for planning","Tradition-specific calendar custodians or authorized subject-matter reviewers","Software and data stewards maintaining calendar implementations"],"observable_state":"Two calendar implementations receive the same authority profile, rule-set edition, location and time basis, and date interval but return different observance dates, labels, ranks, or ambiguity states. One output may silently select among disputed dates, treat a civil-midnight boundary as universal, merge observances recognized by distinct authorities, expose internal precedence numbers as meaningful ranks, or change historical answers after a rule-table update. Consumers cannot determine whether the differences are legitimate profile distinctions, implementation defects, or accidental representation leakage.","consequence":"Calendar substitutions and rule updates can alter research timelines, publications, teaching materials, or planning outputs without an auditable semantic change. Maintainers either freeze one engine’s internal machinery or require consumers to inspect and accommodate each implementation separately.","affected_objective":"Provide reproducible, authority-scoped observance results while permitting calculation algorithms, rule storage, precedence graphs, caches, and calendar libraries to be replaced.","intervention":"Define a versioned abstract component called an Authority-Scoped Observance Resolver. Its public operations configure an explicitly named authority profile and rule-set edition; resolve observances for a bounded civil or ritual-date interval; retrieve an observance by stable scoped identifier; expose the applicable day-boundary convention and result provenance; report conflicts, unsupported ranges, and underdetermination; and reproduce a result under an archived contract version. Specify state transitions from draft profile to reviewed, published, superseded, or withdrawn profile. Require invariants that results never lose their authority scope or rule-set edition, distinct authority profiles are not silently merged, underdetermination is returned rather than guessed, superseding a profile does not mutate archived results, and internal precedence codes or computation order do not become public rank unless deliberately contracted. Hide lookup tables, formulas, precedence graph structure, caches, library choices, and calculation sequence. Test independently implemented resolvers against identical black-box examples and representation-independent laws before accepting substitution within a bounded pilot.","structural_mapping":[{"archetype_element":"Abstract behavioral surface","domain_realization":"Operations for selecting an authority profile, resolving an interval, retrieving scoped observances, reporting provenance or ambiguity, and reproducing versioned results."},{"archetype_element":"Hidden representation","domain_realization":"Astronomical or arithmetic algorithms, lookup tables, precedence graphs, internal identifiers, caches, calendar libraries, and evaluation order remain non-contractual."},{"archetype_element":"Abstract state and transitions","domain_realization":"An authority-scoped rule set moves through draft, reviewed, published, superseded, and withdrawn states without retroactively mutating results attached to an earlier published version."},{"archetype_element":"Behavioral laws and invariants","domain_realization":"Authority scope and rule-set edition persist through every operation; unresolved conflicts remain explicit; distinct profiles are not collapsed; archived versions reproduce their declared outputs; incidental computation order carries no semantic meaning."},{"archetype_element":"Conformance oracle","domain_realization":"Permission-cleared date fixtures, boundary cases, and metamorphic interval queries exercise only public inputs, results, errors, provenance, and version behavior across implementations."},{"archetype_element":"Substitutability rule","domain_realization":"A resolver is eligible for the pilot only if it passes the same contract suite for the declared profiles and supported date range; passage does not authorize it as a religious authority or certify profiles outside that scope."},{"archetype_element":"Version and leakage governance","domain_realization":"Behavioral changes require a reviewed contract or profile version, while leakage audits identify accidental dependencies on internal IDs, ordering, timing, raw precedence values, and error wording."}],"mechanism_mapping":[{"mechanism_slug":"abstract_data_type_specification","role":"Models a resolver as an authority-scoped, versioned mapping from declared temporal inputs to sets of observance results, conflicts, or supported errors; representation invariants and an abstraction function connect each concrete engine state to that meaning.","counterfactual_removal":"Without the abstract value, invariant, and semantic mapping, equivalence would be judged by matching tables or algorithms rather than by authority-scoped calendrical behavior."},{"mechanism_slug":"design_by_contract_clause","role":"Defines each operation’s required authority profile, version, temporal frame, and supported range; promises scoped outputs or enumerated errors; and requires rejected requests to leave published profile state unchanged.","counterfactual_removal":"Without preconditions, postconditions, and error policy, engines can make different silent assumptions about location, day boundaries, unsupported years, or disputed observances."},{"mechanism_slug":"opaque_type_or_module_boundary","role":"Provides profile and result handles through sanctioned operations while preventing consumers from reading or mutating raw rule tables, precedence graphs, cache entries, or library-specific date objects.","counterfactual_removal":"Without opacity, consumers can continue treating a particular graph, row layout, or precedence number as the calendar’s real contract."},{"mechanism_slug":"black_box_contract_test_suite","role":"Runs one set of contract-derived date, boundary, ambiguity, version, and error checks against each candidate resolver using only public operations.","counterfactual_removal":"Without the shared black-box suite, maintainers cannot distinguish a substitutable implementation from one that merely agrees on familiar dates."},{"mechanism_slug":"metamorphic_behavior_test","role":"Checks laws such as resolving a supported interval in partitions yielding the same scoped observance set as resolving it whole, query order not changing results, and repeated resolution under an immutable published version remaining stable.","counterfactual_removal":"Without relational tests, conformance would depend entirely on hand-listed expected dates and could miss stateful, partition-boundary, or ordering defects."},{"mechanism_slug":"representation_leakage_probe","role":"Audits results for unpromised internal identifiers, list order, raw precedence weights, intermediate astronomical values, timing differences, and error wording that consumers could mistake for religiously meaningful behavior.","counterfactual_removal":"Without leakage probing, a nominally opaque resolver may still export implementation details that become unofficial calendrical promises."},{"mechanism_slug":"semantic_versioning_and_deprecation_gate","role":"Classifies changes to operations, result semantics, authority profiles, supported ranges, and ambiguity policy; preserves old versions for reproducibility and stages removals through explicit deprecation.","counterfactual_removal":"Without governed versions, a rule-table or engine update can retroactively alter cited results while retaining the same apparent interface."}],"causal_chain":["Consumers currently rely on outputs whose authority assumptions, temporal conventions, and internal calculation artifacts are incompletely separated.","The abstract contract makes authority profile, rule-set edition, operations, result states, errors, and invariants explicit while excluding algorithms and storage structures.","Opaque access and leakage audits prevent clients from binding themselves to lookup rows, precedence numbers, library objects, or computation order.","Independent resolvers map their concrete states to the same abstract behavior and face the same fixtures and metamorphic laws.","Divergences become classifiable as implementation defects, underspecified contract clauses, profile disagreements requiring authorized review, or intentionally distinct authority scopes.","Version governance prevents reviewed changes from silently rewriting previously cited outputs.","A conforming resolver can replace another within the tested profile and date bounds while consumer workflows continue to depend only on the declared calendrical behavior."],"baseline":"For one permission-cleared authority profile and a bounded date range, execute a predeclared set of interval, boundary, ambiguity, retrieval, and version-reproduction queries against the incumbent calendar source. Record outputs and every consumer dependency on raw table fields, internal IDs, list order, precedence values, unstated day boundaries, or manual exceptions. Separately record which results are explicitly authorized, disputed, unsupported, or merely inherited from current implementation behavior.","nearest_rivals":["Maintain a single universal interfaith date spreadsheet.","Standardize a shared calendar file format while leaving authority, ambiguity, and update semantics unspecified.","Require every consumer to use one designated calendar vendor or library.","Publish separate static schedules for each tradition and reconcile discrepancies manually.","Expose the full calculation rules and require downstream consumers to reproduce each calendar internally.","Ask subject-matter experts to review selected dates after every engine update without a reusable conformance oracle."],"remaining_contrastive_claim":"The proposal does not standardize religious calendars into one ontology, mandate a shared storage format, or declare one calculation universally correct. Its contrastive claim is that a resolver can be defined and substituted by authority-scoped observable behavior—including ambiguity, provenance, temporal conventions, errors, and version persistence—while its algorithms and rule representation remain replaceable.","authority_safety":{"decision_authority":"Tradition-specific calendar custodians or appropriately authorized subject-matter reviewers determine the content and scope of each profile. The archive, publisher, or institutional data steward may authorize a technical pilot. The contract team may formalize and test behavior but may not confer religious authority, resolve doctrinal disputes, or designate a profile as universally normative.","authorized_first_step":"Create a read-only pilot profile from one permission-cleared maintained schedule, define its supported date range and temporal conventions with its authorized reviewer, and implement fixtures against an isolated incumbent adapter and a simple independent resolver.","excluded_actions":["Publishing a pilot profile as an official religious calendar","Merging authority profiles to produce a purportedly universal answer","Silently choosing one date when the authorized source records disagreement or underdetermination","Changing live worship, accommodation, publication, or chaplaincy schedules during the pilot","Scraping or redistributing restricted rule materials","Treating contract-suite passage as authorization by a religious community","Removing access for authorized experts who need to inspect internal calculations for review"],"halt_rollback":"Stop if a profile’s authorized reviewer disputes its scope, a test exposes restricted material, a resolver loses authority or version provenance, an ambiguity is converted into an asserted date, or archived results change under an unchanged version. Disconnect the pilot from consumers, discard derivative public outputs, preserve the incumbent source unchanged, and return disputed clauses to the authorized reviewer."},"negative_tests":{"strongest_counterevidence":"Consumers legitimately require the internal derivation procedure—not merely its observable result—for scholarly interpretation or religious authorization, or independently implemented resolvers pass the suite while authorized reviewers judge their outputs materially non-equivalent within the declared scope.","problem_falsifier":"The baseline finds that all relevant consumers already use explicit authority profiles, versions, temporal conventions, ambiguity states, and stable public behavior, and that replacing the internal engine produces no observable divergence or representation-specific dependency within the bounded tasks.","intervention_falsifier":"A second resolver cannot satisfy the contract without copying the incumbent’s internal representation, or contract-conforming outputs repeatedly fail the predeclared review criteria because the abstract surface omits distinctions that authorized reviewers consider indispensable.","risks":["Formalization may disguise contested authority choices as neutral technical parameters.","Fixtures may freeze an incumbent error into the contract.","A limited date range may miss rare cycles, reforms, or boundary cases.","Consumers may mistake a technically conforming profile for an official religious determination.","Opaque internals may impede legitimate methodological audit unless a sanctioned inspection path is retained.","Version proliferation may confuse consumers if profile identity and deprecation messages are unclear.","Metamorphic laws may be invalid for profiles with explicitly stateful or publication-dependent rules unless carefully scoped."]},"next_evidence_step":"Predeclare 15 queries covering ordinary dates, interval partitions, day-boundary cases, disputed or underdetermined results, unsupported ranges, profile supersession, and archived-version reproduction. Apply them to an incumbent adapter and an independently structured simple resolver for one reviewed profile and a bounded two-year interval. Run leakage checks and metamorphic relations, then have the authorized calendar reviewer classify every divergence without seeing implementation internals. Evidence is limited to whether the proposed surface can distinguish defects, underspecification, and authorized profile differences in this pilot.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Compared with proposal 1, this proposal addresses prospective calendrical resolution rather than preservation and querying of archival ritual evidence. Its abstract object is a versioned authority-scoped rule resolver, not a source-linked ritual record; its primary failure is silent behavioral change during calculation or rule updates, not loss of provenance or emic/etic distinctions during repository substitution. Its intervention introduces explicit temporal conventions, ambiguity outputs, immutable rule-set versions, and resolver conformance, whereas proposal 1 constructs an evidence-record contract around archival assertions and access-preserving transformations. Its causal path runs from hidden calendrical assumptions to explicit authority-scoped resolution and reproducible substitution, not from schema-dependent evidence coding to representation-independent archival retrieval. Either proposal can be adopted without the other, and neither supplies a component required by the other.","revision_record":{"parent_version":null,"progress_targets_addressed":[],"conceptual_changes":[],"operational_changes":[],"evidence_changes":[],"claim_changes":[]}}