{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","cell_id":"activation_decay_measurement__computer_science","arm":"BREADTH_PROBE_ONE_SHOT","candidate_id":"activation_decay_measurement__computer_science__P1","proposal_index":1,"version":0,"title":"Expiry-Governed Security Review Cues for Asynchronous Pull Requests","problem":"A reviewer receives a security pre-brief when assigned a pull request, but may inspect the code hours later after other work and interruptions. The workflow records delivery of the pre-brief as if the reviewer were still ready to trace untrusted input through identity, resource, and authorization checks. If that specific inspection routine has faded by review time, authorization defects can be overlooked and the miss can be misattributed to reviewer competence or carelessness.","actors":["Pull-request reviewer","Contributing developer","Repository maintainer","Application-security lead","Pilot evaluator"],"observable_state":"After a short pre-brief defining an authorization-boundary inspection routine, reviewers complete matched synthetic code-review tasks at controlled delays. Observable proxies are whether they locate each planted authorization decision, correctly name the principal, action, and protected resource, and the latency to begin the inspection routine. Delay, interruptions, competing review cues, task difficulty, and any refresh exposure are recorded.","consequence":"The repository may merge code whose authorization behavior was not deliberately inspected, while maintainers retain false confidence because assignment notices, training completion, or pre-brief delivery are mistaken for current review readiness.","affected_objective":"Maintain dependable inspection of authorization boundaries in asynchronous code review without treating stale cues as evidence that a security check occurred.","intervention":"Define the activated target as the four-step routine: locate untrusted entry points, identify the acting principal and requested action, locate the authorization decision, and verify denial behavior. Capture performance immediately after a transparent pre-brief, then use matched synthetic diffs to probe the same routine after delays representative of the review queue and after common context switches. Fit a simple, uncertainty-bounded decay profile and mark the cue expired when performance no longer meets a repository-owner-defined pilot threshold. Before an expired review begins, present one context-matched reactivation card and require the reviewer to actively restate the four steps; if reactivation is declined or not completed, the system records readiness as unknown rather than blocking or certifying the merge. Refresh frequency is capped, and the timing rule is recalibrated from subsequent pilot observations.","structural_mapping":[{"archetype_element":"Activation Target Definition","domain_realization":"The explicit authorization-boundary inspection routine, rather than generic security awareness or review engagement."},{"archetype_element":"Baseline Activation Capture","domain_realization":"Immediate post-pre-brief performance on a synthetic pull request containing known authorization decision points."},{"archetype_element":"Observable Activation Proxy","domain_realization":"Correct localization and description of planted authorization decisions plus latency to initiate the inspection routine."},{"archetype_element":"Delayed Probe Schedule","domain_realization":"Matched review tasks administered after realistic queue delays and context switches, with task order and difficulty balanced."},{"archetype_element":"Decay Curve Model and Half-Life Estimator","domain_realization":"An empirical delay-to-performance profile with uncertainty bounds, used only to estimate when reliance on the pre-brief becomes unsupported."},{"archetype_element":"Usable Activation Threshold","domain_realization":"A criterion chosen before analysis by the repository owner for pilot tasks, such as locating every planted authorization decision and correctly naming its principal, action, and resource; it is not a production-safety certification."},{"archetype_element":"Refresh or Reprime Protocol","domain_realization":"A just-in-time card at review entry that asks the reviewer to restate the four-step routine before opening the changed files."},{"archetype_element":"Context and Load Register","domain_realization":"Recorded delay, interruptions, concurrent review count, diff complexity, competing warnings, and whether the programming context changed."},{"archetype_element":"Expiry Boundary and Stop Rule","domain_realization":"After the supported window, assignment or pre-brief delivery cannot be cited as evidence of current readiness; the state is marked expired until reactivated or retested."},{"archetype_element":"Ethical Timing Guardrail","domain_realization":"Reviewers are told what is measured and why, may decline probes, and are not individually ranked or subjected to covert cue timing."}],"mechanism_mapping":[{"mechanism_slug":"time-lagged_activation_probe","role":"Measures the same defined inspection routine at increasing assignment-to-review delays using matched synthetic diffs.","counterfactual_removal":"Without delayed probes, the workflow could observe immediate comprehension but could not determine whether readiness survives the asynchronous queue."},{"mechanism_slug":"decay_curve_fitting","role":"Converts delayed task observations into a practical cue-freshness window with uncertainty explicitly retained.","counterfactual_removal":"Without a fitted delay relationship, refresh timing would revert to an arbitrary calendar interval or occur on every review."},{"mechanism_slug":"activation_window_thresholding","role":"Turns the measured profile into a rule distinguishing supported, uncertain, and expired reliance on the pre-brief.","counterfactual_removal":"Without thresholding, measurements would not govern when the system may stop treating cue delivery as current readiness."},{"mechanism_slug":"contextual_reactivation","role":"Restages the inspection routine at the actual review boundary, in the same principal-action-resource terms needed for the task.","counterfactual_removal":"Without contextual reactivation, an expired state could be detected but not restored near the action moment."},{"mechanism_slug":"staleness_boundary_enforcement","role":"Prevents old assignments, training records, or pre-brief receipts from serving as proxies for a current security inspection.","counterfactual_removal":"Without enforcement, the organization could continue claiming readiness from stale exposure records even after measuring their expiry."}],"causal_chain":["A reviewer receives a pre-brief that activates a specific authorization-inspection routine.","The pull request waits in an asynchronous queue while interruptions and competing cues accumulate.","Activation of the routine may weaken before the reviewer encounters the code.","The workflow probes routine-specific performance at representative delays instead of inferring readiness from cue delivery.","Observed performance by delay establishes a bounded freshness profile and an expiry rule.","At review entry, an expired cue triggers a transparent, context-matched restatement exercise.","The restatement may reactivate the inspection path immediately before it is needed.","Expired or unknown readiness is no longer represented as proof that authorization behavior was inspected; the actual review findings remain the evidence for the merge decision."],"baseline":"The assignment system sends a security checklist or pre-brief once, records that it was delivered, and leaves the reviewer to open the pull request later. No routine-specific delayed measurement, freshness state, adaptive refresh timing, or expiry rule connects cue delivery to the actual review moment.","nearest_rivals":["A checklist displayed on every pull request: supplies a cue at a fixed location but does not measure its immediate activation, delayed decay, usable window, or refresh burden.","Annual secure-coding training: targets broader and more durable knowledge, while this intervention governs the short-lived activation of one inspection routine around a particular review.","Mandatory acknowledgement before merge: records a declaration but does not test whether the targeted inspection path remains active or identify when it expired.","Automated static analysis: inspects code mechanically and may complement the intervention, but it does not manage the human reviewer's transient attention to authorization semantics.","Generic spaced retrieval practice: seeks durable learning over repeated sessions; this candidate estimates and governs the operational lifetime of a specific pre-review cue."],"remaining_contrastive_claim":"The candidate is distinguished by the complete measured lifecycle linking a defined review cue to immediate baseline performance, delayed task probes, an empirically bounded expiry state, context-matched reactivation, and a prohibition on treating expired exposure as readiness. Merely showing a checklist, acknowledging a warning, or repeating training does not instantiate that lifecycle.","authority_safety":{"decision_authority":"Repository maintainers retain merge authority, the application-security lead defines which synthetic defects are security-relevant, and participating reviewers control consent to measurement. The pilot evaluator may estimate cue freshness but may not certify reviewer competence or production safety.","authorized_first_step":"Run a preregistered sandbox pilot with a small consenting reviewer cohort, one transparent four-step pre-brief, matched synthetic pull requests, an immediate probe, and a bounded set of delayed probes spanning the repository's ordinary review queue; compare expired-cue tasks with and without one reactivation card.","excluded_actions":["Changing production branch protection or merge permissions","Using pilot scores for employment evaluation, discipline, or individual ranking","Introducing covert priming, hidden monitoring, or deceptive task purposes","Treating the estimated window as proof that a production review is safe","Automatically approving, rejecting, or assigning blame for a pull request","Sending repeated refreshes beyond the preregistered cap"],"halt_rollback":"Stop the pilot if participants withdraw, probes expose sensitive repository content, the reactivation card materially disrupts normal work, or measurement burden exceeds the preregistered limit. Disable the pilot prompt and delete participant-linked measurements according to the consent protocol; existing merge controls remain unchanged throughout."},"negative_tests":{"strongest_counterevidence":"Performance on matched authorization-review tasks remains stable across realistic delays and context switches, while variation is better explained by diff complexity, prior security expertise, or ambiguous planted defects than by time since the pre-brief.","problem_falsifier":"After balancing task difficulty and recording context load, the routine-specific proxy shows no practically decision-relevant deterioration over the full assignment-to-review interval; cue delivery is therefore not becoming stale within the workflow window.","intervention_falsifier":"For observations beyond the candidate expiry boundary, the context-matched restatement does not restore routine-specific performance relative to an otherwise matched no-refresh condition, or it increases distraction and false findings enough to defeat the intended inspection objective.","risks":["Synthetic-task performance may not transfer to production repositories.","Repeated probes may themselves train the routine and distort the estimated decay profile.","The proxy may reward naming authorization concepts without improving defect detection.","A single decay rule may misrepresent reviewers with different experience, workloads, or accessibility needs.","Refresh cards may become habituated noise or encourage mechanical box-checking.","Readiness labels could be misused as personnel surveillance or as an unwarranted security guarantee.","Conservative expiry could add review friction without addressing defects caused by architecture or tooling."]},"next_evidence_step":"Conduct only the sandbox pilot: preregister the target routine, task-level threshold, delay bins, refresh cap, covariates, exclusions, and analysis rule; use matched synthetic diffs with known authorization defects; estimate whether performance changes with delay and whether one transparent reactivation restores the defined proxy. The result may justify rejecting or refining the timing rule, but not production deployment or an effect-size claim.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Not assessed because runtime isolation forbids inspecting other proposals; this candidate was derived solely from the supplied archetype and computer-science domain card.","revision_record":{"parent_version":null,"progress_targets_addressed":[],"conceptual_changes":[],"operational_changes":[],"evidence_changes":[],"claim_changes":[]}}