{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","cell_id":"load_leveling_or_demand_smoothing__computer_science","arm":"BREADTH_PROBE_ONE_SHOT","candidate_id":"load_leveling_or_demand_smoothing__computer_science__P1","proposal_index":1,"version":0,"title":"Capacity-Aware Pre-Expiry Refresh Windows for Shared Software Caches","problem":"Many independently deployed services cache the same versioned configuration, schema, or authorization metadata with identical time-to-live boundaries. When a widely shared entry approaches expiry, instances refresh it in the same narrow interval. This synchronized refresh wave can saturate the metadata service and network even though the same total refresh work would fit comfortably across the preceding low-load period.","actors":["Application service instances that consume cached metadata","The authoritative metadata service","A cache-refresh coordinator or client-library scheduler","Site-reliability engineers responsible for the participating services","Security or service owners who classify nonshiftable refreshes"],"observable_state":"Telemetry shows repeatable spikes in refresh requests, metadata-service utilization, timeout rate, and refresh queue depth near common expiry boundaries, with materially lower utilization during adjacent intervals. Refresh records identify which entries were due, scheduled, completed, bypassed, or overdue.","consequence":"The refresh wave competes with interactive metadata lookups, causing timeouts, stale-cache fallback, retry amplification, and delayed recovery precisely when many cached copies are becoming invalid.","affected_objective":"Preserve timely metadata freshness and interactive lookup availability while reducing harmful temporal concentration of routine refresh computation without discarding required refreshes.","intervention":"For eligible shared entries, assign each service instance a deterministic pre-expiry refresh window distributed across the interval before expiration. A coordinator publishes current metadata-service headroom and temporarily narrows or advances releases when capacity is available. Security revocations, forced version changes, cache misses, and entries without a safe early-refresh window bypass smoothing. Every shifted refresh retains an explicit completion deadline, and overdue work re-enters service before expiry. The scheduler records assignments, completions, bypass reasons, backlog, and cohort-level delay so operators can detect starvation, unfair placement, and secondary peaks.","structural_mapping":[{"archetype_element":"Bursty or synchronized demand","domain_realization":"Instances sharing expiry boundaries initiate metadata refreshes within the same narrow interval."},{"archetype_element":"Capacity profile over time","domain_realization":"Metadata-service request capacity and latency headroom vary across the pre-expiry interval and are observable through service telemetry."},{"archetype_element":"Temporally shiftable work","domain_realization":"Routine refreshes may execute earlier within a validity-preserving window without changing the required metadata version or omitting the refresh."},{"archetype_element":"Temporal distribution policy","domain_realization":"Deterministic cohort assignments spread refresh starts across pre-expiry windows and adjust releases using a capacity signal."},{"archetype_element":"Urgent or nonshiftable-work protection","domain_realization":"Revocations, forced invalidations, misses, and entries lacking a safe window bypass scheduled cohorts."},{"archetype_element":"Defined service path for shifted demand","domain_realization":"Each refresh has a scheduled window, latest completion deadline, overdue state, and forced re-entry rule."},{"archetype_element":"Feedback and observability","domain_realization":"Peak refresh rate, utilization variance, interactive latency, backlog, completion, bypass, and cohort distribution tune or halt the policy."},{"archetype_element":"Preserved total service","domain_realization":"The policy changes refresh timing but does not drop refresh obligations or extend metadata validity beyond its existing bound."}],"mechanism_mapping":[{"mechanism_slug":"staggered_start_or_release_times","role":"A stable hash of entry, service, and instance assigns eligible refresh work to separated pre-expiry cohorts, preventing synchronized starts while avoiding a central reservation bottleneck.","counterfactual_removal":"Without staggered release times, instances retain aligned refresh boundaries and the original refresh peak remains."},{"mechanism_slug":"capacity_signal","role":"Observed metadata-service headroom governs whether scheduled cohorts may start, advance within their safe windows, or pause before release.","counterfactual_removal":"Without the capacity signal, static staggering cannot adapt to unrelated load and may move refreshes into another overloaded interval."},{"mechanism_slug":"urgent_work_bypass_rule","role":"Explicit classifications allow correctness- or security-critical refreshes to execute immediately outside the smoothing schedule.","counterfactual_removal":"Without bypass, temporal smoothing could delay revocation or forced-version propagation and violate the freshness invariant."},{"mechanism_slug":"peak_reentry_condition","role":"A refresh that nears its latest safe completion time exits the smoothing queue and receives service regardless of cohort placement.","counterfactual_removal":"Without forced re-entry, paused or repeatedly displaced cohorts could starve and cross expiry without refreshing."}],"causal_chain":["Shared expiry boundaries synchronize routine refresh demand.","Synchronized refresh starts create a short load peak above the metadata service's comfortable capacity despite spare capacity earlier in the validity interval.","Eligibility rules separate safely shiftable routine refreshes from urgent or timing-constrained refreshes.","Deterministic pre-expiry cohort windows move eligible refresh execution from the boundary peak into lower-pressure intervals.","A live capacity signal adjusts cohort release without altering each refresh's latest safe deadline.","Urgent bypass and deadline-based re-entry preserve security and freshness requirements.","Distributed execution lowers temporal concentration while retaining the refresh obligations.","Completion, backlog, latency, bypass, and cohort telemetry reveal peak migration, hidden capacity shortage, starvation, or unfair delay and support rollback."],"baseline":"All instances refresh an entry when their locally observed TTL expires, with ordinary retry behavior after failure. Compare against this unchanged policy using replayed traces or a shadow schedule; do not assume that random jitter already present is sufficient or absent.","nearest_rivals":["Random expiry jitter: spreads timestamps probabilistically but does not explicitly use service capacity, guarantee a completion path, or protect a latest safe deadline.","Request coalescing or single-flight refresh: suppresses duplicate concurrent refreshes for a key, whereas this candidate preserves independently required refresh work and redistributes its execution over time.","Rate limiting: caps refresh admission during a peak but may merely grow a queue; this candidate assigns work to earlier capacity-bearing windows and tracks its deadline.","Backpressure: tells producers to slow when the metadata service is stressed but does not create an auditable pre-expiry temporal allocation.","Cache-TTL extension: reduces refresh frequency by accepting longer-lived data, whereas this candidate leaves validity limits unchanged.","Horizontal capacity expansion: increases the service rate available at the peak rather than changing the temporal concentration of refresh work."],"remaining_contrastive_claim":"The candidate's distinguishing claim is limited to structure: deterministic, capacity-aware pre-expiry cohorting redistributes required refreshes into safe earlier windows while coupling each shifted item to urgent bypass, an explicit deadline, and forced re-entry. If it only blocks work at expiry, suppresses refreshes, or lengthens TTLs, it is not this intervention.","authority_safety":{"decision_authority":"The metadata-service owner may authorize a shadow evaluation; each participating service owner must separately authorize any later scheduling change for that service, and the security owner controls which metadata classes may never be shifted.","authorized_first_step":"Use historical refresh and capacity traces to compute a shadow cohort schedule for one metadata class and one expiry cycle; emit predicted assignments and metrics without changing cache TTLs, refresh execution, traffic, or production configuration.","excluded_actions":["Changing production refresh timing","Extending cache TTLs or validity guarantees","Suppressing or dropping refresh obligations","Delaying revocations, forced invalidations, cache misses, or other designated urgent refreshes","Enrolling services or metadata classes without their owners' approval","Automatically provisioning or removing metadata-service capacity","Using identity, tenant value, or commercial priority to allocate favorable cohorts"],"halt_rollback":"The first step is read-only and ends by deleting or expiring the shadow assignments according to the evaluation data policy. Any later pilot must provide a per-client kill switch that immediately restores native expiry-triggered refresh behavior; halt on projected deadline misses, urgent-path delay, unbounded shadow backlog, worse interactive latency, or a secondary peak above the baseline peak."},"negative_tests":{"strongest_counterevidence":"The apparent expiry correlation disappears after controlling for unrelated scheduled jobs, or the same overload persists when refresh demand is removed from a trace replay, indicating that synchronized refreshes are not the material cause.","problem_falsifier":"Reject the problem framing if eligible refreshes are not temporally concentrated, adjacent intervals lack usable headroom, refresh traffic is too small to affect overload, or total demand exceeds service capacity across the entire safe shifting window.","intervention_falsifier":"Reject the intervention if a deadline-respecting shadow schedule cannot reduce the maximum refresh-arrival rate without increasing projected interactive latency, producing a comparable secondary peak, leaving shifted work overdue, or relying on TTL extension or dropped work.","risks":["Early refreshes may increase total work when refreshed data changes again before the original expiry.","Many cohorts may migrate into the same apparently quiet interval and create a new peak.","Capacity telemetry may lag, causing releases based on obsolete headroom.","A deterministic assignment defect may repeatedly give some services inconvenient windows.","Urgent classification may be gamed or broadened until smoothing becomes ineffective.","Misclassification may delay a security-critical or correctness-critical refresh.","Lower visible peak traffic may conceal growing scheduled or overdue work.","Average capacity may be adequate while a regional shard or metadata key remains locally overloaded.","Scheduler or coordinator failure may couple previously independent clients.","Operational complexity may exceed the value of the reduced concentration."]},"next_evidence_step":"For one metadata class, replay a single representative expiry cycle using timestamped refresh requests, entry deadlines, interactive traffic, and metadata-service capacity at the finest already-retained interval. Generate only shadow cohort assignments over the existing safe pre-expiry window. Compare baseline and shadow maximum refresh-arrival rate, peak-to-average ratio, projected service utilization, interactive tail latency under an agreed queue model, completion before deadline, maximum scheduled backlog, urgent bypass count, cohort distribution by service, and the largest secondary peak. Proceed no further unless all refreshes retain their original validity bound, every shifted item has a completion path, and the shadow result reduces the original peak without a worse secondary peak or projected interactive-latency regression.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"No comparison was made: this isolated one-shot candidate was derived only from the supplied archetype record and computer-science domain card.","revision_record":{"parent_version":null,"progress_targets_addressed":[],"conceptual_changes":[],"operational_changes":[],"evidence_changes":[],"claim_changes":[]}}