{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","research_id":"eoa_inverse_innovation_exp09_light_prior_art_20260804","cell_id":"constraint_envelope_adjustment__computer_science","search_lanes":{"direct_problem_and_intervention":{"queries":["database migration guardrails operation specific policy expand contract lock timeout waiver","production schema migration guardrails backward compatibility destructive changes"],"source_ids":["SRC1","SRC2","SRC3","SRC4"],"no_result_note":null},"synonyms_and_historical_terms":{"queries":["expand contract parallel change schema migration backward compatibility rolling deployment","database refactoring transition phase old and new schema coexist"],"source_ids":["SRC1","SRC2"],"no_result_note":null},"products_practices_and_standards":{"queries":["official database migration lint destructive changes table locks policy Atlas","GitLab migration style guide lock timeout post deployment migration","GitLab database change lock targeted DDL freeze"],"source_ids":["SRC2","SRC3","SRC4"],"no_result_note":null},"component_combination":{"queries":["migration runner enforce lock timeout backward compatibility destructive DDL exception waiver","schema migration policy operation class sequence compatibility reversibility","database migration targeted freeze safe additive changes backlog"],"source_ids":["SRC1","SRC2","SRC3","SRC4"],"no_result_note":null}},"sources":[{"source_id":"SRC1","title":"Parallel Change","publisher":"Martin Fowler","url":"https://martinfowler.com/bliki/ParallelChange.html?collections=null","source_type":"TRADE_PROFESSIONAL","claims_supported":["Parallel change, also called expand and contract, is an established three-phase pattern for safely implementing backward-incompatible changes.","Database refactoring commonly uses a transition period in which old and new schemas coexist until clients have migrated.","Incremental migration lowers risk, while failure to complete contraction can leave the system in a worse state."]},{"source_id":"SRC2","title":"Migration Style Guide","publisher":"GitLab","url":"https://docs.gitlab.com/development/migration_style_guide/","source_type":"OFFICIAL_GUIDANCE","claims_supported":["GitLab assigns schema changes to regular, post-deployment, or background workflows according to operation purpose and expected duration.","GitLab documents short statement and lock timeouts, lock-acquisition retries, multi-release changes, reversible migration methods, and staged destructive cleanup.","The guidance explicitly identifies exclusive-lock acquisition as a source of failed upgrades and application instability."]},{"source_id":"SRC3","title":"Verifying Migration Safety","publisher":"Atlas","url":"https://atlasgo.io/versioned/lint","source_type":"FIRST_PARTY_PRODUCT","claims_supported":["Atlas automatically analyzes migration files for destructive operations, breaking changes, table locks or rewrites, and custom policy violations.","Atlas can simulate migrations on a development database and integrate analysis into CI.","Analyzer-specific nolint directives provide an exception mechanism, although the documented mechanism lacks ownership, expiry, and runtime monitoring."]},{"source_id":"SRC4","title":"Database upgrade DDL lock","publisher":"GitLab","url":"https://docs.gitlab.com/development/database/database_upgrade_ddl_lock/","source_type":"OFFICIAL_GUIDANCE","claims_supported":["GitLab uses an enforceable, time-bounded targeted DDL lock instead of a hard production change lock that would block all deployments.","Different configured block levels selectively prohibit DDL or post-deployment migrations while permitting other changes.","GitLab warns that allowing post-deployment migrations to accumulate during a freeze creates a larger and riskier backlog."]}],"problem_evidence":{"status":"PARTLY_SUPPORTED","finding":"The sources directly show that schema operations differ in lock, compatibility, destructiveness, timing, and reversibility risk, and that broad freezes can unnecessarily block unrelated deployment work or create migration backlogs. They also document differentiated controls used in response. They do not establish how prevalent the proposal's exact binary-approved-runner baseline is or quantify the incidence of beneficial schema changes blocked by blanket freezes.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"closest_prior_art":[{"name":"GitLab differentiated migration workflow and targeted change locks","source_ids":["SRC2","SRC4"],"overlap":"GitLab already differentiates regular, post-deployment, and background migrations; applies operation- and table-sensitive sequencing; controls lock exposure; requires multi-release cleanup patterns; and uses enforceable, scheduled locks with distinct block levels rather than a universal freeze.","remaining_difference":"The retained guidance does not present one general evaluator that jointly computes permissions from operation class, deployment phase, mixed-version compatibility, predicted lock exposure, reversibility, and table criticality, nor an audited expiring waiver with automatic abort conditions and feedback-driven relaxation."},{"name":"Atlas migration safety analysis and policy exceptions","source_ids":["SRC3"],"overlap":"Atlas analyzes destructive, breaking, and lock-heavy operations, supports custom policies, simulates changes on a development database, fails CI checks, and permits analyzer-specific exceptions.","remaining_difference":"The documentation describes pre-execution linting and nolint suppression, not a phase-aware runtime envelope with named and expiring waivers, enhanced monitoring, abort thresholds, or revision based on blocked-safe-action evidence."},{"name":"Parallel change for database refactoring","source_ids":["SRC1"],"overlap":"The established expand-migrate-contract pattern already preserves old and new interfaces during transition and delays destructive contraction until consumers migrate.","remaining_difference":"It is a workflow pattern rather than an automatically enforced control plane combining quantitative operational bounds, exceptions, telemetry, and adjustment rules."}],"prior_art_disposition":"ADJACENT_PRIOR_ART","contrastive_claim_remaining":"A single migration control plane can jointly enforce permissions using operation class, expand-migrate-contract phase, mixed-version compatibility, predicted lock exposure, reversibility, and table criticality; attach named, expiring, audited waivers with monitoring and automatic abort conditions; and revise individual bounds using both escaped-hazard and safely-blocked-action evidence. The retained art establishes many constituent practices but not this full feedback-governed combination.","contrastive_claim_falsifier":"The claim is falsified by finding a public system or documented production practice that already implements the combined phase-aware envelope, including quantitative lock and compatibility bounds, owned expiring waivers with abort conditions, and systematic relaxation from safe-blockage evidence; it is also falsified operationally if isolated replay cannot distinguish hazardous direct sequences from safe staged equivalents or produces unacceptable unexplained false blocks.","gates":{"adequate_source_search":{"status":"PASS","rationale":"The search covered the proposal directly, historical terminology, current tools and operational practices, and combinations of sequencing, compatibility, locking, freezes, and exceptions. Exactly four opened sources from three publishers were retained, including first-party and official sources.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"supported_problem":{"status":"PASS","rationale":"The sources make heterogeneous migration hazards and overbroad-freeze tradeoffs visible, although prevalence of the exact binary-approval baseline remains unquantified.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"distinct_testable_claim":{"status":"PASS","rationale":"The remaining claim specifies a falsifiable combination absent from the retained sources: unified phase-aware enforcement, bounded monitored waivers, automatic aborts, and bidirectional revision from hazard and overconstraint signals.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"bounded_next_test":{"status":"PASS","rationale":"A report-only replay of 30 owner-labeled migrations from one consenting service on an isolated database is bounded and measurable. Atlas's documented development-database simulation supports the feasibility of this testing mode.","source_ids":["SRC2","SRC3"]},"no_obvious_safety_or_authority_stop":{"status":"PASS","rationale":"The proposed first test changes no production permissions and uses an isolated copy under database-owner consent. Official and first-party sources document comparable development-database, CI, and non-production assessment mechanisms. Production data handling and service-owner compatibility authority remain required boundaries.","source_ids":["SRC2","SRC3","SRC4"]}},"screen_survival":true,"world_novelty_boundary":"This bounded public-web screen establishes only coarse researchability and adjacent prior art. It cannot establish world novelty, patentability, market size, expert acceptance, implementation feasibility at scale, or realized value; survival applies solely to the narrower combined contrastive claim and the proposed bounded next test."}