Capability as Confidence Input

Mechanism

Capability awareness is the agent function that determines, prior to commitment, whether the substrate on which the agent runs can in fact execute a proposed task. The function is not a permission check and not a preference score; it is a feasibility computation expressed as a structured value within the canonical confidence field. The novel contribution claimed in Chapter 6 is the requirement that this computation consume per-input confidence values from each contributing signal and propagate the worst-case value into the aggregate capability score.

Each input to the capability function arrives with an associated confidence value in the closed interval between zero and one. Inputs include sensor readings of available compute, telemetry of memory headroom, network reachability assessments, latency measurements, energy budget estimates, peripheral availability, and any domain-specific resource indicators required by the task class. Every such input carries provenance metadata identifying its source, freshness, and prior confidence assignment. The capability awareness function reads each input together with its confidence, never treating the value as bare data.

The aggregation rule is monotone non-increasing in the minimum input confidence. In the canonical embodiment the aggregate is the minimum: if any single contributing input has confidence below the configured floor, the aggregate capability confidence cannot exceed that floor. This is the anti-laundering property. A high-confidence sensor cannot rescue a low-confidence sensor through averaging; a fresh measurement cannot conceal a stale one through weighted blending; an internally certain estimate cannot mask an externally uncertain one through optimistic combination. The worst input bounds the aggregate.

The output of the capability function is a structured tuple containing the per-dimension feasibility verdict, the per-dimension confidence, the aggregate capability confidence, and the identity of the binding input — that is, the specific input whose confidence determined the aggregate. This binding input is recorded in the lineage so that any downstream consumer, auditor, or governance process can trace which signal limited the capability assessment for any given decision.

The capability confidence then enters the broader confidence governance layer as one input among several, including epistemic confidence, alignment confidence, and goal-condition confidence. The same anti-laundering rule applies at that level: capability confidence cannot be averaged away by high values in other dimensions. A task that is permissible, well-aligned, and well-understood but not physically feasible remains gated by the capability term.

Operating Parameters

The mechanism is parameterized by a small, declarative set of values held in the agent's policy reference. The confidence floor specifies the minimum acceptable input confidence below which the capability function refuses to commit and instead emits a deferred or escalated outcome. Typical floors range from 0.6 for exploratory or reversible tasks to 0.95 for irreversible or safety-critical tasks. The floor is task-class scoped, not global, so that the same agent can apply different thresholds to different action categories.

The aggregation operator is configurable but constrained. Permissible operators are those that satisfy the worst-case bound: minimum, soft-min with a temperature parameter that converges to minimum at the configured limit, and weighted minimum where weights bias toward more critical resource dimensions but cannot inflate the result above the lowest weighted input. Arithmetic mean, geometric mean, and any operator that can produce an output exceeding the minimum input are explicitly excluded from the permissible set, and the policy validator rejects configurations that select them.

Input freshness windows are specified per input class. A latency measurement older than its freshness window has its confidence decayed toward zero on a configurable schedule, ensuring that stale data cannot indefinitely retain high confidence by virtue of having been certain at the time of capture. Decay schedules are typically linear, exponential, or step, with the choice recorded in policy and applied deterministically.

Hysteresis margins prevent oscillation when the binding input hovers near the floor. Once the aggregate falls below the floor, recovery requires the binding input to exceed the floor by the configured margin before the capability function returns to a feasible verdict. This prevents rapid toggling between feasible and infeasible states under noisy sensors.

The lineage retention parameter governs how long binding-input identities and per-input confidences are retained. Retention is set per task class and per regulatory regime, with safety-critical classes typically retaining the full record indefinitely.

Alternative Embodiments

The mechanism admits several embodiments while preserving the core anti-laundering property. In a software-only embodiment the capability function evaluates compute, memory, and network resources of the host runtime, with inputs drawn from operating-system telemetry and confidence values assigned by a calibrated estimator. In an embodied robotics embodiment the inputs additionally include actuator readiness, end-effector calibration, payload tolerance, and environmental sensing, each with its own confidence pipeline.

In a federated embodiment the agent computes capability across a distributed substrate where some inputs are sourced from remote nodes. Remote input confidence is multiplied by a transport-trust factor that captures uncertainty introduced by the network path; the result enters the same worst-case aggregation. In a multi-agent embodiment one agent's capability assessment can be consumed as an input to another agent's capability function, with the upstream confidence flowing through unchanged and never inflated.

