{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","research_id":"eoa_inverse_innovation_exp09_light_prior_art_20260804","cell_id":"failover__computer_science","search_lanes":{"direct_problem_and_intervention":{"queries":["stateful Jupyter notebook kernel failover warm standby checkpoint recovery","computational notebook live migration kernel state checkpoint execution history","Jupyter kernel fault tolerance checkpoint restart state recovery","notebook kernel shadow replica failover epoch fencing"],"source_ids":["SRC1","SRC2","SRC3"],"no_result_note":null},"synonyms_and_historical_terms":{"queries":["Jupyter notebook kernel active passive replication warm standby failover","computational notebook fault tolerance cell execution log side effects replay","Jupyter notebook kernel high availability state replication split brain","notebook kernel checkpoint shadow replica recovery"],"source_ids":["SRC1","SRC2","SRC4"],"no_result_note":null},"products_practices_and_standards":{"queries":["JupyterHub high availability kernels state failover product","Jupyter kernel checkpoint restore product fault tolerance","DMTCP Jupyter notebook checkpoint restore failure","CRIU JupyterHub live migration checkpoint restore official"],"source_ids":["SRC2","SRC3"],"no_result_note":null},"component_combination":{"queries":["computational notebooks cell replay side effects nondeterministic recovery","Jupyter notebook replay external side effects cell execution idempotent","notebook reproducibility hidden state execution order side effects primary research","fault tolerant notebook cell side effect log exactly once execution"],"source_ids":["SRC1","SRC2","SRC4"],"no_result_note":"No retained source described the complete combination of a continuously synchronized warm notebook kernel, failure-triggered epoch-fenced promotion, and cell-level handling of uncertain external effects. This bounded combination miss is not evidence of novelty."}},"sources":[{"source_id":"SRC1","title":"ElasticNotebook: Enabling Live Migration for Computational Notebooks (Technical Report)","publisher":"arXiv; authors from the University of Illinois and collaborators","url":"https://arxiv.org/abs/2309.11083","source_type":"PRIMARY_RESEARCH","claims_supported":["Notebook sessions depend directly on stateful language kernels, and launching on another machine ordinarily loses session state.","Re-executing a notebook from scratch can be time-consuming, while simple variable copying and OS-level checkpointing have reliability, efficiency, or portability limitations.","ElasticNotebook observes cell executions and combines transferred variables with selective recomputation to reconstruct session state on another machine.","ElasticNotebook reports large reductions in migration and restoration time with low measured overhead."]},{"source_id":"SRC2","title":"Checkpoint, Restore, and Live Migration for Science Platforms","publisher":"arXiv; DiRAC Institute, University of Washington","url":"https://arxiv.org/abs/2101.05782","source_type":"PRIMARY_RESEARCH","claims_supported":["The Elsa prototype implements checkpoint, restore, and cross-host live migration for per-user JupyterHub sessions.","Its checkpoints include process memory, registers, open files, and related session state, permitting continuation on another machine.","The implementation uses Podman and CRIU and reports checkpoint/restore times on the order of tens of seconds, with a pathway toward faster migration.","The demonstrated workflow freezes or proactively migrates a session; it does not describe automatic post-crash promotion of a continuously warm shadow kernel."]},{"source_id":"SRC3","title":"Running Code — Jupyter Notebook 7.4.4 documentation","publisher":"Project Jupyter","url":"https://jupyter-notebook.readthedocs.io/en/v7.4.4/examples/Notebook/Running%20Code.html","source_type":"OFFICIAL_GUIDANCE","claims_supported":["Each notebook is associated with a kernel process that executes its code.","Jupyter prompts the user to restart when a kernel dies.","The kernel maintains the notebook computation state, and restarting the kernel resets that state.","Jupyter exposes rerun-all and rerun-above practices after restart but this page describes no preservation or failover of live kernel state."]},{"source_id":"SRC4","title":"Restoring Reproducibility of Jupyter Notebooks","publisher":"Hong Kong University of Science and Technology Research Portal","url":"https://researchportal.hkust.edu.hk/en/publications/restoring-reproducibility-of-jupyter-notebooks/","source_type":"PRIMARY_RESEARCH","claims_supported":["Arbitrary cell ordering can leave notebook results dependent on an execution sequence that is not obvious from document order.","In the reported sample, 73% of otherwise executable notebooks were not reproducible by straightforward approaches and required inference of cell order.","The Osiris prototype reconstructs execution schemes and instruments cells to mitigate nondeterministic statements such as random functions.","Notebook reconstruction and replay therefore present documented ordering and nondeterminism problems beyond merely restarting a kernel."]}],"problem_evidence":{"status":"PARTLY_SUPPORTED","finding":"The central problem is visible: official Jupyter documentation places computation state in one kernel and says restart resets it, while notebook-migration research explicitly reports loss of state on a new machine and potentially expensive reconstruction. Research also documents execution-order and nondeterminism barriers to straightforward replay. The retained sources do not directly quantify kernel-loss incident frequency or duplicate external writes during recovery, so those portions remain only indirectly supported.","source_ids":["SRC1","SRC3","SRC4"]},"closest_prior_art":[{"name":"ElasticNotebook","source_ids":["SRC1"],"overlap":"Notebook-specific state continuity across machines; transparent observation of every cell execution; transfer of selected variables; dependency-aware replay to reconstruct the existing session efficiently.","remaining_difference":"The source describes migration and restoration, not a continuously running warm shadow in a separate failure domain, automatic failure-triggered takeover, epoch fencing of the former primary, or explicit disposition of an interrupted cell's possible external effects."},{"name":"Elsa checkpointable JupyterHub deployment","source_ids":["SRC2"],"overlap":"Captures a substantially complete Jupyter session, including memory and open files, and restores or migrates it to another host with continuity for the user.","remaining_difference":"Elsa freezes and restores or proactively migrates a session. The source does not describe per-committed-cell synchronization to an already running alternate, post-crash health-triggered promotion, execution epochs, an external-effect ledger, or controlled non-authoritative reentry."},{"name":"Osiris notebook execution reconstruction","source_ids":["SRC4"],"overlap":"Addresses recovery-adjacent replay difficulty by reconstructing cell execution orders and mitigating nondeterministic statements.","remaining_difference":"Osiris targets reproducibility rather than kernel availability; it neither preserves live process state nor supplies warm-standby activation, fencing, or in-flight effect reconciliation."},{"name":"Ordinary Jupyter kernel restart and rerun","source_ids":["SRC3"],"overlap":"Detects or exposes kernel death, starts a replacement process, and offers commands for rerunning notebook cells.","remaining_difference":"Restart explicitly resets kernel state and provides no transfer of the prior session's state or sole execution authority."}],"prior_art_disposition":"ADJACENT_PRIOR_ART","contrastive_claim_remaining":"Within the retained sources, the remaining falsifiable distinction is that notebook continuity after an unplanned primary loss can be achieved by promoting an independently hosted, already-running kernel synchronized at committed-cell boundaries, while a monotonically increasing epoch rejects old-primary work and a cell-effect ledger permits automatic retry only for replay-safe in-flight cells. Existing notebook sources establish restart, checkpoint/restore, live migration, state reconstruction, and replay analysis separately, but not that combined takeover protocol.","contrastive_claim_falsifier":"A public system or publication predating the proposal that implements, for one interactive notebook session, all of the following would falsify the contrast: a warm cross-host kernel replica updated at cell commit boundaries, health-triggered automatic promotion after unplanned failure, fencing tokens or epochs that reject the old kernel's submissions or outputs, and explicit safe-versus-uncertain handling of the cell in flight. The experimental claim would also fail if fault injection permits dual authority, yields unequal committed state, retries an effectful cell, or exceeds the prespecified interruption bound.","gates":{"adequate_source_search":{"status":"PASS","rationale":"The bounded search covered direct wording, older replication and checkpoint terminology, notebook products and practices, and combinations involving replay, nondeterminism, side effects, split brain, and fencing. Four opened sources span official Jupyter guidance and three research efforts from multiple publisher organizations.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"supported_problem":{"status":"PASS","rationale":"The sources directly establish single-kernel state, state reset on restart, cross-host state-loss and reconstruction cost, and substantial replay-order or nondeterminism difficulty. Incident prevalence and external-write duplication remain unquantified, hence PARTLY_SUPPORTED rather than fully supported.","source_ids":["SRC1","SRC3","SRC4"]},"distinct_testable_claim":{"status":"PASS","rationale":"The remaining claim specifies observable invariants absent from the retained adjacent systems: warm readiness, equality at a committed-cell boundary, one accepted epoch, and explicit disposition of interrupted work. Each can be falsified under injected failure.","source_ids":["SRC1","SRC2","SRC4"]},"bounded_next_test":{"status":"PASS","rationale":"A four-case disposable harness is bounded and directly measures committed-state hashes, stale-epoch rejection, selective retry, unresolved external effects, and non-authoritative reentry. Prior work supports the technical researchability of state capture and cross-host restoration without requiring a production deployment.","source_ids":["SRC1","SRC2"]},"no_obvious_safety_or_authority_stop":{"status":"PASS","rationale":"The authorized test is confined to synthetic notebooks, separate local processes, and mocked disposable services, with explicit halt conditions and no production promotion. Sensitive memory replication, unserializable resources, false failover, and duplicate effects remain design risks but do not create an obvious stop for this isolated prototype.","source_ids":["SRC2","SRC3"]}},"screen_survival":true,"world_novelty_boundary":"This light screen supports coarse researchability and identifies adjacent notebook checkpointing, migration, reconstruction, and replay work. It does not establish world novelty, patentability, market size, expert acceptance, realized value, or absence of undiscovered products, papers, patents, source-code implementations, or operational practices."}