{"schema_version":1,"assessment_id":"eoa_inverse_innovation_exp03_opportunity320_20260801","source_experiment_id":"eoa_inverse_innovation_exp03_full320_20260801","cell_id":"layer_decay_and_expiration_management__human_computer_interaction","archetype_slug":"layer_decay_and_expiration_management","domain_slug":"human_computer_interaction","title":"Source-aware lifecycle management for persistent notifications","opportunity_summary":"Test whether source-linked lifecycle states, reversible archival suggestions, and governed expiry reduce mistaken interaction with obsolete notifications and improve current-work triage without hiding valid obligations or losing recoverable history.","adopter_authorizer":"The immediate adopter is a consenting workspace team and its product owner; workspace administrators and records/privacy authorities authorize class rules and deletion policy, while designated legal or safety authorities retain control over holds and protected alerts.","scores":{"meaningful_impact":{"score":3,"rationale":"The proposal targets mistaken actions, attention burden, and impaired task finding while preserving accountability, but the packet supplies no prevalence, effect-size, or representative-session evidence showing that accumulated notifications cause material harm."},"stakeholder_pull":{"score":2,"rationale":"Recipients, workspace owners, and governance stakeholders are identifiable, but the sealed candidate reports no expressed demand, adoption inquiry, cleanup behavior data, or willingness to accept lifecycle cues and governed retention."},"incremental_advantage":{"score":4,"rationale":"Relative to filters, search, grouping, and manual archive, the proposed source-state mismatch detection, explicit authority states, reversible routing, and dependency-gated deletion directly address obsolete apparent actionability; whether these mechanisms improve outcomes remains untested."},"distinctiveness_plausibility":{"score":3,"rationale":"The integrated composition is specifically differentiated from the stated nearest rival, but prior art is explicitly unsearched, so distinctiveness beyond that constructed comparison is uncertain."},"technical_implementability":{"score":3,"rationale":"Metadata classification, labels, reversible archive suggestions, quarantine, and restoration are technically bounded concepts, but source-state coverage, cross-system linking, dependency detection, and classification reliability are unvalidated."},"adoption_authority_feasibility":{"score":4,"rationale":"The packet separates user organization authority, product-rule authority, records/privacy approval, and legal or safety holds, and it defines a consent-based first step; coordination across those authorities may still delay adoption."},"evidence_readiness":{"score":3,"rationale":"A four-week shadow pilot, baseline comparison, falsifiers, exclusions, and rollback conditions are specified, but acceptance tolerances, source coverage, measurement procedures, and observed baseline rates are absent."},"safety_net_benefit":{"score":5,"rationale":"The proposal explicitly preserves recoverable history through reversible archive and quarantine paths, excludes permanent deletion and protected alerts from the pilot, respects holds, and provides concrete halt and restoration conditions."},"scalability":{"score":3,"rationale":"The lifecycle framework could apply across notification classes, but scaling requires class-specific rules, reliable source integrations, accessibility validation, and organization-specific retention and authority policies."}},"score_confidence":"MODERATE","costs":{"first_evidence":{"band_2026_usd":"50K_TO_250K","scope":"Prepare and run the specified four-week, one-team shadow pilot using copied notification metadata, prototype lifecycle labels and reversible archive suggestions, baseline comparison, consent, safety review, and outcome analysis.","confidence":"MODERATE","assumptions":["One cooperative team and one notification environment are included.","Existing metadata can be copied and linked to source state without major platform reconstruction.","No permanent deletion or safety-critical alert suppression occurs.","Labor includes product, engineering, design/research, data analysis, accessibility, privacy, and partner coordination."]},"initial_deployment_startup":{"band_2026_usd":"250K_TO_1M","scope":"Build a limited production-capable implementation for one product or workspace class, including source-state integration, lifecycle taxonomy, user controls, audit evidence, quarantine/restoration, accessibility work, and governance configuration.","confidence":"LOW","assumptions":["Deployment is limited to a small number of notification classes and source systems.","Existing archive, search, identity, and audit infrastructure can be extended.","Records and privacy requirements do not require a new enterprise-wide retention platform.","Safety-critical classes remain excluded until separately validated."]},"operational_launch":{"band_2026_usd":"1M_TO_5M","scope":"Launch across multiple notification classes and organizational workspaces with production reliability, migration, monitoring, support, administrator controls, policy review, accessibility validation, and evaluation of missed-alert and restoration outcomes.","confidence":"LOW","assumptions":["Multiple source-system connectors and policy variants are required.","The product already has scalable notification, archive, and search services.","Launch includes staged rollout rather than universal simultaneous activation.","No claim is made about exact organization size or integration count."]},"annual_recurring":{"band_2026_usd":"250K_TO_1M","scope":"Maintain source integrations and lifecycle rules, monitor classification and missed-alert failures, administer holds and retention changes, support restoration, conduct accessibility and policy reviews, and operate user support.","confidence":"LOW","assumptions":["Recurring work covers one established product with several notification classes.","Rule drift and source-schema changes require continuing engineering and governance labor.","Storage growth is moderate because archival history remains searchable.","Major new source platforms or regulatory redesigns are excluded."]}},"research_burden":"HIGH","earliest_credible_horizon":"3_TO_12_MONTHS","pipeline_gates":{"recognizable_externally_supportable_problem":{"status":"YES","reason":"The candidate specifies observable stale-state cohorts, obsolete actionable styling, unclear ownership, task-finding burden, and mistaken-action risk, together with a separate problem falsifier; actual prevalence remains to be measured."},"identifiable_adopter_or_authorizer":{"status":"YES","reason":"Notification recipients and a consenting team are identifiable adopters, while the workspace product owner, administrators, records/privacy authorities, and legal or safety authorities have explicitly divided authorization roles."},"distinct_testable_incremental_claim":{"status":"YES","reason":"The proposal can be compared with the ordinary chronological read/unread baseline and the stated filter/search/manual-archive rival on stale-card selections, current-task identification time, missed valid alerts, restoration failures, and cue comprehension."},"bounded_next_evidence_step":{"status":"YES","reason":"The sealed candidate authorizes a four-week, one-team shadow pilot using copied metadata, prototype labels, and reversible archive suggestions without permanent deletion, with explicit intervention and safety falsifiers."},"no_unresolved_safety_or_authority_stop":{"status":"YES","reason":"Protected alerts, permanent deletion, unauthorized record removal, and hold overrides are excluded; consent, divided authority, halt triggers, rule disablement, and restoration are specified for the first step."},"implementation_cost_scope_and_range":{"status":"UNCERTAIN","reason":"The candidate identifies needed components and stakeholders but does not specify notification volume, source-system count, existing archive capabilities, integration quality, retention regimes, or organizational rollout scale, so only broad assumption-dependent cost ranges are supportable."}},"blocking_evidence":["No representative evidence shows that accumulated old notifications increase task-identification time, errors, or mistaken actions.","Source systems' coverage and accuracy for detecting current, stale, superseded, or unresolved states are unknown.","Lifecycle-label comprehension, missed-valid-alert rates, restoration reliability, and acceptable tolerances have not been established.","Stakeholder demand and willingness to authorize source-linked lifecycle rules are untested.","Prior art is unsearched, preventing a supported distinctiveness claim.","Implementation scope is insufficiently specified for confident deployment and recurring-cost estimates."],"next_evidence_step":"Predeclare thresholds for source-state coverage, label disagreement, stale-card selection, current-task identification time, missed valid alerts, cue misunderstanding, and restoration failure; then run the authorized four-week one-team shadow pilot comparing the ordinary notification presentation with prototype stale/superseded labels and reversible archive suggestions on copied metadata. Falsify advancement if the prototype fails to improve stale selection or task-identification outcomes, or exceeds the declared safety and comprehension tolerances.","research_questions":["Do representative accumulated-notification cohorts measurably increase current-task identification time, errors, or stale actions compared with a low-staleness condition?","What proportion of cards can be linked to sufficiently current and authoritative source state, and where do systems or human reviewers disagree?","Compared with ordinary presentation and manual archive controls, do lifecycle cues reduce stale-card selections without increasing missed valid alerts or unresolved-work concealment?","Can users, including users with accessibility needs, correctly understand stale, superseded, archived, and review states and reliably retrieve or restore history?","Which notification classes, dependencies, holds, and retention rules require exception handling or prohibit automated demotion and deletion?","Does scoped prior-art research identify substantially equivalent source-aware lifecycle, governed expiry, and reversible disposition mechanisms?","Will product owners, administrators, records/privacy authorities, and users authorize and adopt the rules under the measured tradeoffs?","What source count, notification volume, integration work, and governance obligations determine credible deployment and recurring-cost ranges?"] ,"recommendation":"VALIDATE_PROBLEM_FIRST","uncertainty_constraints":["Closed-book assessment: no external evidence was consulted.","Problem prevalence, effect size, stakeholder demand, market size, realized impact, and prior art are unmeasured.","Cost bands are resource-equivalent ranges based only on the candidate's stated pilot and system components, not vendor quotes or observed implementation data.","Technical feasibility depends on source-state availability, integration coverage, and organization-specific retention and authority rules.","The recommendation concerns reversible evidence generation and does not authorize live automated suppression or permanent deletion."],"closed_book_prior_art_boundary":"Prior art is explicitly unsearched. This assessment recognizes only the candidate's internal comparison with filters, search, grouping, and manual archive; it makes no claim about novelty, existing implementations, prevalence, or competitive differentiation in the external world."}