{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp06_four_proposal_generalization60_20260803","cell_id":"representation_independent_interface_contract__human_computer_interaction","arm":"COMPLETE_PROPOSAL_PORTFOLIO","candidate_id":"semantic_design_concern_anchor_contract","proposal_index":3,"version":0,"title":"Semantic Anchors for Design Critiques That Survive Prototype Change","problem":"Interaction-design critiques are commonly attached to screen coordinates, prototype frames, layer identifiers, or DOM nodes. When a design moves from sketch to interactive prototype to coded interface—or when an element is moved, split, merged, or reimplemented—the attachment may disappear or silently point to the wrong element. Reviewers then cannot reliably determine whether an accessibility, usability, or interaction concern remains applicable, was addressed, or became unresolvable.","actors":["Interaction designers","Usability researchers","Accessibility reviewers","Product managers and design critics","Prototype and frontend engineers","Design-operations repository owner"],"observable_state":"Given successive representations of the same interaction, each recorded concern has a lifecycle state and a target-resolution result: uniquely resolved, ambiguously resolved, intentionally superseded, or unresolved. The problem is observable when an active concern disappears, follows a reused layer identifier to an unrelated element, is marked addressed solely because its original node vanished, or requires its author to reconstruct the target from screenshots and prose.","consequence":"Unresolved interaction concerns can be lost or misapplied, reviewers repeat prior analysis, and teams cannot distinguish an intentionally addressed issue from a broken attachment. Preserving comments by retaining old layer structures also constrains how prototypes and production interfaces may be reorganized.","affected_objective":"Preserve the identity, applicability, and explicit lifecycle of design concerns across changing interface representations without freezing prototype structure or allowing automatic anchor resolution to masquerade as human resolution of the concern.","intervention":"Introduce an opaque Design Concern Anchor component defined by behavior rather than by coordinate or layer storage. Its abstract value contains a concern identity, semantic target description, applicability condition, lifecycle state, representation bindings, and resolution status. A target describes the interaction role and condition under critique—for example, the control that commits a purchase while confirmation is pending—rather than a particular rectangle or node. Public operations create a concern, bind a representation target, resolve a target in a revision, report ambiguity, rebind with recorded authority, mark addressed with rationale, reopen, supersede, and query history. Resolver implementations may use component lineage, task-role tags, structural matching, coordinate hints, or manual mappings internally, but they must return the same contract-level statuses and may never silently choose among multiple plausible targets. Shared black-box tests and generated revision sequences govern whether a resolver or storage implementation is substitutable.","structural_mapping":[{"archetype_element":"Abstract behavioral surface","domain_realization":"Operations for creating, binding, resolving, rebinding, addressing, reopening, superseding, and inspecting a design concern, together with defined lifecycle and target-resolution results."},{"archetype_element":"Hidden representation","domain_realization":"Prototype frame IDs, layer paths, DOM nodes, component-instance keys, coordinates, resolver indexes, matching algorithms, and storage layout."},{"archetype_element":"Abstract state model","domain_realization":"A concern identity paired with semantic target, applicability condition, lifecycle status, zero or more revision bindings, provenance, and one resolution status per queried representation."},{"archetype_element":"Behavioral laws and invariants","domain_realization":"Concern identity persists across rebinding; disappearance of a concrete node does not mark a concern addressed; ambiguous resolution is never reported as unique; only an authorized operation changes lifecycle status; and every rebind, supersession, or resolution decision retains provenance."},{"archetype_element":"Error and side-effect semantics","domain_realization":"Invalid lifecycle transitions, unauthorized rebinding, unknown revisions, and non-unique targets return declared errors without changing the concern or discarding its previous binding."},{"archetype_element":"Abstraction mapping","domain_realization":"Each resolver maps concrete artifact references and matching evidence to the contract-level result uniquely resolved, ambiguous, unresolved, or superseded, without exposing its internal matching representation to clients."},{"archetype_element":"Conformance oracle","domain_realization":"One implementation-parameterized suite applies artifact transformations and concern operations, then checks abstract identity, status, provenance, lifecycle, and error behavior."},{"archetype_element":"Substitutability rule","domain_realization":"A new resolver or repository implementation is accepted only if it preserves concern histories and contract-level resolution outcomes, rejects forbidden transitions, and does not require clients to interpret raw prototype identifiers."},{"archetype_element":"Leakage control","domain_realization":"An audit detects client queries, exports, or tests that rely on coordinate stability, layer naming, traversal order, exact confidence scores, or other undeclared resolver details."}],"mechanism_mapping":[{"mechanism_slug":"abstract_data_type_specification","role":"Defines the concern, semantic target, lifecycle, binding history, and resolution statuses independently of prototype storage, with an abstraction mapping from each resolver's concrete records.","counterfactual_removal":"Without the abstract value and mapping, preserving a database row or layer reference could be mistaken for preserving the identity and applicability of the concern."},{"mechanism_slug":"design_by_contract_clause","role":"Specifies preconditions and postconditions for rebinding, addressing, reopening, superseding, and resolving, including authority requirements and unchanged-state behavior on failure.","counterfactual_removal":"Without operation-level clauses, implementations could disagree about whether node deletion closes a concern, whether ambiguous matches may be selected, or whether failed rebinding mutates history."},{"mechanism_slug":"opaque_type_or_module_boundary","role":"Exposes concern handles and semantic operations while preventing review tools from editing raw bindings, resolver indexes, or lifecycle fields directly.","counterfactual_removal":"Without opacity, clients could restore convenient coordinate or node dependencies and bypass provenance and ambiguity rules."},{"mechanism_slug":"black_box_contract_test_suite","role":"Runs the same revision and lifecycle scenarios against coordinate-assisted, lineage-based, tag-based, and manual resolver implementations using only public operations.","counterfactual_removal":"Without a shared oracle, multiple resolvers could claim compatibility while differing on ambiguity, node deletion, history preservation, or authorization failures."},{"mechanism_slug":"property_based_conformance_test","role":"Generates sequences of moves, renames, splits, merges, deletions, reintroductions, rebindings, and lifecycle changes to test identity and provenance invariants.","counterfactual_removal":"Without generated sequences, the oracle could cover ordinary edits yet miss history corruption or silent misbinding after unusual combinations of revisions."},{"mechanism_slug":"representation_leakage_probe","role":"Identifies public outputs and client dependencies that reveal layer paths, coordinates, resolver ordering, or exact internal scores not promised by the contract.","counterfactual_removal":"Without the probe, review clients could turn convenient resolver artifacts into an unofficial interface that prevents implementation replacement."},{"mechanism_slug":"abstraction_barrier_code_review","role":"Requires reviewers to classify every requested field or resolver behavior as semantic contract, sanctioned diagnostic access, or prohibited dependence on artifact representation.","counterfactual_removal":"Without intent-sensitive review, technically observable matching details could be promoted into permanent client expectations without a deliberate contract decision."},{"mechanism_slug":"semantic_versioning_and_deprecation_gate","role":"Governs changes to lifecycle meanings, resolution statuses, semantic-target vocabulary, and export behavior while allowing internal matching algorithms to change without a public version change when conformance is preserved.","counterfactual_removal":"Without version governance, a resolver update could silently redefine ambiguous, addressed, or superseded and make existing histories change meaning."}],"causal_chain":["Current critique attachments identify targets through transient properties of a particular design representation.","The abstract concern model separates concern identity and applicability from coordinates, frames, layers, or DOM nodes.","Opaque operations force design tools to request binding and resolution behavior instead of treating raw artifact references as authoritative.","Explicit ambiguity and lifecycle laws prevent node disappearance or uncertain matching from silently closing or relocating a concern.","Shared conformance tests expose resolvers that corrupt history, choose among ambiguous targets, or behave differently after equivalent artifact transformations.","Leakage review prevents internal matching artifacts from becoming new attachment contracts.","Resolver and repository implementations can then change while clients continue to observe the same concern identities, histories, and declared resolution semantics."],"baseline":"Keep comments inside each design or prototyping tool, attach them to frames or coordinates, copy selected concerns into an issue tracker, and manually reconcile broken links during design review. Teams may retain old frames or component identifiers to reduce attachment loss.","nearest_rivals":["Persistent layer or component identifiers, which can preserve attachments through limited edits but expose representation identity and do not define behavior for splits, merges, deletion, ambiguity, or cross-medium change.","Screenshot-based annotations, which retain the original visual evidence but do not determine whether the concern applies to a later interactive representation.","Issue-tracker tickets with prose and links, which preserve concern text and workflow status but leave target resolution and artifact-change semantics to manual convention.","A design-system component registry, which can stabilize references for shared components but does not cover page-specific affordances, interaction states, task roles, or prototypes outside the registry.","Manual critique reconciliation at review milestones, which permits human judgment but lacks a reusable behavioral boundary for repositories and resolver implementations."],"remaining_contrastive_claim":"The proposal treats a design concern and its semantic applicability as the durable abstract object, while concrete artifact references are replaceable bindings whose resolution can explicitly fail or become ambiguous. It does not claim that automated resolution understands the critique or may decide that the underlying concern has been addressed.","authority_safety":{"decision_authority":"The design-operations repository owner may authorize a sandbox implementation; design-review process owners define lifecycle authority, and accessibility or research owners retain authority over concerns they originate.","authorized_first_step":"Copy a bounded set of synthetic prototype revisions into an isolated repository, create fictional concerns, and compare two resolver implementations against a contract written before their outputs are inspected.","excluded_actions":["Migrating, rewriting, closing, or rebinding production comments","Allowing a resolver to mark a substantive concern addressed","Using private participant data or confidential product artifacts in the sandbox","Exposing raw prototype credentials or unrestricted artifact contents to a resolver","Treating a unique target match as evidence that the design concern is resolved","Replacing named human authority with a confidence threshold"],"halt_rollback":"Stop if a resolver can change lifecycle state, if ambiguity is silently collapsed, if sandbox code accesses production artifacts, or if a seeded history or authorization violation passes the oracle. Disable the sandbox integration, delete copied artifacts and bindings, and retain only the abstract failure cases for contract revision."},"negative_tests":{"strongest_counterevidence":"The strongest counterevidence would show that most consequential critiques depend inseparably on exact visual, spatial, temporal, or material properties of one representation, making semantic targets either too vague to resolve or so detailed that they merely reproduce the original artifact structure.","problem_falsifier":"The inferred problem is falsified if tested concern histories already remain correctly attached and explicitly unresolved across moves, splits, merges, deletions, and tool changes, while observed review loss instead results from absent ownership or deliberate failure to act on intact concerns.","intervention_falsifier":"The intervention is falsified if independently implemented resolvers pass the suite yet bind the same concern to different contract-level targets, or if reliable client behavior requires raw layer paths, coordinate rules, exact matching scores, or resolver-specific traversal order to enter the public contract.","risks":["A plausible but incorrect automatic binding may be more dangerous than an obvious orphaned comment.","Semantic target descriptions may become costly parallel documentation that drifts from the design.","Overly broad targets may attach one concern to unrelated controls with similar roles.","Overly detailed targets may freeze task structure and recreate representation coupling.","Lifecycle controls may add review overhead without improving follow-through.","Preserved critique text or artifact snapshots may contain confidential or personal information.","A conforming resolver may preserve attachment semantics while providing poor suggestions or an unusable review experience."]},"next_evidence_step":"Run an offline mutation test using three synthetic versions of one interactive prototype and twelve fictional concerns. Specify expected concern identity, applicability, ambiguity, and lifecycle outcomes before implementing one component-lineage resolver and one task-tag resolver. Seed node reuse, one-to-many splits, many-to-one merges, deletion, ambiguous duplicates, unauthorized closure, and lost provenance. Continue only if both implementations reject every forbidden transition, report seeded ambiguity rather than selecting silently, and preserve identical abstract histories without clients inspecting raw artifact identifiers.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Proposal 1 contracts live maintenance-report task execution across interaction modalities, protecting user-reachable actions, validation, recovery, and submission behavior. Proposal 2 contracts usability-evidence records across interface releases, protecting the declared meaning and privacy boundary of measurement. This proposal instead contracts the identity, target applicability, provenance, and lifecycle of collaborative design critiques across changing artifacts. Its protected object is neither an executing user session nor an analytics record; its primary actors are design reviewers and repository stewards; and its causal path operates through semantic anchoring, explicit ambiguity, and concern-history preservation. It can be adopted without multiple user modalities, workflow substitution, or continuous telemetry, so it is not a feature or implementation detail of either earlier proposal.","revision_record":{"parent_version":null,"progress_targets_addressed":["Initial complete proposal at proposal_index 3","Material differentiation from sealed proposals 1 and 2"],"conceptual_changes":["Established the design concern and its semantic applicability as the abstract component.","Separated target resolution from human authority to mark a concern addressed.","Made ambiguity and unresolved status contractual outcomes rather than resolver failures to conceal."],"operational_changes":["Specified lifecycle operations, provenance invariants, resolver substitution criteria, and leakage controls.","Bound the first step to fictional concerns and isolated synthetic prototype revisions.","Added explicit authority exclusions and rollback triggers for silent binding and lifecycle mutation."],"evidence_changes":["Defined an offline comparison of two independently represented resolvers.","Added seeded split, merge, node-reuse, ambiguity, provenance, and authorization failures.","Kept prior-art status unsearched."],"claim_changes":["Made no claim of novelty, prevalence, demand, adoption, or effect size.","Limited the claim to preserving contract-declared concern identity and resolution behavior across artifact representations."]}}