{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","cell_id":"modular_decomposition__computer_science","arm":"BREADTH_PROBE_ONE_SHOT","candidate_id":"modular_decomposition__computer_science__P1","proposal_index":1,"version":0,"title":"Responsibility-Bounded Processing for Machine-Learning Data-Deletion Requests","problem":"A machine-learning platform processes a person's data-deletion request through one monolithic worker that resolves identities, traverses dataset and model lineage, determines affected artifacts, schedules remediation, and produces an audit record. These responsibilities use different expertise and change for different reasons, yet share internal state and control flow. Consequently, modifying an identity-matching rule or lineage representation requires broad review and can accidentally alter remediation scheduling or audit conclusions.","actors":["Privacy operations analyst who submits and monitors deletion requests","Identity engineer responsible for matching subjects to stored records","Data-platform engineer responsible for dataset and artifact lineage","Machine-learning engineer responsible for model remediation decisions","Compliance reviewer responsible for the final evidence record","Platform engineering lead responsible for the deletion processor"],"observable_state":"Repository inspection and change history show the same worker, shared data structures, or shared database writes being modified for identity matching, lineage traversal, remediation planning, and audit rendering; unit tests cannot exercise these responsibilities independently; and failures are usually discovered only in end-to-end deletion runs.","consequence":"A localized rule or schema change has an unpredictable blast radius, ownership of defects is ambiguous, and a request can report completion even when the identity, lineage, remediation, and audit stages do not agree about what was processed.","affected_objective":"Maintain a deletion workflow whose intermediate decisions are inspectable, whose local rules can change without reopening unrelated logic, and whose final completion claim remains consistent with the work actually planned and recorded.","intervention":"Apply Software Module Decomposition to partition the monolithic worker into four responsibility-coherent modules: Subject Resolution, Artifact-Lineage Closure, Remediation Planning, and Completion Evidence. Give each module a steward and encapsulated internal representation. Connect them through versioned contracts carrying a subject-set manifest, an affected-artifact manifest, a remediation plan, and an evidence bundle. Establish an integration policy that checks manifest identities, lineage snapshot versions, artifact coverage, and the invariant that no request is marked complete unless every affected artifact has a recorded disposition.","structural_mapping":[{"archetype_element":"Entangled whole","domain_realization":"The single deletion worker in which identity matching, lineage traversal, remediation selection, and audit production share control flow and mutable state."},{"archetype_element":"Responsibility partitioning","domain_realization":"Four modules own distinct change reasons: resolving subjects, computing lineage closure, selecting artifact dispositions, and assembling completion evidence."},{"archetype_element":"Module boundary","domain_realization":"A stage may read its declared input manifest and local stores but may not mutate another stage's internal records or infer completion from undocumented shared state."},{"archetype_element":"Interface contract","domain_realization":"Versioned manifests specify request ID, input snapshot, item identifiers, decision status, reason codes, and provenance for each handoff."},{"archetype_element":"Encapsulation","domain_realization":"Matching heuristics, graph-traversal algorithms, remediation policy tables, and evidence formatting remain private to their respective modules."},{"archetype_element":"Module steward","domain_realization":"Named engineering owners approve local changes and maintain each contract endpoint; the platform lead stewards cross-module invariants."},{"archetype_element":"Integration policy and compatibility check","domain_realization":"Contract tests and replayed workflow tests reject missing identifiers, incompatible schema versions, stale lineage snapshots, or affected artifacts without dispositions."},{"archetype_element":"System-level coherence","domain_realization":"The modules compose into one traceable request whose completion evidence corresponds to the resolved subjects, lineage closure, and remediation plan."}],"mechanism_mapping":[{"mechanism_slug":"software_module_decomposition","role":"Creates code and ownership units around the four cohesive responsibilities rather than around incidental workflow steps or folders.","counterfactual_removal":"If the worker remains one implementation unit, shared representations and change paths continue to require whole-system reasoning even if documentation labels the stages."},{"mechanism_slug":"define_interfaces_and_handoffs","role":"Makes each stage's admissible inputs, outputs, provenance, and rejection conditions explicit through versioned manifests.","counterfactual_removal":"Without explicit handoffs, dependencies remain hidden in shared tables or call-stack assumptions, so the apparent modules cannot be tested or changed independently."},{"mechanism_slug":"establish_reintegration_policy","role":"Uses compatibility checks and a completion invariant to verify that locally valid outputs still form a coherent deletion record.","counterfactual_removal":"Without reintegration checks, all modules could pass local tests while the final evidence omits an affected artifact or refers to a different lineage snapshot."}],"causal_chain":["Distinct responsibilities are currently coupled through shared state and monolithic control flow.","Partitioning by coherent responsibility places rules that change together inside the same module.","Versioned manifests limit and expose what crosses each module boundary.","Encapsulation prevents local heuristics and representations from becoming dependencies of unrelated stages.","Named stewardship makes local defects and contract maintenance assignable while integration checks retain shared invariants.","Local changes can then be evaluated within one responsibility boundary, while whole-workflow replay verifies that the final completion evidence still composes correctly."],"baseline":"Retain the monolithic deletion worker, shared internal data model, broad code review, and end-to-end test suite, with operators manually investigating disagreements among intermediate logs and the final status.","nearest_rivals":["Extract helper functions or reorganize folders while retaining shared state, shared ownership, and the same monolithic completion logic.","Place an API façade around the existing worker, stabilizing external invocation without partitioning its internal responsibilities.","Connect the existing stages with an event bus, which changes transport but does not by itself establish coherent ownership, bounded schemas, or a completion invariant.","Apply bulkhead resource isolation so expensive lineage or remediation work cannot exhaust the worker pool; this contains operational failure but does not address reasoning and change-path entanglement."],"remaining_contrastive_claim":"The candidate differs from cosmetic refactoring, an API façade, transport decoupling, and resource isolation because it jointly relocates responsibility, internal state, ownership, and tests behind four boundaries, then requires explicit contracts and a cross-module completion invariant. Its testable contribution is tractability of local change without surrendering agreement among the workflow's outputs, not merely separate deployment or failure containment.","authority_safety":{"decision_authority":"The platform engineering lead may authorize a non-production prototype and shadow replay; privacy, data, and compliance owners retain authority over production deletion policy, data access, remediation, and completion criteria.","authorized_first_step":"Create contract stubs and extract only Subject Resolution behind an adapter in a disposable branch, then replay sanitized or synthetic requests without changing production execution or status records.","excluded_actions":["Deleting or modifying production records","Triggering production model retraining or artifact removal","Changing the legal or organizational definition of deletion completion","Exposing direct identifiers or unrestricted production lineage data","Deploying the prototype into the production request path"],"halt_rollback":"Stop if the adapter changes resolved subject sets, loses provenance, requires undeclared shared-state access, or prevents exact comparison with the baseline. Roll back by discarding the prototype branch and replay artifacts; the production worker remains unchanged."},"negative_tests":{"strongest_counterevidence":"A dependency trace shows that identity resolution, lineage closure, remediation selection, and evidence production must routinely co-design and atomically mutate the same representation, so proposed boundaries introduce more coordination and consistency burden than local reasoning benefit.","problem_falsifier":"For a bounded sample of recent changes and failures, each responsibility is already independently owned, tested, and changed through an explicit stable handoff, with no broad review, shared-state dependency, or cross-responsibility defect ambiguity.","intervention_falsifier":"In shadow replay, extracting Subject Resolution still requires unrelated remediation or evidence changes, or contract and handoff work exceeds the reviewed surface needed for equivalent changes in the monolith without improving independent testability.","risks":["A manifest may conceal semantically important coupling while appearing structurally complete.","Premature contract stability may preserve an incorrect identity or lineage model.","Additional handoffs may increase latency, storage, and operational debugging burden.","Local owners may optimize their modules while neglecting request-level completion semantics.","Dual-running prototype and baseline logic may expose sensitive identifiers unless replay data are sanitized.","Too-fine granularity may replace code complexity with schema-version and coordination complexity."]},"next_evidence_step":"Using at most 20 sanitized or synthetic deletion traces and five representative change scenarios, map reads, writes, decisions, owners, and cross-responsibility dependencies in the current worker. Prototype the Subject Resolution contract and adapter, then compare whether its tests can run without initializing lineage, remediation, or evidence internals and whether the unchanged downstream path reproduces the baseline manifests exactly. Record undeclared dependencies, contract exceptions, review surface, and integration mismatches; do not deploy or infer an effect size from this bounded exercise.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"No other proposals or experiment candidates were inspected under runtime isolation; this one-shot candidate is grounded only in the supplied modular-decomposition archetype and computer-science domain card.","revision_record":{"parent_version":null,"progress_targets_addressed":["Initial one-shot construction from the supplied archetype and domain record","Concrete domain problem with observable entanglement","Causal preservation of responsibility boundaries, contracts, encapsulation, stewardship, and reintegration","Bounded authority, safeguards, falsifiers, and first evidence step"],"conceptual_changes":[],"operational_changes":[],"evidence_changes":[],"claim_changes":[]}}