{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","research_id":"eoa_inverse_innovation_exp09_light_prior_art_20260804","cell_id":"formal_derivation_system_design__computer_science","search_lanes":{"direct_problem_and_intervention":{"queries":["\"release admissibility\" certificate policy as code proof","software deployment approval machine-checkable proof certificate","machine-checkable release policy deployment authorization"],"source_ids":["SRC1","SRC2","SRC3","SRC4"],"no_result_note":null},"synonyms_and_historical_terms":{"queries":["software release governance automated controls audit trail","deployment authorization policy decision provenance explainable","proof-carrying authentication authorization policy proof checker"],"source_ids":["SRC2","SRC3","SRC4"],"no_result_note":null},"products_practices_and_standards":{"queries":["OPA policy language decision logs official","GitLab deployment approvals protected environments history","CI/CD release policy exceptions audit trail deployment approval standard"],"source_ids":["SRC1","SRC2","SRC3"],"no_result_note":null},"component_combination":{"queries":["policy as code proof explanation decision trace exceptions","supply chain attestations policy engine deployment authorization","machine-checkable policy proof tree software release","proof-carrying authorization distributed policy credentials"],"source_ids":["SRC1","SRC2","SRC3","SRC4"],"no_result_note":null}},"sources":[{"source_id":"SRC1","title":"Policy Language","publisher":"Open Policy Agent","url":"https://www.openpolicyagent.org/docs/policy-language","source_type":"FIRST_PARTY_PRODUCT","claims_supported":["OPA's declarative Rego language evaluates structured data using explicit rules and formally documented syntax.","Rego already supplies much of the proposed policy-as-code rule layer, including unambiguous queries, undefined results, schemas, conflicts, and rule metadata."]},{"source_id":"SRC2","title":"Decision Logs","publisher":"Open Policy Agent","url":"https://www.openpolicyagent.org/docs/management-decision-logs","source_type":"FIRST_PARTY_PRODUCT","claims_supported":["OPA decision logs can preserve policy inputs, results, decision identifiers, evaluated-rule identifiers, policy-bundle revisions, timestamps, and nondeterministic values intended for replay.","This is established prior art for version-correlated policy audit and offline debugging, though the documented log is not itself a proof submitted to an independent proof checker.","The documentation identifies sensitive policy inputs as a concern and provides masking and erasure mechanisms."]},{"source_id":"SRC3","title":"Deployment approvals","publisher":"GitLab","url":"https://docs.gitlab.com/ci/environments/deployment_approvals/","source_type":"FIRST_PARTY_PRODUCT","claims_supported":["GitLab supports rule-based approvals for deployments to protected environments, including multiple approver groups and blocked deployment states.","The product records approval status, eligible approvers, required and granted approval counts, approver identities, and approval or rejection history.","Approval does not automatically execute deployment, demonstrating an established separation between gate satisfaction and deployment authority."]},{"source_id":"SRC4","title":"Proof-carrying authentication","publisher":"Princeton University","url":"https://collaborate.princeton.edu/en/publications/proof-carrying-authentication/","source_type":"PRIMARY_RESEARCH","claims_supported":["Appel and Felten reported an implemented distributed authorization framework based on higher-order logic.","The framework requires users to submit proofs with authorization requests and emphasizes simple proof checking.","This directly anticipates the proposal's core pattern of attaching a machine-checkable logical certificate to a request for permission."]}],"problem_evidence":{"status":"PARTLY_SUPPORTED","finding":"The sources make the structural problem visible: production-deployment approval can involve configured approval rules and human approval history, while a separate policy engine evaluates structured facts and separately logs inputs, results, rule identifiers, and bundle revisions. Earlier proof-carrying-authorization research also addresses distributed authorization through submitted proofs. However, the retained sources do not demonstrate that two release operators commonly disagree on identical evidence or quantify failures to reconstruct historical release decisions.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"closest_prior_art":[{"name":"Proof-carrying authentication and authorization","source_ids":["SRC4"],"overlap":"A distributed authorization request is accompanied by a proof under an explicit logic, and proof checking is designed to be simple. This substantially overlaps the proposed formal inference system, submitted admissibility certificate, and independent mechanical checker.","remaining_difference":"The retained research is about general authentication and authorization, not a release-specific calculus that standardizes CI evidence, artifact identities, service ownership, scoped and expiring exceptions, contradictory inputs, policy-version regression, and human escalation."},{"name":"OPA policy evaluation with decision logs","source_ids":["SRC1","SRC2"],"overlap":"Explicit declarative rules evaluate structured external input, support undefined and conflicting outcomes, and produce audit records tied to policy-bundle revisions, evaluated rules, inputs, and results.","remaining_difference":"The retained documentation establishes decision records and replay support, not a portable proof object whose every inference can be checked independently of the evaluator or a release-specific treatment of malformed, expired, contradictory, and out-of-scope evidence."},{"name":"GitLab protected-environment deployment approvals","source_ids":["SRC3"],"overlap":"Configured approval rules gate production deployments, preserve approval and rejection history, expose blocked status, and keep approval distinct from execution.","remaining_difference":"The documented gate records approvals and status but does not provide a rule-complete derivation integrating heterogeneous machine evidence, exception scope, contradictions, and policy counterfactuals."}],"prior_art_disposition":"SUBSTANTIAL_COLLISION","contrastive_claim_remaining":"In a heterogeneous, exception-bearing release workflow, a release-specific calculus layered beyond proof-carrying authorization and ordinary policy-engine logs will let an independent reviewer reproduce and localize malformed premises, scoped or expired exceptions, contradictory evidence, and policy-version counterfactuals more completely than an implementation assembled from the closest existing mechanisms.","contrastive_claim_falsifier":"Using an existing proof-carrying-authorization or OPA-based implementation with deployment-approval records, an independent reviewer can reproduce every sampled release outcome, identify every premise and rule used, distinguish missing, malformed, contradictory, expired, and out-of-scope evidence, and predict the tested policy-version counterfactuals without adding a distinct release-admissibility calculus or certificate format.","gates":{"adequate_source_search":{"status":"PASS","rationale":"The bounded search covered direct terminology, synonyms and older proof-carrying terminology, current policy and deployment products, and combinations of policy evaluation, proof checking, decision provenance, and approval gates. Exactly four opened direct sources from three publishers were retained, including peer-reviewed primary research and first-party documentation.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"supported_problem":{"status":"PASS","rationale":"The component-level fragmentation is visible across deployment approvals, structured policy evaluation, and separate decision logging. Evidence for actual operator disagreement and its prevalence is absent, so the problem is only partly supported.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"distinct_testable_claim":{"status":"PASS","rationale":"After accounting for proof-carrying authorization, the remaining claim is narrowly about whether release-specific evidence and exception semantics improve independent reconstruction and localization over adaptations of established mechanisms; both success and falsification observations are specified.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"bounded_next_test":{"status":"PASS","rationale":"An offline replay of 12 releases for one service can compare an implementation based on existing OPA or proof-carrying mechanisms with the proposed release-specific calculus on verdict reproduction, premise localization, exception handling, contradiction handling, and policy-version counterfactuals without changing production controls.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"no_obvious_safety_or_authority_stop":{"status":"PASS","rationale":"The proposed shadow evaluation has no deployment credentials or enforcement hooks and preserves the authorized release manager's decision. Existing deployment practice also demonstrates that approval can remain separate from execution. Sensitive inputs and certificates require access control or masking, but this is a manageable test constraint rather than an obvious stop.","source_ids":["SRC2","SRC3"]}},"screen_survival":false,"world_novelty_boundary":"This bounded public-web screen found substantial conceptual collision with proof-carrying authorization and adjacent product mechanisms for policy evaluation, decision replay, and deployment approval. It cannot establish world novelty, patentability, market size, expert acceptance, problem prevalence, effect size, or realized operational value."}