Place-Level Capability Envelope

Mechanism

Place-level capability is a dimension of the capability envelope, the structured data object each execution substrate advertises to describe its current structural characteristics. The disclosure names this dimension Locality: a description of the substrate's physical and network position, including geographic region, data center identity, network topology position, latency characteristics to other substrates, and jurisdictional classification. The Locality dimension is one of several dimensions, alongside compute class, memory architecture, model access, execution guarantees, and sensor and actuator interfaces, that together determine what forms of execution a substrate can structurally support.

Locality matters because capability, as the term is used throughout the disclosure, is a structural condition describing whether an executable form of a given objective can exist on a given execution substrate. Some objectives carry positional requirements that no amount of compute or memory can satisfy if the substrate sits in the wrong place. The Locality dimension lets the system evaluate those positional requirements as part of the same capability determination that evaluates every other dimension, rather than treating location as a separate compliance afterthought layered on top of execution.

Positional Requirements

The disclosure identifies the positional requirements the Locality dimension is built to satisfy. Data sovereignty requirements mandate execution within a specific jurisdiction. Latency requirements mandate proximity to a data source or actuator. Regulatory requirements mandate execution within a certified facility. Each of these is a requirement that the substrate's geographic region, data center identity, network topology position, or jurisdictional classification must satisfy for an executable form of the objective to exist at all.

Because these requirements are encoded as a structured envelope dimension with defined semantics, value ranges, and comparison operators, the system can match an objective's positional requirements against a substrate's Locality descriptor in the same formal manner it matches every other dimension. A substrate whose jurisdictional classification does not satisfy a data sovereignty requirement produces a capability mismatch on the Locality dimension, just as a substrate lacking a required accelerator produces a mismatch on the compute class dimension.

Dimension-by-Dimension Matching

Capability matching proceeds dimension by dimension. The system extracts the objective's capability requirements into a structured requirements vector, retrieves the candidate substrate's current capability envelope, and compares them dimension by dimension, producing a match result for each. A capability match is achieved only when every requirement dimension is satisfied; a capability mismatch is identified when one or more dimensions are unsatisfied. The Locality dimension participates in this comparison on equal footing with the others.

Each dimension match result is not binary. It resolves to satisfied, unsatisfied, or conditionally satisfiable. For Locality, a substrate in the wrong jurisdiction is unsatisfied in a manner that no temporal deferral resolves, since waiting does not move the substrate. The unsatisfied dimensions are recorded and propagated to the routing, deferral, and decomposition subsystems, so that an objective with an unmet positional requirement can be rerouted to a substrate whose Locality descriptor satisfies it rather than failing at runtime.

Aggregate Determination and Rerouting

The aggregate capability determination is composed from the individual dimension match results according to a defined composition rule. If all dimensions are satisfied, the determination is structurally possible. If one or more dimensions are unsatisfied and no conditional path exists, the determination is structurally impossible. If one or more dimensions are unsatisfied on the candidate substrate but satisfied on an alternative substrate known to the system, the determination is rerouted: execution is possible but must occur on a different substrate.

The rerouted outcome is the characteristic response to an unmet positional requirement. An objective requiring execution within a specific jurisdiction, when presented against a substrate outside that jurisdiction, does not fail; the system recognizes the structural possibility of execution elsewhere and routes the objective to a substrate whose Locality descriptor places it within the required jurisdiction. This avoids the pathological behavior of retrying an operation on a substrate that can never satisfy the requirement.

The Envelope Is Dynamic

Capability envelopes are dynamic data objects updated in response to changes in the substrate's structural characteristics. When network conditions change, the envelope is updated to reflect the substrate's current state. The system does not rely on stale or statically configured capability information; the envelope is a living description of the substrate's present affordances. For the Locality dimension this matters most for its network-position and latency components, which shift as network topology and inter-substrate latency characteristics evolve.

The disclosure also maintains a capability genealogy for each substrate: a historical, append-only record of envelope changes over time, capturing when capabilities were added, removed, or modified and what events triggered each change. The genealogy is subject to the same cryptographic integrity protections that apply to the agent's lineage, so that historical capability records, including past Locality states, cannot be retroactively altered. This supports forensic analysis of whether a substrate's capability was adequate at the time an objective was dispatched.

Auditable Capability Records

Each capability-native computation produces a structured capability determination record that is persisted in the agent's lineage and made available to governance infrastructure. The record includes the identity of the evaluated substrate, the capability requirements extracted from the objective, the capability envelope retrieved from the substrate, the per-dimension match results, the aggregate determination, the associated uncertainty bounds, and, for deferred or rerouted determinations, the forecasted conditions under which the determination may change.

Because the per-dimension match results are recorded, an auditor can see specifically whether an objective was routed to a particular substrate because of a positional requirement and which Locality component, geographic region, data center identity, network position, or jurisdictional classification, drove the routing. The determination is auditable, reproducible, and traceable from the record alone, rather than carrying the opaque provenance of conventional dispatch.

Independence From Permission

Capability is structurally distinct from permission, authorization, and access control. Permission, authorization, and access control each answer whether an operation is allowed; capability answers whether an operation can structurally exist. The disclosure enforces this independence architecturally: the capability envelope subsystem does not consult governance policies when computing capability, and the governance subsystem does not consult capability envelopes when evaluating permission. The two produce independent determinations combined at the execution synthesis gate, where both must be satisfied for synthesis to proceed.

This distinction governs the Locality dimension as well. A substrate's jurisdictional classification is a structural property of where the substrate is, not a statement about what an agent is permitted to do there. The Locality dimension answers whether a positional requirement can be met by this substrate; a separate governance determination answers whether the agent is authorized to proceed. The four-quadrant model, authorized and capable, authorized but not capable, capable but not authorized, neither, applies here exactly as it applies to every other capability dimension.

Prior-Art Distinction

In conventional distributed computing architectures, capability is assumed, implicitly inferred from resource availability, or conflated with authorization. A task is dispatched to a node, and the node either executes the task or returns a failure, with the determination of whether the node can execute typically made through resource-availability checks or static, manually maintained capability registries. The inability to execute is treated as a failure requiring error handling, retry, or escalation rather than as a structurally valid computational result that informs subsequent routing, deferral, or decomposition.

The disclosure differs by making Locality a formal dimension of the capability envelope, matched dimension by dimension against an objective's positional requirements, composed into the same aggregate capability determination as compute, memory, model access, and the rest, and recorded in an auditable, genealogy-backed lineage. A positional mismatch is not an error; it is a capability determination that drives structurally valid rerouting to a substrate whose position satisfies the requirement.

Disclosure Scope

The Locality dimension of the capability envelope, comprising geographic region, data center identity, network topology position, latency characteristics to other substrates, and jurisdictional classification, together with its dimension-by-dimension matching against an objective's positional requirements (data sovereignty, latency proximity, certified-facility regulation), its composition into the aggregate structurally-possible, structurally-impossible, structurally-deferred, or rerouted determination, its dynamic update and capability-genealogy record, and its architectural independence from permission and authorization, is disclosed in the cognition filing, United States Patent Application 19/647,395, in the capability chapter. This article describes that disclosed mechanism. The scope extends to substrate classes and deployment domains not enumerated, provided locality is evaluated as a structural dimension of the capability envelope and composed into the capability determination on equal footing with the other dimensions.