{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","research_id":"eoa_inverse_innovation_exp09_light_prior_art_20260804","cell_id":"decoupling_via_interface__computer_science","search_lanes":{"direct_problem_and_intervention":{"queries":["\"versioned runtime introspection\" protocol debugger profiler VM","\"runtime introspection protocol\" debugger heap analyzer","debugger profiler shared semantic VM interface capability negotiation"],"source_ids":["SRC1","SRC2","SRC3"],"no_result_note":null},"synonyms_and_historical_terms":{"queries":["JVMPI JVMDI replacement stable tool interface","JVMTI debugger profiler heap inspection interface version capabilities","CLR DAC matching runtime version debugger"],"source_ids":["SRC1","SRC2","SRC4"],"no_result_note":null},"products_practices_and_standards":{"queries":["Java JVM Tool Interface specification threads stack frames heap capabilities version","Java Platform Debugger Architecture JVM TI JDWP","HPROF heap CPU profiler JVM TI","Microsoft CLR DAC version mismatch debugging"],"source_ids":["SRC1","SRC2","SRC3","SRC4"],"no_result_note":null},"component_combination":{"queries":["VM interface profiling debugging monitoring thread analysis heap traversal","runtime semantic interface GetAllThreads GetStackTrace IterateThroughHeap capabilities errors","shared debugger profiler interface replacing separate profiling debugging interfaces"],"source_ids":["SRC1","SRC2","SRC3"],"no_result_note":null}},"sources":[{"source_id":"SRC1","title":"JVM Tool Interface 25.0.0","publisher":"Oracle","url":"https://docs.oracle.com/en/java/javase/25/docs/specs/jvmti.html","source_type":"OFFICIAL_STANDARD","claims_supported":["JVM TI is a VM-provided interface intended for profiling, debugging, monitoring, and thread-analysis tools.","It defines semantic operations for threads, stack frames, objects, and heap traversal without requiring tools to know VM-private layouts.","It provides interface-version compatibility checks, per-implementation capabilities, extension mechanisms, and specified error codes.","Multiple simultaneous agents can use separate JVM TI environments, although the interface is in-process and permits control and mutation as well as inspection."]},{"source_id":"SRC2","title":"Java Platform Debugger Architecture (JPDA)","publisher":"Oracle","url":"https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/index.html","source_type":"OFFICIAL_GUIDANCE","claims_supported":["JPDA places JVM TI between the VM and debugger infrastructure and uses JDWP for communication with debugger front ends.","JVM TI replaced both the earlier experimental profiling interface JVMPI and debugging interface JVMDI, showing consolidation of formerly separate tool interfaces."]},{"source_id":"SRC3","title":"HPROF","publisher":"Oracle","url":"https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr008.html","source_type":"OFFICIAL_GUIDANCE","claims_supported":["HPROF used JVM TI for heap and CPU profiling and could report heap dumps, allocation statistics, monitor state, and thread state.","The example demonstrates that a heap/profiling tool can consume the same semantic VM interface used within debugging architecture rather than private layouts.","Oracle labels this HPROF implementation demonstration code rather than a supported formal product."]},{"source_id":"SRC4","title":".cordll (Control CLR Debugging)","publisher":"Microsoft","url":"https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/-cordll--control-clr-debugging-","source_type":"OFFICIAL_GUIDANCE","claims_supported":["Managed debugging requires loading a CLR Data Access Component corresponding to the CLR loaded by the target.","The command offers long module names to avoid local-CLR mismatches and requires selection when multiple CLR versions are present.","This directly demonstrates runtime/debugging-component version coupling and runtime-specific mediation in another VM ecosystem."]}],"problem_evidence":{"status":"PARTLY_SUPPORTED","finding":"Runtime/tool version coupling is directly visible in Microsoft's requirement for a target-corresponding CLR DAC, and Java's history shows separate profiler and debugger interfaces being replaced by JVM TI. The retained evidence does not establish the proposal's broader premise that current debuggers, profilers, and heap analyzers generally dereference private layouts themselves; it also shows that a supported semantic interface already prevents that coupling for many Java tools.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"closest_prior_art":[{"name":"JVM Tool Interface (JVM TI)","source_ids":["SRC1","SRC2","SRC3"],"overlap":"A versioned, VM-implemented semantic contract already serves debuggers, profilers, monitors, thread analyzers, and heap-oriented tooling. It defines thread, frame, object, and heap operations, capability discovery, extensions, compatibility checks, and explicit errors while hiding VM representations.","remaining_difference":"JVM TI is a native in-process interface, is not limited to read-only operations, and the retained specification does not provide the proposal's schema-validation and cross-build conformance-fixture regime."},{"name":"Java Platform Debugger Architecture","source_ids":["SRC1","SRC2"],"overlap":"JPDA combines a VM tool interface with a wire protocol and higher-level debugger API, placing governed semantic interfaces between VM implementation and debugger front ends.","remaining_difference":"Its wire-protocol layer is debugger-focused rather than one read-only protocol expressly shared by debuggers, profilers, and heap analyzers."},{"name":"CLR Data Access Component matching","source_ids":["SRC4"],"overlap":"A runtime-specific component mediates debugger access and must correspond to the inspected CLR, including for live targets and crash dumps.","remaining_difference":"Version dependence is managed by locating the matching component rather than by demonstrating one implementation-neutral contract that remains unchanged across representation-changing CLR builds."}],"prior_art_disposition":"SUBSTANTIAL_COLLISION","contrastive_claim_remaining":"The remaining testable distinction is narrower than the original intervention: a strictly read-only, out-of-process, schema-validated protocol can let an unchanged debugger and profiler inspect two representation-different runtime builds through adapter-only changes while preserving predefined semantic fixtures and resource limits. The general claim that a versioned semantic VM interface can decouple multiple diagnostic tool classes is already substantially embodied by JVM TI.","contrastive_claim_falsifier":"The residual claim is falsified if existing JVM TI or another located interface already supplies the same read-only out-of-process and conformance-governed combination, or if either trial tool needs build-specific code or hidden-layout access, golden entities change meaning or disappear, consistency cannot be expressed, or preset pause-time, latency, or memory limits are exceeded.","gates":{"adequate_source_search":{"status":"PASS","rationale":"The bounded search covered direct wording, older JVMPI/JVMDI terminology, official Java and CLR practices, and combinations of versioning, capabilities, semantic entities, heap traversal, and runtime adapters. Exactly four opened sources from Oracle and Microsoft were retained.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"supported_problem":{"status":"PASS","rationale":"The problem is partly supported: CLR documentation directly exposes target-version coupling, while Java documentation records consolidation of separate profiler and debugger interfaces. The stronger claim of widespread direct private-layout access is not established.","source_ids":["SRC2","SRC4"]},"distinct_testable_claim":{"status":"PASS","rationale":"After accounting for JVM TI, a distinct claim remains around a strictly read-only, out-of-process, schema-validated and conformance-tested contract used unchanged by two tool classes across representation-different builds.","source_ids":["SRC1","SRC2","SRC3"]},"bounded_next_test":{"status":"PASS","rationale":"The proposed two-build, one-debugger, one-profiler harness is bounded and can measure tool-side changes, residual layout references, semantic equivalence, and preset overhead limits. Including a JVM TI baseline would make the contrast interpretable.","source_ids":["SRC1","SRC2","SRC3"]},"no_obvious_safety_or_authority_stop":{"status":"PASS","rationale":"A feature-flagged, read-only, non-production harness with payload restrictions and rollback is within ordinary experimental authority. Existing inspection interfaces establish feasibility, although attachment permissions, sensitive object data, pauses, and resource limits still require enforcement.","source_ids":["SRC1","SRC3","SRC4"]}},"screen_survival":false,"world_novelty_boundary":"This four-source public-web screen finds substantial collision with JVM TI and related Java tooling architecture. It does not establish world novelty, patentability, market size, expert acceptance, production safety, adoption feasibility, or realized value; broader literature, source-code, product, and patent searches could reveal an exact read-only out-of-process contract or further differences."}