RFD-0038 — Runtime capability advertisement — what OxbinRuntime::capabilities() reports about supported AFT operators and lattice contexts

Question

RFD-0035 §14 specifies the OxbinRuntime trait surface, including fn capabilities(&self) -> RuntimeCapabilities. RFD-0037 commits to AFT as the truth-value semantic foundation, with per-standpoint world-assumption operators (OWA, CWA, LCWA, MKNF+WFS, …) and three lattice contexts (Boolean, K3, FDE). What should RuntimeCapabilities advertise, and how does artifact-runtime tier matching incorporate the truth-value framework?

A runtime that does not implement the well-founded fixpoint cannot load an artifact whose composition signature requires it. A runtime that supports only K3 refinement membership cannot load an artifact that uses cross-standpoint federation (FDE-typed queries). The Layer-1 / Layer-2 validation hooks in RFD-0035 §6–§7 need to incorporate operator-and-lattice-context capability matching alongside the existing tier-table check.

This RFD opens the design space; it does not commit answers. A dedicated design session is needed before this RFD goes to committed.

Context

The relevant surfaces:

• OxbinRuntime::capabilities() (RFD-0035 §14) — currently advertises max_tier_supported, resource bounds, feature flags. Loosely typed.
• Layer-1 validation (RFD-0035 §6) — closed-boolean, O(1): refuses artifact when max_tier_claimed > max_tier_supported.
• Layer-2 validation (RFD-0035 §6, §7) — per-section verifier; runs after Layer-1 passes. Currently covers symbol resolution, lattice acyclicity, provenance well-formedness, composition-signature consistency, tier-table consistency, doc-block well-formedness.
• AFT operators (RFD-0037 §5) — per-standpoint mode declared in the standpoint manifest entry. Maps to a specific approximator construction: OWA (identity), CWA (stratified-negation closure), LCWA (window-parameterized), MKNF+WFS (Liu-You alternating fixpoint), circumscription (via stable-model bridge).
• Lattice contexts (RFD-0037 §2) — Boolean / K3 / FDE. Each typed query, mutation, and rule has a declared context.
• Per-standpoint consistency policy (RFD-0037 §9) — strict or paraconsistent. Affects append-time invariant checking.
• Artifact metadata — the .oxbin carries per-standpoint operator declarations + per-query lattice contexts in the global-control section’s serialized manifest.

The capability-mismatch question has at least four sub-questions. Each is open.

Open questions

Q-37.1: What’s in RuntimeCapabilities?

Plausible shape (not committed):

#![allow(unused)]
fn main() {
pub struct RuntimeCapabilities {
    pub max_tier_supported: TierLevel,
    pub supported_aft_operators: BTreeSet<AftOperatorClass>,
    pub supported_lattice_contexts: BTreeSet<LatticeContext>,
    pub supports_paraconsistent_standpoints: bool,
    pub supports_federation: bool,
    pub resource_limits: ResourceLimits,
    pub feature_flags: BTreeSet<FeatureFlag>,
}

pub enum AftOperatorClass {
    Identity,             // OWA
    StratifiedNegation,   // CWA / Reiter+Clark
    WindowedClosure,      // LCWA
    AlternatingFixpoint,  // MKNF+WFS / Liu-You 2019
    Circumscription,      // via AEL or stable models
}

pub enum LatticeContext { Boolean, K3, FDE }
}

Open: is BTreeSet<AftOperatorClass> the right granularity, or should we report individual operator implementations with versions? Should supports_federation be a derived flag from supported_lattice_contexts.contains(FDE), or independent?

Q-37.2: What does artifact-runtime capability matching look like?

The artifact’s global-control section carries required_aft_operators (the union over all standpoints’ declared modes) and required_lattice_contexts (the union over all queries/rules). Layer-1 needs to check:

artifact.required_aft_operators ⊆ runtime.supported_aft_operators
artifact.required_lattice_contexts ⊆ runtime.supported_lattice_contexts

Open: is this a Layer-1 check (fast, O(1) — set inclusion is constant-time over a small fixed alphabet) or a Layer-2 check? Where does it sit in the §7 streaming load order? My intuition says Layer-1 because the alphabet is small and fixed; this also matches the pattern of max_tier_claimed ≤ max_tier_supported.

Q-37.3: How does this interact with multi-release overlay?

RFD-0035 §4 specifies multi-release overlay (JEP-238 at the section level). An artifact may carry both a projection-cache (DRedc-shaped) and an arrangement-section (DBSP-shaped) in parallel; each runtime picks the section it understands.

Open: does the same overlay pattern apply at the operator level? An artifact could carry both an LCWA-shaped event log section and an MKNF-WFS-shaped section, and each runtime picks the one it can evaluate. Or is operator-level overlay too granular? My intuition is that operator selection is a property of the standpoint declaration, not of artifact storage — the operator is fixed at compose time, and a runtime that doesn’t support that operator simply refuses the artifact. But there might be a use case for “this artifact can be evaluated under EITHER LCWA or full CWA, depending on the runtime.”

Q-37.4: Diagnostic codes for capability mismatch

