{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","cell_id":"formal_derivation_system_design__computer_science","arm":"BREADTH_PROBE_ONE_SHOT","candidate_id":"formal_derivation_system_design__computer_science__P1","proposal_index":1,"version":0,"title":"Machine-Checkable Release Admissibility Certificates","problem":"A software organization decides whether a production release is admissible using conditions scattered across CI configuration, service-ownership files, security exceptions, dependency dashboards, and reviewer judgment. Because the vocabulary, valid condition forms, starting assumptions, and permissible inference moves are not separately specified, two release operators can reach different decisions from the same evidence, and a later auditor cannot reconstruct why a release was permitted or blocked.","actors":["Release engineer proposing a deployment","Service owner accountable for operational readiness","Security reviewer controlling bounded exceptions","CI/CD platform supplying test and artifact evidence","Release manager holding production-deployment authority","Auditor or incident reviewer examining past decisions"],"observable_state":"For a selected release, required evidence appears across multiple systems; some conditions are represented only by scripts or prose; exceptions lack a uniform scope and expiry representation; and the final permit-or-block result has no complete, versioned derivation linking accepted evidence to the release policy in force.","consequence":"A release may be delayed by irreconcilable interpretations, permitted through an unstated assumption, or blocked without an explainable rule path. Policy changes can also alter outcomes without revealing which earlier release decisions would have differed.","affected_objective":"Reproducible, auditable, and bounded determination of whether a specific software artifact may enter a specified production environment under a named release-policy version.","intervention":"Create a bounded release-admissibility calculus. Define typed symbols for artifacts, environments, checks, attestations, owners, exceptions, scopes, and expiry times; specify a grammar for legal release-evidence statements; separate policy axioms from externally supplied facts; encode inference rules that derive prerequisite satisfaction and an admissibility certificate; and require every result to carry a machine-checkable proof tree and policy version. Treat missing, malformed, contradictory, expired, or out-of-scope evidence as distinct outcomes. Keep the calculus in shadow mode initially, and leave the production deployment decision with the authorized release manager.","structural_mapping":[{"archetype_element":"Symbol Vocabulary","domain_realization":"Typed identifiers and predicates for release artifact, target environment, test result, vulnerability status, dependency compatibility, approval, exception scope, and expiry."},{"archetype_element":"Well-Formed Expression Grammar","domain_realization":"A schema defining legal evidence claims, such as an attestation binding one artifact digest, one check type, one issuer, one result, and one validity interval."},{"archetype_element":"Axiom Base","domain_realization":"Versioned release-policy requirements, including which prerequisites are mandatory for each environment and which authorities may issue narrowly scoped exceptions."},{"archetype_element":"External Fact Gateway","domain_realization":"Adapters admit signed or provenance-tagged facts from CI, artifact storage, dependency analysis, and approval systems without treating those facts as policy axioms."},{"archetype_element":"Inference Rule Set","domain_realization":"Rules derive satisfied prerequisites, valid substitutions, applicable exceptions, unresolved conditions, contradictions, and finally release admissibility or non-derivability."},{"archetype_element":"Derivation Trace Record","domain_realization":"Each evaluation emits a proof tree identifying every fact, axiom, and rule used, plus unused conflicting evidence."},{"archetype_element":"Closure Boundary","domain_realization":"The kernel may establish derivability under the encoded policy but cannot establish that tests are empirically adequate, that an attestation is honest, or that deployment is operationally wise."},{"archetype_element":"Consistency Guardrail","domain_realization":"The evaluator detects incompatible policy clauses, mutually inconsistent evidence, cycles in prerequisite rules, and certificates that depend on expired exceptions."},{"archetype_element":"Revision and Versioning Rule","domain_realization":"Every certificate names the policy and rule-set version; proposed changes run against a fixed regression suite before activation."},{"archetype_element":"Interpretation Boundary","domain_realization":"Ambiguous service ownership, novel risk, contested evidence, and emergency context are routed to human review rather than converted into hidden inference rules."}],"mechanism_mapping":[{"mechanism_slug":"formal_grammar_specification","role":"Defines the only admissible shapes for release evidence and policy clauses, allowing malformed or underspecified claims to be rejected before reasoning begins.","counterfactual_removal":"Without the grammar, syntactically ambiguous evidence would enter the kernel and operators could silently interpret the same record differently."},{"mechanism_slug":"inference_rule_calculus","role":"Makes each transition from policy requirements and external facts to prerequisite satisfaction and release admissibility explicit.","counterfactual_removal":"Without explicit inference rules, the system would remain a collection of conditions whose final combination depends on implementation order or reviewer intuition."},{"mechanism_slug":"proof_tree_or_derivation_log","role":"Produces a versioned certificate showing exactly why the release outcome follows inside the calculus.","counterfactual_removal":"Without the derivation log, a verdict could be automated but would not be reproducible or suitable for rule-level audit."},{"mechanism_slug":"mechanical_proof_checker","role":"Independently verifies that a certificate uses well-formed premises and licensed rules under the named policy version.","counterfactual_removal":"Without checking, a defect in the certificate generator could emit apparently valid conclusions unsupported by the declared calculus."},{"mechanism_slug":"formal_system_change_control_workflow","role":"Versions policy axioms and inference rules and tests their effects on exemplar releases and expected non-derivations.","counterfactual_removal":"Without change control, a rule edit could silently invalidate old reasoning or expand the conditions under which deployment is permitted."}],"causal_chain":["Release requirements, evidence forms, and exceptions are separated into explicit policy axioms, typed external facts, and inference rules.","A well-formedness linter rejects evidence that lacks required identity, provenance, scope, or validity fields before it can influence a decision.","The rule engine derives intermediate prerequisite states only through enumerated transformations.","Contradictions, missing premises, expired exceptions, and out-of-bound questions remain explicit instead of being collapsed into a generic failure or informal override.","A proof checker validates the resulting derivation against the named calculus version.","The release manager receives a reproducible certificate or a localized non-derivation report, reducing dependence on hidden assumptions while preserving human authority over deployment.","Regression evaluation exposes how proposed axiom or rule changes would alter known release cases before those changes become active."],"baseline":"The baseline is the current release workflow: CI jobs, policy documents, approval forms, and operator review produce a final deployment decision, but the implementation code and human interpretation jointly act as an undocumented rule system. Evaluate the candidate in shadow mode against this workflow without changing deployment permissions.","nearest_rivals":["Policy-as-code engine: can evaluate encoded conditions, but may leave expression grammar, inference semantics, closure limits, and proof certificates implicit in implementation code.","Release checklist: exposes required items for human review, but does not define a rule-closed derivation from typed facts to a mechanically checkable result.","CI quality gate: blocks on configured job outcomes, but typically does not distinguish policy axioms from external facts or explain multi-step exception reasoning.","Software supply-chain attestation bundle: provides provenance-bearing evidence, but does not by itself specify which conclusions follow from that evidence under a versioned release policy."],"remaining_contrastive_claim":"If release admissibility genuinely depends on multi-step, exception-bearing reasoning, then an independently checkable, versioned derivation certificate should identify malformed premises, hidden assumptions, and rule-change consequences that a verdict-only policy engine, checklist, or CI gate does not expose. This is a testable design claim, not a claim of novelty or effect size.","authority_safety":{"decision_authority":"The release manager retains authority to deploy or withhold a release; service owners and security reviewers retain their existing authority over attestations and exceptions. The calculus may report derivability but cannot authorize production access by itself.","authorized_first_step":"Build an offline shadow evaluator for one service and replay a bounded set of historical release records without connecting it to deployment credentials or enforcement hooks.","excluded_actions":["Automatically deploy, block, roll back, or promote any artifact","Create or broaden security exceptions","Treat non-derivability as proof that a release is unsafe","Treat derivability as proof of empirical reliability, legal compliance, or operational wisdom","Modify active CI/CD policy or production access controls during the first evidence step"],"halt_rollback":"Stop the shadow evaluation if it requires unapproved sensitive data, cannot reproduce its own certificates, accepts contradictory premises, or obscures rather than localizes disagreements. Because the first step is offline, rollback consists of disabling the evaluator and retaining the unchanged operational workflow."},"negative_tests":{"strongest_counterevidence":"Operators can already reconstruct every sampled release decision from a single versioned specification and independently replay it to the same result, including scoped exceptions and explicit treatment of missing or contradictory evidence.","problem_falsifier":"In a bounded sample, disagreements arise from contested risk appetite or unreliable empirical evidence rather than from implicit grammar, assumptions, inference moves, or rule versions; formal derivation would therefore address the wrong cause.","intervention_falsifier":"The shadow calculus produces the same verdicts but cannot supply stable, independently checkable traces, cannot localize disagreements to particular premises or rules, or requires frequent unformalized overrides to match authorized decisions.","risks":["Formal derivability may be mistaken for evidence that a release is safe or useful.","Incorrect policy axioms can make wrong outcomes internally valid and more persuasive.","Evidence adapters may admit stale, forged, or artifact-mismatched facts.","Exception rules may create unintended derivation paths or privilege actors able to shape the formal vocabulary.","A large or recursive rule set may not terminate predictably or may become too difficult to review.","Encoding effort may shift attention away from improving weak tests or resolving contested governance.","Detailed certificates may expose sensitive infrastructure, vulnerability, or approval information."]},"next_evidence_step":"For one service, select 12 completed releases spanning permits, blocks, expired exceptions, missing evidence, and at least one disputed case. Encode only the policy version documented for those releases, replay each case offline, and compare the calculus result and trace with the recorded decision. Record malformed inputs, unstated premises needed for agreement, contradictory rules, unresolved interpretations, checker failures, and whether a reviewer can reproduce each result from the certificate alone. Do not infer prevalence or effect size from this bounded diagnostic.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Not assessed because runtime isolation forbids inspecting prior proposals; this candidate was derived solely from the supplied archetype and domain card.","revision_record":{"parent_version":null,"progress_targets_addressed":["One-shot generation from the supplied archetype and domain card"],"conceptual_changes":[],"operational_changes":[],"evidence_changes":[],"claim_changes":[]}}