{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp12_substrate_denial72_20260805","cell_id":"modular_decomposition__computer_science","arm":"ORDINARY_MAX","candidate_id":"modular_decomposition__computer_science__ORDINARY_MAX","proposal_index":1,"version":0,"title":"Shadow-first decomposition of authorization logic across application execution paths","problem":"In a legacy multi-tenant SaaS application, one authorization rule—such as whether a suspended account may start or retrieve a data export—is separately encoded in HTTP handlers, background workers, query builders, and audit code. Each location mixes context collection, policy interpretation, enforcement, and evidence generation. A rule change therefore requires whole-path reasoning, while a missed or differently interpreted copy can produce inconsistent decisions.","actors":["Application maintainers","Security policy owner","Feature teams operating HTTP and background-processing paths","Site reliability engineers","Privacy or compliance reviewer","Tenant administrators and users subject to authorization decisions"],"observable_state":"For the selected export rule, a change-impact trace shows the same subject-action-resource predicate or its equivalent in multiple execution paths owned by different maintainers. The paths construct authorization context differently, emit different decision reasons, and require edits or broad review when the policy meaning changes. Replaying an equivalent request through HTTP, queued-job, and scheduled-job paths can expose whether their decisions and audit evidence agree.","consequence":"Policy changes can retain an obsolete interpretation in one path, require unrelated components to be reviewed together, or produce decisions whose rationale cannot be reconciled across execution modes. This impairs safe policy evolution, accountability, and confidence that the composed application enforces one policy meaning.","affected_objective":"Preserve one adjudicated authorization meaning and complete audit evidence across request, job, and data-access paths while making a bounded policy change locally understandable, testable, and owned.","intervention":"Treat the application's existing authorization behavior as the entangled whole and decompose it inside the current deployable. Create execution-channel context adapters, capability-aligned policy modules, a small decision kernel, enforcement adapters, and an audit-evidence module. All paths submit a normalized AuthorizationRequest containing subject, action, resource, tenant, and relevant state and receive a Decision containing allow or deny, reason, policy version, and obligations. Policy modules own rule meaning; adapters may translate local context but may not reinterpret decisions. Internal rule representation is encapsulated. Named stewards own each module and the shared contract. Cross-path conformance tests, shadow decision comparison, and whole-workflow tests provide the reintegration policy. The first pilot covers only the export rule and does not create a network service or affect production enforcement.","structural_mapping":[{"archetype_element":"Entangled whole","domain_realization":"Authorization context gathering, rule interpretation, enforcement, and auditing are interleaved and duplicated across HTTP, queued-job, scheduled-job, and query code."},{"archetype_element":"Cohesive responsibility identification","domain_realization":"Separate responsibilities that change for different reasons: channel-specific context acquisition, capability-specific policy meaning, decision semantics, local enforcement, and audit evidence."},{"archetype_element":"Module boundary","domain_realization":"Package-level boundaries inside the existing application distinguish context adapters, export-policy rules, the decision kernel, enforcement adapters, and audit recording."},{"archetype_element":"Responsibility partitioning","domain_realization":"The export-policy module owns whether an action is authorized; channel adapters own trustworthy fact translation; enforcement adapters own applying the returned decision; the audit module owns durable evidence."},{"archetype_element":"Interface contract","domain_realization":"Every execution path exchanges a normalized AuthorizationRequest and a versioned Decision rather than calling or reproducing internal rule predicates."},{"archetype_element":"Encapsulation","domain_realization":"Rule tables, precedence, and exception handling remain inside the policy module, while transport, queue, and database details remain inside their adapters."},{"archetype_element":"Module granularity","domain_realization":"The pilot uses one capability-level policy module rather than one module per rule or one monolithic module for all application policy; the boundary is reconsidered if handoffs exceed the local reasoning gain."},{"archetype_element":"Module stewardship","domain_realization":"A security-policy steward owns rule semantics, channel maintainers own adapters, and an application owner owns the shared contract and integration suite."},{"archetype_element":"Integration policy","domain_realization":"Contract validation, cross-channel replay, deny-by-default checks, audit-completeness assertions, and selected end-to-end workflows verify that locally valid modules still compose into consistent enforcement."}],"mechanism_mapping":[{"mechanism_slug":"software_module_decomposition","role":"Turns one cross-cutting authorization implementation into bounded in-process packages with enforceable dependency directions.","counterfactual_removal":"If code is merely relabeled or moved into folders without dependency restrictions, callers can continue reaching into rule internals and the change surface remains entangled."},{"mechanism_slug":"change_reason_partitioning","role":"Places policy meaning, channel translation, enforcement, and auditing in separate modules because each changes under different authority and for different reasons.","counterfactual_removal":"If boundaries follow existing directories or teams instead of responsibility and change reason, the same policy edit will still cross unrelated units."},{"mechanism_slug":"authorization_request_decision_contract","role":"Provides the bounded interaction surface through which all execution paths request a decision without knowing policy internals.","counterfactual_removal":"Without a common request and decision contract, each adapter must know rule details and will remain another policy implementation."},{"mechanism_slug":"encapsulation_with_dependency_checks","role":"Prevents enforcement and context adapters from importing internal predicates or data structures from the policy module.","counterfactual_removal":"Without encapsulation checks, hidden coupling can reappear even if the architecture diagram retains module boxes."},{"mechanism_slug":"cross_path_compatibility_replay","role":"Reintegrates the modules by checking adjudicated decision and audit invariants across HTTP and background paths.","counterfactual_removal":"Without compatibility replay, each module can pass local tests while the composed paths produce different authorization outcomes."},{"mechanism_slug":"module_and_interface_stewardship","role":"Assigns authority for policy modules, adapters, and the shared boundary, including resolution of cross-module defects.","counterfactual_removal":"Without stewards, contract changes and failures at module boundaries have no accountable decision path."}],"causal_chain":["The same authorization responsibility is currently mixed with transport, scheduling, persistence, and audit concerns in several execution paths.","Because those concerns change under different triggers, a policy edit requires maintainers to inspect and coordinate across otherwise unrelated components.","Duplicated predicates and path-specific context construction create hidden coupling and allow interpretations to drift.","A dependency and change-reason map identifies policy meaning, context translation, enforcement, and evidence as distinct cohesive responsibilities.","Package boundaries and dependency rules make those responsibilities locally owned and prevent adapters from importing policy internals.","The normalized request and decision contract limits what must cross each boundary while preserving the facts and obligations needed by the whole application.","A policy-only mutation can then be attempted inside the capability module without changing channel adapters; failure to do so reveals a misplaced boundary or leaky contract.","Cross-path replay and whole-workflow tests check that local changes still compose into adjudicated decisions, enforcement behavior, and audit evidence.","If edits remain local and composed behavior remains equivalent, the pilot supports the decomposition hypothesis; if coordination or contract churn remains broad, it rejects or redirects it."],"baseline":"Keep the existing inline and helper-based authorization checks in their HTTP handlers, workers, queries, and audit paths, relying on broad code review plus current unit and end-to-end tests. Before the pilot, record for the selected rule which files, components, and owners a test-only rule mutation reaches; which context facts each path uses; and whether a fixed case set yields matching decisions, reasons, and audit records.","nearest_rivals":["Retain the current structure and add characterization or generated regression tests. This may be preferable when rule changes are rare and the principal problem is undetected regression, but it does not itself assign coherent ownership or reduce the edit surface.","Route authorization through one global middleware or gateway. This offers a single choke point when every protected action passes through it, but background jobs and direct data operations may lack that choke point, and middleware alone does not partition context, policy, enforcement, and evidence responsibilities.","Move policy to a centralized policy-as-code service. This may be preferable when multiple independently deployed applications need one shared policy authority, but it changes deployment and failure topology beyond the proposed in-process decomposition.","Document rules and assign repository ownership without changing code boundaries. This can clarify reviewers at low implementation cost, but ownership remains coupled if one semantic change still requires edits across several execution paths.","Rewrite the full authorization subsystem. This may be warranted if existing semantics cannot be adjudicated incrementally, but it requires a broader evidence and authority basis than the single-rule extraction proposed here."],"remaining_contrastive_claim":"Holding policy meaning and deployment topology constant, responsibility-aligned in-process decomposition plus an explicit request-decision contract should allow a test-only change to the selected export rule to remain within its policy module and fixtures while all three execution paths preserve adjudicated decisions and audit obligations. Tests-only can detect drift without localizing responsibility, and gateway middleware cannot provide the same result when no universal execution choke point exists. The claim fails if the mutation still requires adapter or contract changes unrelated to new information needs.","authority_safety":{"decision_authority":"The application service owner controls code and deployment boundaries; the designated security policy owner controls rule meaning; both must approve the module contract and any production trial. A privacy or compliance reviewer must approve any use of recorded authorization traces.","authorized_first_step":"A maintainer may perform a read-only dependency map and build an isolated, nonproduction, shadow-only prototype for the single export rule using synthetic or approved redacted cases. The shadow result may be logged for comparison but cannot influence an actual authorization decision.","excluded_actions":["Changing the substantive allow-or-deny policy","Replacing production enforcement","Creating a network-accessible authorization service","Automatically denying or granting user actions from shadow output","Copying raw credentials, tokens, export contents, or unnecessary personal data into replay fixtures","Refactoring unrelated capabilities or execution paths","Treating baseline behavior as correct where the policy owner has not adjudicated a disagreement"],"halt_rollback":"Stop before production integration if the shadow evaluator permits an adjudicated denial, denies an adjudicated allowance, cannot produce required audit obligations, requires sensitive data outside the approved fixture, or expands beyond the selected capability. Disable the prototype flag and remove the isolated shadow call path; the existing enforcement path remains the sole authority throughout the pilot."},"negative_tests":{"strongest_counterevidence":"The apparently duplicated rule may conceal genuinely channel-specific semantics: an interactive export request and a delayed scheduled export may require different freshness, delegation, or revocation rules. If those differences dominate, one capability policy module would create false cohesion and a swollen contract rather than useful locality.","problem_falsifier":"The problem hypothesis is falsified if the selected rule already has one coherent implementation and steward, policy changes do not require unrelated execution-path edits, equivalent cases produce reconciled decisions and evidence, and observed delay instead comes from unresolved policy language or an unavailable test environment.","intervention_falsifier":"The intervention is falsified for this slice if a test-only policy mutation necessarily changes multiple channel adapters or the shared schema despite requiring no new context, if dependency checks cannot prevent direct rule access, or if adjudicated replay cases cease to compose into equivalent enforcement and audit results.","risks":["A boundary chosen from one rule may not fit other capabilities.","A normalized request may omit a security-relevant fact or become an unbounded bag of channel details.","Matching existing behavior can preserve an existing policy defect unless disagreements are adjudicated.","Dual-running implementations can drift during the pilot.","Shadow logs can expose sensitive identity, tenant, or resource metadata.","Extra module calls and validation can add latency or operational complexity.","Capability ownership can become a silo and obscure cross-policy invariants.","Prematurely stabilized contracts can ossify an incorrect decomposition.","A deny-by-default fallback can be mistaken for a complete safety argument even when enforcement paths can bypass the evaluator."]},"next_evidence_step":"On an isolated branch, select exactly the rule \"a suspended tenant account may not start or retrieve a data export\" and three paths: an HTTP request, a queued export worker, and a scheduled export. Map their predicates, inputs, owners, and audit outputs; then implement one normalized request-decision contract, one export-policy module, and three shadow adapters. Replay a fixed matrix of 24 synthetic cases spanning account state, actor role, resource ownership, and execution path; have the policy owner adjudicate any baseline disagreement. Apply one test-only semantic mutation and record which modules, interfaces, tests, and owners must change. Continue only if the mutation remains inside the policy module and fixtures, every adjudicated case yields the required decision and audit obligations through all three adapters, and no unapproved sensitive data is needed; otherwise reject or redraw the boundary.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"No comparison with prior proposals was performed because runtime isolation forbids inspecting them. Within the supplied inputs, this candidate is distinguished by targeting authorization-rule drift across synchronous and asynchronous execution paths, retaining one deployable, and making cross-path shadow equivalence the reintegration test.","revision_record":{"parent_version":null,"progress_targets_addressed":["Initial complete candidate constructed from the supplied modular-decomposition archetype and computer-science domain card."],"conceptual_changes":["Established cross-path authorization-rule entanglement as the concrete target problem and capability-level decomposition as the proposed boundary."],"operational_changes":["Defined an in-process, shadow-only, single-rule pilot with responsibility ownership, dependency restrictions, safeguards, and rollback."],"evidence_changes":["Specified a bounded dependency-map, synthetic replay, adjudication, and test-only mutation study; no evidence has yet been collected."],"claim_changes":["Limited the claim to a falsifiable contrast with tests-only and middleware baselines and made no novelty, prevalence, demand, or effect-size claim."]}}