RFD-0035 §16 already has OE1004 TierMismatch for tier-level mismatch. Capability mismatch suggests parallel codes:

Open: are these all distinct, or does OE1017 collapse into OE1015 (paraconsistent support is a kind of operator-level capability)? Should the runtime also advertise consistency policy support per standpoint, or is this implicit in supporting the FDE lattice context?

Q-37.5: How do alternative runtime backends advertise?

RFD-0035 §14 anticipates multiple backends: kernel, in-process oxc-runtime, sandboxed bytecode, oxigraph-backed embedded engine. Each implements OxbinRuntime and advertises capabilities. Sandboxed runtimes likely advertise a smaller capability set (no MKNF+WFS, no paraconsistent, only K3).

Open: is the capability set monotone in implementation richness — i.e., a strictly-richer runtime advertises a strictly-larger set — or are there genuinely incomparable runtimes? An oxigraph backend might support a different set of operators than the kernel for performance-or-architecture reasons. This affects whether we can have a useful “runtime-A is a strict subset of runtime-B” relation, which would let oxup recommend the right backend per artifact.

Q-37.6: How does this interact with ox bench and ox inspect?

RFD-0035 §17 specifies ox inspect <oxbin> (surface artifact structure) and ox bench <oxbin> (benchmark harness). Both should incorporate the capability story:

• ox inspect should report which AFT operators the artifact requires + which lattice contexts.
• ox bench should refuse to bench an artifact a runtime can’t load.

Open: does ox inspect benefit from a --runtime <kernel|in-process|...> flag that scopes the report to “what’s required for this runtime to load this artifact”? Or is the unfiltered report always the right thing?

Q-37.7: Forward-compatibility for refined approximation spaces

RFD-0037 §13 lists Vanbesien 2025 refined approximation spaces, Heyninck 2022 non-deterministic AFT, Charalambidis 2024 higher-order weak bilattices, and continuous-confidence lattices as forward-compatible extensions. Each adds new AFT operator classes and possibly new lattice contexts.

Open: should RuntimeCapabilities use AftOperatorClass as a closed enum (today’s classes only) or an open string-tagged set (String for future operator names)? Closed enum gives us drift-gate coverage but blocks unsanctioned extensions; open set is forwards-compatible but loses the type-safety story. The Argon convention so far (per RFD-0024’s closed Severity enum) is closed — but capability surfaces are different from diagnostic surfaces in that capabilities want to grow naturally over time.

Non-questions (locked by upstream RFDs)

The following are settled and do not reopen here:

• The truth-value bilattice substrate (FDE / Truth4) — RFD-0037 §1.
• The three lattice contexts (Boolean, K3, FDE) — RFD-0037 §2.
• Fail-closed projection from FDE to K3 — RFD-0037 §8.
• Per-standpoint consistency policy at the language level — RFD-0037 §9.
• The OxbinRuntime trait shape — RFD-0035 §14.
• The Layer-1 / Layer-2 validation discipline — RFD-0035 §6–§7.

This RFD is purely about the capability advertisement surface on top of those settled commitments.

Anticipated direction

Given the discussion above, my anticipated commitment shape (subject to the design session) is:

• RuntimeCapabilities carries closed enums for AftOperatorClass and LatticeContext, expanding additively when new operators land.
• Capability matching is Layer-1, alongside the existing tier check, because the alphabets are small and fixed.
• Operator-level multi-release overlay is rejected (Q-37.3). Operator selection is a compose-time decision; the artifact requires the operator chosen at compose; runtimes either support it or refuse.
• Diagnostic codes are distinct (OE1015 operator, OE1016 lattice context, OE1017 paraconsistent), since each represents a different mismatch class with different remediation paths.
• ox inspect --runtime <name> is added as a filter, defaulting to “all required” when omitted.

But these are anticipations, not commitments. The design session should validate or reject each.

Out of scope

• The implementation of any specific AFT operator. RFD-0037 names them; the implementations live in the per-standpoint operator modules and are covered by the soundness proof at argon-formal/.
• The wire-format of global-control’s required_aft_operators field. That belongs in oxc-protocol::core::oxbin per RFD-0035 §17 once this RFD commits.
• How alternative runtime backends (kernel, oxigraph, …) actually compute their capability set. That’s an implementation detail per backend.

Diagnostic codes (anticipated, not registered yet)

Pending the design session and this RFD’s promotion to committed:

• OE1015 RuntimeOperatorMismatch — required AFT operator not supported.
• OE1016 RuntimeLatticeMismatch — required lattice context not supported.
• OE1017 RuntimeParaconsistentUnsupported — artifact has paraconsistent standpoints; runtime does not support them.

Codes are NOT reserved while this RFD is in discussion per the lifecycle rule.

Historical lineage

• RFD-0035 — OxbinRuntime trait + Layer-1/Layer-2 validation. The base this RFD extends.
• RFD-0037 — AFT-grounded truth-value semantics. The framework this RFD reports on.
• WebAssembly Component Model — capability-set advertisement for component composition is the closest published precedent.
• ONNX three-axis versioning (RFD-0035 §4 historical lineage) — lesson for evolving capability surfaces additively.