Capability-Native Computation

Mechanism

The capability computation is implemented as a deterministic function inside the agent process. Its inputs are: the agent's demonstration record, the policy reference identifying which demonstrations remain valid and under what conditions, the substrate descriptor identifying the tools and services the agent currently has access to, and the task descriptor identifying the goal under consideration. Its outputs are: the current capability vector, a per-action validity flag, and a feasibility verdict for the task. The function does not call out to a remote service to obtain its result. The function does not consult a learned model whose weights are not part of the agent's recorded state. The function is pure, in the technical sense, with respect to the four declared inputs and the policy reference.

Every invocation of the function is recorded in the agent's lineage. The record contains the four inputs by content hash, the policy reference identifier and version, the function's version, and the produced outputs by content hash. An auditor in possession of these recorded artifacts can re-execute the function and obtain bit-identical outputs. This is the operational meaning of reproducibility: not that the computation can be approximated by an independent re-implementation, but that the exact same function applied to the exact same inputs produces the exact same outputs. The agent's claim about its own capability is therefore checkable, not merely asserted.

The function is structured as a composition of named sub-routines, each of which has its own typed input and output schema and its own version. The capability vector is constructed by a sub-routine that filters the demonstration record against the validity rules in the policy reference. The feasibility verdict is produced by a sub-routine that matches the task descriptor against the capability vector. The policy reference itself is a versioned, content-addressed artifact, and the agent records which version was in effect for each invocation. Substituting a different policy reference produces a different output and is recorded as such; the substitution cannot be silent.

Operating Parameters

Native computation imposes a determinism contract. Every operation inside the function is required to be deterministic with respect to its inputs: no wall-clock reads, no random sampling without a seeded generator whose seed is part of the input, no implicit dependency on system state outside the declared inputs. Where determinism would be expensive to enforce naively, for example in a sub-routine that depends on map iteration order, the sub-routine specifies a canonical order and orders its inputs before processing. The contract is checked by a static analyzer at build time and by a runtime monitor that verifies that two consecutive invocations on identical inputs produce identical outputs.

Native computation also imposes a locality contract. The function does not perform network I/O during its execution. All inputs that originate outside the agent process are materialized as part of the input record before the function is invoked, and the input record is hashed before invocation. This prevents the failure mode in which the function appears to be deterministic but in fact depends on a network resource whose state can change between invocations. Materialization may be lazy at the input-construction layer, but is not lazy inside the function itself.

The function exposes its own version and the version of every sub-routine it composes. Version transitions are explicit events in the lineage. An agent that upgrades its capability function records both the old and the new version, and any capability vector that was in effect at the time of transition is marked with the version that produced it. This allows downstream auditors to compare the agent's behavior across versions without ambiguity, and prevents the failure mode in which an upgrade silently changes the meaning of a recorded capability claim.

Alternative Embodiments

In one embodiment, the capability function is implemented as a pure module in the agent's host language and is statically linked into the agent binary. The version of the module is the hash of the binary section that contains it. This embodiment is appropriate for agents whose capability rules change rarely and whose deployment cadence accommodates rebuilds.

In a second embodiment, the capability function is implemented as a sandboxed interpreter that loads its rules from the policy reference at startup. The interpreter is itself versioned, and the loaded rules are content-addressed. This embodiment is appropriate for agents whose capability rules are policy-driven and change without requiring binary rebuilds, while preserving the determinism and locality contracts.

In a third embodiment, the capability function is partitioned across a cluster of agent processes that share a common policy reference and a common demonstration record. Each process computes its own local capability vector, and the vectors are reconciled through a deterministic merge function whose inputs are the per-process vectors and whose output is the cluster-wide vector. The merge function itself satisfies the determinism and locality contracts, so the cluster as a whole remains auditable and reproducible.

In a fourth embodiment, the agent additionally consults an external advisory service whose output is treated as evidence rather than authority. The advisory output is incorporated into the capability function's input record by content hash, and the function's output remains determined by the recorded inputs. The presence of an advisory service does not break the native-computation property: the agent's claim about its own capability is still computed by the agent, and the advisory output is one input among others, recorded and reproducible.