A regulated-domain embodiment binds the floor to the regulatory class of the task, so that medical-grade actions, vehicular-control actions, and financial-execution actions each draw their floor from a domain-specific schedule. A simulation embodiment runs the capability function in shadow mode against historical telemetry to produce counterfactual feasibility verdicts for compliance review without committing actual execution.

The aggregation operator may be replaced by any operator in the permissible set without changing the mechanism's character. Compositional embodiments stack the capability function inside a broader confidence governance pipeline where capability is one of several worst-case terms, each of which can independently gate execution.

Composition

Capability confidence composes with alignment confidence, epistemic confidence, and goal-condition confidence inside the confidence governance layer. The composition is itself worst-case: the aggregate execution confidence cannot exceed the minimum of its constituents. This means a task can be blocked by capability alone, by alignment alone, by epistemics alone, or by any combination, and no high-confidence dimension can compensate for a low-confidence one.

The mechanism composes with confidence contagion such that capability confidence flowing into a delegated subtask is bounded by the upstream capability confidence at delegation time. Downstream agents inherit a ceiling rather than a floor; they must re-establish capability confidence locally and cannot exceed the inherited bound without re-evaluation against their own substrate.

The mechanism also composes with the curiosity modulator: curiosity-driven exploration cannot drive the agent to commit to actions whose capability confidence is below the floor, regardless of the exploration bonus. The curiosity term modulates choice within the feasible set; it does not enlarge the feasible set.

Prior-Art Posture

Existing capability checks in production systems typically reduce to authorization checks, resource availability polls, or precondition assertions. Authorization-based systems confuse permission with feasibility and routinely commit to actions the substrate cannot complete. Resource-poll systems return bare values without confidence, leaving the consumer to assume measurements are accurate. Precondition assertions are binary and do not propagate uncertainty.

Probabilistic planning literature has explored confidence-weighted feasibility, but the typical aggregation is a product of probabilities or a weighted sum, both of which permit high-confidence inputs to mask low-confidence ones. The novelty claimed here is the structural commitment to worst-case aggregation, the binding-input lineage, and the policy-enforced exclusion of laundering operators. No prior system known to the inventor combines these properties in a single, declaratively governed cognitive function.

Failure Modes and Structural Defenses

Three classes of failure motivate the worst-case structural commitment. The first is silent laundering, in which an aggregation operator quietly inflates the capability score above its lowest input. Arithmetic mean is the canonical example: a single input at 0.2 combined with three inputs at 0.95 yields an aggregate of 0.7375, well above the 0.2 floor that should bind the decision. The mechanism's structural exclusion of mean-style operators eliminates this failure by construction rather than by audit.

The second is stale optimism, in which a high-confidence measurement persists past its validity. A latency reading taken under nominal load remains highly confident as a number long after the network has degraded. The freshness window and decay schedule force the confidence value to follow the age of the underlying observation, so that an unrefreshed input loses its authority over time and cannot continue to mask current conditions.

The third is binding-input invisibility, in which a feasibility verdict is produced without recording which input was the limiting factor. Without that record, governance cannot determine whether the agent is being throttled by a recurring weak signal that should be improved or by a transient fluctuation that should be tolerated. The mechanism's lineage requirement ensures that every aggregate verdict is accompanied by the identity and value of its binding input, making patterns of capability limitation observable and tractable for engineering response.

A fourth class, opportunistic re-aggregation, occurs when an agent re-evaluates capability mid-execution and inflates a previously low aggregate by selectively dropping inputs whose confidence has not yet recovered. The mechanism's monotone-non-increasing aggregation rule combined with lineage continuity prevents this: an input that was binding at decision time cannot be silently removed from the aggregation set later, and any change in the input set itself is a recorded structural event subject to governance.

Disclosure Scope

This article discloses the input-to-capability coupling at the level required for licensee implementation against Chapter 6 of the cognition patent. It does not disclose the full claim set, the confidence calibration procedures used to assign per-input values, or the lineage schema by which binding inputs are retained for audit. Implementers should consult the patent specification and accompanying policy reference for the operative parameter ranges, the validator rules that exclude impermissible aggregation operators, and the governance interfaces by which floors and freshness windows are administered. Licensees seeking to integrate the mechanism into existing systems should additionally review the conformance test suite, which exercises the worst-case property under adversarial input distributions designed to expose laundering operators that pass casual inspection.