Skip to main content

Core-Lite Admissibility Engine

Status

Canonical source repository: Admissible-Existence/core-lite

Wiki state: watching

Detail status: initial public-safe canonical detail page

Definition

Core-Lite Admissibility Engine is a canonical engine layer for applying admissibility checks, receipts, and transition outcomes in a minimal runtime form.

It connects the formalism graph to executable intake, validation, publication, or transition-gating paths.

Source Boundary

Admissible-Existence defines the formalism or engine boundary. Publisher publishes papers and public exposition. The Admissibility Wiki mirrors, relates, crosswalks, and discovers relationships.

The wiki is not the source authority for this engine.

Scope

Core-Lite Admissibility Engine applies where a repo, organization, or workflow needs a minimal governed path for evaluating transition standing and producing inspectable records.

Purpose

The purpose of Core-Lite Admissibility Engine is to prevent admissibility from remaining only conceptual when a practical execution or publication path needs a deterministic gate, receipt, or validation surface.

Core Constructs

ConstructRole
IntakeReceives proposed artifacts, bundles, or transition requests.
GateEvaluates whether a transition may proceed, deny, escalate, defer, refuse, or fail closed.
Policy referenceIdentifies the rule basis for the gate.
Evidence packetProvides data supporting or failing to support standing.
ReceiptRecords the decision path and enough context for reconstruction.
ValidatorChecks artifacts, registries, receipts, or state records.
Publication pathMakes accepted public-safe state visible when applicable.
Related FormalismRelationship
Governance-Centered and Boundary-Centered Admissibility TestingSupplies admissibility tests used by the engine.
Runtime Transition GovernanceApplies checks at execution or publication boundary.
Transition TableClassifies engine outcomes and transition posture.
Boundary ConditionsSupplies boundary satisfaction checks.
State Transition Continuity ModelSupports continuity checks across engine state changes.
Decision ContinuityPreserves decision standing across receipts and reruns.
Data ContinuityPreserves evidence and data standing across ingestion and publication.
Continuity Handoff FormalismPreserves engine state across handoffs.
Triad Governance ModelSupports role-separated governance above engine actions.

Mathematical Candidates

Status: pending source-confirmed extraction from canonical source or publication artifacts.

Proof Candidates

Status: pending source-confirmed extraction from canonical source or publication artifacts.

Validation Candidates

Status: pending source-confirmed extraction from canonical source or publication artifacts.

Validation candidates should include allow, deny, escalate, stale-state, missing-evidence, failed-publication, and receipt-reconstruction cases when public-safe source artifacts are available.

Publication Artifacts

Status: pending source-confirmed extraction.

Reference Implementations

Status: pending source-confirmed extraction.

External Crosswalk Targets

External FrameworkRelationship
GLMMay supply pre-engine declarations of claims, non-claims, scope, and composition.
EVIDEMay preserve post-engine evidence for reconstruction and audit.

These are crosswalk targets only. They do not replace canonical formalism or engine definition.

Open Questions

Which exact Admissible-Existence source file defines Core-Lite Admissibility Engine?
Which engine outcomes are canonical versus explanatory?
Which validators are source-confirmed reference implementations?
Which receipt fields are required for reconstructing engine standing?

Non-Claims

This wiki page does not define, prove, validate, or implement the engine. External framework mappings are crosswalk candidates, not equivalence decisions. A listed relationship does not imply accepted formal equivalence.