Composition

Native computation composes with the constrained-behavior mechanism that uses the capability vector as the planner's action alphabet. Because the vector is computed natively and is reproducible, the planner's alphabet is itself reproducible, and an auditor can reconstruct exactly which actions the planner could have emitted at any point in the agent's history. Without native computation, this reconstruction would require trusting an external scorer whose state at the time of the planning episode might no longer be available.

Native computation also composes with the agent's lineage and provenance machinery. The capability function's inputs and outputs are recorded with the same fidelity as any other inference, and the records participate in the same hash-chained lineage. An audit that traces a particular agent action back to the plan that produced it, and the plan back to the alphabet that constrained it, can continue tracing the alphabet back to the demonstration record and policy reference that produced it, all within a single consistent record.

Prior-Art Distinctions

Conventional capability frameworks rely on an external scoring service that the agent queries to determine what it can do. The service may be a learned classifier, a centralized policy engine, or a third-party evaluator. In all these patterns the agent's claim about its own capability is mediated by a remote dependency whose state is not part of the agent's recorded inputs. The agent cannot reproduce the claim in isolation, an auditor cannot reconstruct the claim from the agent's record alone, and a change in the remote service silently changes the meaning of every claim the agent has made.

Native computation closes this gap by structurally locating the computation at the agent and by recording every input that flows into it. The agent's claim is not delegated; it is owned. The audit does not require cooperation from a third party; it requires only the agent's record and the named policy reference, both of which are part of the agent's deliverables. This is a structural property, not a deployment choice; the agent that delegates capability scoring to a remote service is not practicing native computation, regardless of how the deployment is described.

Failure Modes Prevented

Native computation is targeted at a cluster of failure modes that recur when capability scoring is delegated to external services. The first is the silent-drift failure, in which the external scorer is updated, the agent's capability claims thereafter mean something different than they did before, and no record of the change is present in the agent's lineage. Auditors comparing two episodes separated by the upgrade reach incorrect conclusions about the agent's behavior because they assume the meaning of the capability claim is constant. Native computation prevents this by binding the function and its policy reference to an explicit version, recorded in the lineage, so that any meaning change is visible as a version transition.

The second is the unverifiable-claim failure, in which the agent asserts that it can perform a particular action because an external scorer has so reported, and a third party attempting to verify the claim cannot do so because the scorer's state at the time of the claim is not preserved. The agent's claim is therefore unfalsifiable from the agent's record alone, and the audit is forced to rely on the scorer's cooperation. Native computation prevents this by ensuring that every input flowing into the capability function is recorded with the agent and is sufficient, by itself, to reproduce the function's output.

The third is the network-coupling failure, in which the capability function appears deterministic but in fact depends on a network resource whose state can change between invocations. Two invocations separated by an unobserved network event produce different outputs, and the agent's behavior becomes irreproducible. The locality contract prevents this by forbidding network I/O inside the function and by requiring that all external inputs be materialized into the input record before invocation.

The fourth is the hidden-randomness failure, in which a sub-routine consumes randomness from a source that is not part of the declared inputs, and the function's output is therefore not reproducible even when the declared inputs are held constant. The determinism contract prevents this by requiring that any randomness be drawn from a seeded generator whose seed is part of the input record, so that the output is fully determined by what is recorded.

Disclosure Scope

The mechanism described herein is a component of the cognition patent's capability-awareness surface. The disclosure covers the location of the capability computation at the agent rather than at an external service, the determinism and locality contracts that make the computation reproducible, the content-addressed input record and policy reference that make the computation auditable, the version-explicit handling of function and sub-routine upgrades, the static-link, sandboxed-interpreter, partitioned-cluster, and advisory-augmented embodiments, and the composition of native computation with constrained-behavior planning and with lineage and provenance machinery. The disclosure is intended to cover any system in which an agent's capability claims are produced by a deterministic, locality-bound, version-explicit function executed at the agent and recorded in the agent's lineage such that the claims are reproducible from the recorded inputs alone.