{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp12_substrate_denial72_20260805","cell_id":"inversion_of_control__computer_science","arm":"ORDINARY_MAX","candidate_id":"inversion_of_control__computer_science__ORDINARY_MAX","proposal_index":1,"version":0,"title":"Checkpoint-Pulled Maintenance for Stateful Workflow Workers","problem":"A platform controller initiates approved base-image or runtime restarts of stateful workflow workers according to a fleet schedule, although only each worker can observe whether it is between durable workflow steps with no unresolved external side effect. Generic health and readiness signals therefore do not tell the controller whether the current instant is safe for replacement.","actors":["Infrastructure platform release controller","Stateful workflow worker runtime","Application or service owner","Platform security or maintenance owner","Site-reliability operator","Downstream systems receiving workflow side effects"],"observable_state":"For each maintenance intent, logs can align the controller-selected restart time with the worker's checkpoint identifier, active critical section, outstanding side-effect acknowledgements, recovery replay range, replacement version, maintenance deadline, and fleet concurrency. The target state is a pushed restart occurring after a step begins but before its durable commit or external-effect acknowledgement completes.","consequence":"An ill-timed restart can require expensive replay, repeat a non-idempotent external action, prolong recovery, or prompt operators to postpone maintenance after a failed rollout.","affected_objective":"Apply approved runtime and base-image maintenance within its policy deadline while preserving workflow correctness, bounded unavailability, and fleet capacity.","intervention":"Replace the immediate restart command with a pending maintenance intent containing an approved artifact, eligibility window, deadline, and concurrency limit. When a worker reaches an application-defined durable checkpoint and has no unresolved external effect, it sends a signed, one-use request to pull that maintenance action. The platform revalidates identity, intent version, replica capacity, and fleet concurrency before granting a short-lived lease and orchestrating replacement. The worker controls only activation timing inside the approved window; the platform retains artifact, deadline, capacity, and fallback authority.","structural_mapping":[{"archetype_element":"Usual controller push","domain_realization":"The platform scheduler chooses a wall-clock restart time and commands a worker replacement using fleet-level information."},{"archetype_element":"Context holder","domain_realization":"The worker runtime observes durable checkpoints, application critical sections, and unresolved external effects that are not represented by generic readiness."},{"archetype_element":"Control boundary","domain_realization":"Maintenance policy remains with the platform, while the right to initiate a particular approved replacement within its window moves to the worker."},{"archetype_element":"Activation rule","domain_realization":"A request is valid only when an approved intent is pending, a durable checkpoint has committed, no tracked external effect is unresolved, and the checkpoint attestation is fresh."},{"archetype_element":"Interface contract","domain_realization":"The pull request carries worker identity, maintenance-intent ID, checkpoint and execution epoch, attestation, and expiry; the response is a grant or denial with a one-use lease."},{"archetype_element":"Delegation rule","domain_realization":"The worker may choose when to request the approved action but cannot select the artifact, extend the deadline, raise concurrency, or declare the rollout complete."},{"archetype_element":"Feedback signal","domain_realization":"The system records false-safe attestations, critical-section intersections, recovery replay, lease denials, time remaining to deadline, and fallback activations."},{"archetype_element":"Guardrail policy","domain_realization":"Authenticated requests, replay protection, minimum healthy replicas, per-service and fleet concurrency caps, version compatibility checks, and non-extendable deadlines constrain activation."},{"archetype_element":"Override or fallback path","domain_realization":"If a worker is silent or cannot reach a safe point, the platform can deny further work, drain it, notify the owner, and use the preapproved deadline path appropriate to that workload's risk tier."},{"archetype_element":"Audit trail","domain_realization":"The platform records the intent, checkpoint evidence, requester, grant or denial, replacement time, resulting version, recovery behavior, and any override."}],"mechanism_mapping":[{"mechanism_slug":"event_listener_or_webhook","role":"A committed-checkpoint event causes the worker to submit the signed maintenance pull request instead of waiting for platform polling or an immediate restart command.","counterfactual_removal":"Without this event-triggered request, the platform must again guess from time or coarse exported state when to initiate replacement."},{"mechanism_slug":"callback_function","role":"The worker framework invokes a narrow application-supplied maintenance-safety callback after checkpoint commit so application-specific unresolved effects can veto the pull request.","counterfactual_removal":"Without the callback slot, the worker can report only generic runtime idleness and may label an application-unsafe point as safe."}],"causal_chain":["The platform has authority to require maintenance but sees mainly fleet health, deadlines, and generic readiness.","The worker possesses the decisive short-lived information about durable commit and unresolved side effects.","A controller-timed push can intersect a locally visible critical interval because its timing signal omits that information.","Intersection can convert replacement into replay, duplicate external action, or extended recovery.","Publishing an intent separates policy initiation from execution activation.","A durable checkpoint event lets the worker pull the already-approved action through a narrow contract.","The controller validates global safety constraints before issuing a one-use lease, so local initiation does not become unlimited control.","The restart occurs under the lease or follows the explicit deadline fallback, and the audit record permits comparison with the pushed baseline."],"baseline":"A centrally scheduled rolling update chooses restart order and time from health checks, replica counts, fixed termination grace periods, and rollout-wave limits; a pre-stop hook may attempt cleanup only after the controller has already initiated termination.","nearest_rivals":["A central scheduler consuming an exported application-level safe-to-restart metric: this preserves central initiation and could match the proposal if the metric remains fresh through scheduling latency.","Checkpoint-on-termination with a longer grace period: this retains push control but gives a worker time to manufacture a safe point after receiving termination.","Blue-green replacement with traffic draining: this avoids interrupting the old worker by creating a parallel replacement, at the cost of duplicate capacity and state-transfer requirements.","Transactional or idempotent workflow steps: this reduces the consequence of interruption without changing who initiates maintenance.","A globally coordinated barrier: the controller waits until every worker reports readiness and then commits one fleet transition, favoring version uniformity over per-worker activation."],"remaining_contrastive_claim":"Holding the artifact, deadline, checkpoint definition, and fleet-capacity rules fixed, the testable distinction is whether a worker's real right to initiate its maintenance lease at a locally observed checkpoint identifies safer replacement instants than controller initiation from exported signals. If centralized scheduling selects equally safe instants with equal deadline compliance, inversion adds no demonstrated value.","authority_safety":{"decision_authority":"The platform maintenance owner approves the artifact and deadline; the service owner defines and reviews the checkpoint-safety predicate; the worker may request activation; the platform controller alone grants the lease and performs replacement.","authorized_first_step":"Instrument one staging worker with a no-op maintenance-intent endpoint that records signed shadow pull requests and hypothetical lease decisions but cannot restart a worker or alter production state.","excluded_actions":["Autonomous production restarts initiated directly by application code","Allowing a worker to choose or modify the maintenance artifact","Allowing a worker to extend or erase a maintenance deadline","Disabling replica, compatibility, authentication, or concurrency checks","Forcing a production restart as part of the first evidence step","Treating absence of a pull request as proof that maintenance is unnecessary"],"halt_rollback":"Disable the shadow endpoint and retain the existing centralized scheduler if an attestation is not durable, identities or intent versions cannot be verified, requests create material control-plane load, or the safety predicate cannot be audited. Any later pilot must cancel outstanding leases and revert to centralized scheduling on duplicate effects, capacity breach, or incompatible mixed versions."},"negative_tests":{"strongest_counterevidence":"A fresh application-level safety signal available to the central scheduler predicts checkpoint-safe restart instants as well as a worker-triggered request, showing that the mismatch is signal transport or scheduling latency rather than control direction.","problem_falsifier":"For the scoped workload, restart traces do not intersect non-repeatable critical intervals, or observed replay and duplicate effects occur independently of restart timing; then the proposed control mismatch is not the operative problem.","intervention_falsifier":"Shadow pull requests attest unsafe state, fail to arrive within approved windows, or provide no additional discrimination over centrally visible state under identical deadline and capacity rules.","risks":["Workers may defer security maintenance by withholding or gaming readiness signals.","A defective or compromised worker may falsely attest that external effects are settled.","Many workers may reach checkpoints together and create a request or replacement surge.","Per-worker activation may create an incompatible mixed-version interval.","Callbacks and leases may make lifecycle control harder to trace or debug.","Workloads with sparse checkpoints may repeatedly enter the fallback path.","Application teams may encode an overly conservative predicate that converts local safety into fleet patch delay."]},"next_evidence_step":"In one replayable staging workload, issue at most 40 no-op maintenance intents across representative execution states. For each, record the existing scheduler's hypothetical restart time and the first worker-generated eligible checkpoint under the same window and concurrency rules; manually reconcile every attestation against checkpoint, transaction, and external-effect logs. Proceed to a separate non-production restart test only if no false-safe attestation is found and at least one trace shows a baseline critical-section intersection avoided by the pull time without introducing a deadline violation; otherwise reject or revise the mechanism.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Not assessed against other proposals because runtime isolation forbids inspecting them; this candidate is characterized solely as worker-checkpoint-triggered infrastructure maintenance.","revision_record":{"parent_version":null,"progress_targets_addressed":["Initial complete candidate with a concrete control mismatch, operational mechanism, serious rivals, safeguards, falsifiers, and bounded evidence step"],"conceptual_changes":["Initial version separates platform policy authority from worker-level activation authority."],"operational_changes":["Initial version introduces attested checkpoint requests, one-use leases, capacity checks, deadlines, fallback handling, and an audit record."],"evidence_changes":["Initial version limits first evidence to a shadow-only staging comparison with no actual restart."],"claim_changes":["The contrast is framed as a falsifiable hypothesis and makes no novelty, prevalence, demand, or effect-size claim."]}}