{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","research_id":"eoa_inverse_innovation_exp09_light_prior_art_20260804","cell_id":"inversion_of_control__computer_science","search_lanes":{"direct_problem_and_intervention":{"queries":["LLVM new pass manager analyses computed lazily on demand getResult cached invalidation","compiler demand driven analysis pass manager lazy analysis prior art"],"source_ids":["SRC1","SRC2","SRC3"],"no_result_note":null},"synonyms_and_historical_terms":{"queries":["LLVM legacy pass manager required analyses unused lazy analysis","compiler query system demand-driven memoized provider"],"source_ids":["SRC1","SRC4"],"no_result_note":null},"products_practices_and_standards":{"queries":["MLIR analysis management computed on demand cached invalidated pass","Rust compiler query system demand driven memoized official rustc dev guide"],"source_ids":["SRC2","SRC3","SRC4"],"no_result_note":null},"component_combination":{"queries":["compiler pass requests registered analysis provider cache invalidation instrumentation","typed compiler query provider dependency graph cycle detection"],"source_ids":["SRC2","SRC3","SRC4"],"no_result_note":null}},"sources":[{"source_id":"SRC1","title":"The New Pass Manager","publisher":"The LLVM Project","url":"https://blog.llvm.org/posts/2021-03-26-the-new-pass-manager/","source_type":"FIRST_PARTY_PRODUCT","claims_supported":["LLVM's legacy pass manager required passes to declare analyses in advance even though a pass might not use every declared analysis in every case.","LLVM's new pass manager separates analyses from transformation passes and lets a pass request an analysis from an analysis manager for lazy computation.","The analysis manager computes, caches, and invalidates results, addressing redundant work and separation-of-concerns problems."]},{"source_id":"SRC2","title":"Using the New Pass Manager","publisher":"The LLVM Project","url":"https://llvm.org/docs/NewPassManager.html","source_type":"OFFICIAL_GUIDANCE","claims_supported":["A running transformation pass queries an analysis manager; a valid cached result is returned or the analysis run method is invoked and its result cached.","LLVM uses preserved-analysis declarations and explicit clearing to control validity after IR transformations.","LLVM restricts cross-scope analysis activation because it can cause quadratic work, nondeterminism, concurrency problems, or access to invalid mutable results."]},{"source_id":"SRC3","title":"Pass Infrastructure: Analysis Management","publisher":"The MLIR Project","url":"https://mlir.llvm.org/docs/PassManagement/","source_type":"OFFICIAL_GUIDANCE","claims_supported":["MLIR analyses are free-standing, nonmutating classes computed lazily on demand and cached to avoid unnecessary recomputation.","An operation pass requests an analysis through typed getAnalysis utilities, which construct it only if necessary.","MLIR records analysis dependencies for invalidation and provides instrumentation callbacks around analysis computation."]},{"source_id":"SRC4","title":"The Query Evaluation Model in Detail","publisher":"The Rust Project","url":"https://rustc-dev-guide.rust-lang.org/queries/query-evaluation-model-in-detail.html","source_type":"OFFICIAL_GUIDANCE","claims_supported":["rustc's compiler database is populated on demand by typed queries with named provider functions.","Providers invoke dependent queries, while the query context memoizes results and calls providers only on cache misses.","The query engine tracks a dependency DAG and checks for cyclic invocations."]}],"problem_evidence":{"status":"SUPPORTED","finding":"The problem is directly visible in LLVM's account of its legacy pass manager: analyses were declared before execution even when a pass might not use them, while invalidation and uncached cross-function analysis could cause redundant work. LLVM and MLIR documentation also confirms that analysis recomputation is expensive enough to motivate lazy requests, caching, and fine-grained invalidation.","source_ids":["SRC1","SRC2","SRC3"]},"closest_prior_art":[{"name":"LLVM New Pass Manager analysis management","source_ids":["SRC1","SRC2"],"overlap":"A transformation pass requests a typed analysis from a centrally configured analysis manager; the manager returns a valid cached result or runs the registered analysis, caches it, and applies invalidation after transformations. This matches the proposed consumer-triggered control direction and broker role.","remaining_difference":"The proposal additionally emphasizes per-request authorization, explicit resource budgets, provenance linking each computation to subsequent use, and approved fallback behavior; these are governance and observability refinements rather than a new activation architecture."},{"name":"MLIR Analysis Management","source_ids":["SRC3"],"overlap":"Passes request nonmutating analyses on demand through typed APIs; analyses may request dependencies, are cached, and are invalidated according to preserved-analysis information. Instrumentation can observe analysis computation.","remaining_difference":"The retained documentation does not establish the proposal's full audit record, provider-level budgets, or conservative fallback protocol."},{"name":"rustc demand-driven query system","source_ids":["SRC4"],"overlap":"Typed consumer queries trigger registered provider functions on cache misses, memoize results, form dependency graphs, and detect cycles.","remaining_difference":"rustc's query model is broader than transformation-pass analysis management and relies on immutable keys, results, and pure providers rather than versioned analyses over a mutating IR."}],"prior_art_disposition":"ESTABLISHED_PRACTICE","contrastive_claim_remaining":"Only a narrower enhancement remains testable: adding explicit authorization, resource budgets, request-to-use provenance, and approved fallback semantics to an existing on-demand compiler analysis manager may improve auditability or resource control without changing analysis results, determinism, or IR semantics. The proposal's stated core contrast—consumer-requested analysis mediated by a manager rather than fixed scheduling—is already established in LLVM and MLIR.","contrastive_claim_falsifier":"The narrower claim is falsified if the target compiler's existing analysis manager already supplies materially equivalent authorization, budgeting, provenance, and fallback controls, or if a fixed-corpus replay shows no reduction in unconsumed work or improved traceability after accounting for request latency, invalidation bookkeeping, and cycle handling.","gates":{"adequate_source_search":{"status":"PASS","rationale":"The bounded search covered the proposal directly, legacy and demand-driven terminology, current compiler products and practices, and combinations of typed requests, providers, caching, dependencies, invalidation, instrumentation, and cycles. Four opened direct sources from two publishers were retained.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"supported_problem":{"status":"PASS","rationale":"Official LLVM material explicitly describes advance declaration of analyses that may go unused, expensive recomputation, invalidation, and redundant uncached work; MLIR identifies avoidance of unnecessary recomputation as a reason for lazy cached analyses.","source_ids":["SRC1","SRC2","SRC3"]},"distinct_testable_claim":{"status":"FAIL","rationale":"The proposal's claimed control-direction distinction substantially matches the established LLVM New Pass Manager and MLIR analysis-manager design. Only narrower governance and observability additions remain distinguishable.","source_ids":["SRC1","SRC2","SRC3"]},"bounded_next_test":{"status":"PASS","rationale":"The proposed offline, trace-only replay for one deterministic read-only analysis is finite and measurable. Existing analysis instrumentation and cache/invalidation APIs make comparison of requests, computations, invalidations, dependencies, latency, cycles, and result equivalence technically plausible.","source_ids":["SRC2","SRC3"]},"no_obvious_safety_or_authority_stop":{"status":"PASS","rationale":"A non-authoritative offline replay that retains the scheduled result, forbids provider mutation, enforces resource and cycle limits, checks equivalence and determinism, and restores the unchanged schedule presents no obvious safety or authority stop. Official systems likewise impose scope, mutability, validity, and cycle constraints.","source_ids":["SRC2","SRC3","SRC4"]}},"screen_survival":false,"world_novelty_boundary":"This bounded public-web screen finds the core architecture already established in LLVM and MLIR. It cannot establish world novelty, patentability, market size, expert acceptance, realized value, or whether the narrower authorization, budgeting, provenance, and fallback combination exists elsewhere."}