Negative Capability Signals: Recording What Cannot Be Done as Structured Constraint

Mechanism

The mechanism for recording and enforcing negative capabilities operates through three coordinated structures within the memory-resident execution architecture: the negative capability table, the structural enforcement gate, and the downstream advertisement protocol. Together these structures convert what would otherwise be a runtime exception or a documentation convention into a property of the agent's memory that no caller can bypass and no implementation can ignore.

The negative capability table is a region of the agent's persistent memory that holds typed, signed declarations of operations that the agent cannot perform. Each entry in the table is a tuple containing the operation name, the conditions under which the negative capability applies, the rationale for the declaration, the identity that authorized the declaration, and a lineage reference that anchors the declaration to a verifiable point in the agent's history. The conditions field is itself structured: it can express temporal constraints, environmental constraints, input constraints, and dependency constraints. A declaration that an agent cannot process payment instructions denominated in a particular currency carries a different conditions structure than a declaration that an agent cannot operate when network connectivity to a particular service is unavailable, and the table preserves both with full structural detail.

The structural enforcement gate is the runtime mechanism through which the table is consulted on every operation invocation. When an agent receives a request to perform an operation, the substrate evaluates the request against the negative capability table before any application logic executes. The evaluation is not advisory. If the request matches a negative capability declaration under its current conditions, the substrate refuses the operation and returns a structured negative capability response that names the matched declaration and references the rationale. The application logic is never invoked. This structural gating distinguishes negative capabilities from runtime guards written in application code, which could be bypassed by direct invocation, by reflection, or by a maliciously modified runtime. The gate sits beneath the application surface and is enforced by the substrate.

The downstream advertisement protocol propagates the contents of the negative capability table to consumers of the agent. When a consumer queries the agent's interface, the response includes not only the operations the agent supports but also, in a parallel structure, the operations the agent has declared it cannot perform. Consumers can therefore plan around negative capabilities at construction time rather than discovering them through failed invocations. The advertisement is signed with the same authority that signed the table entries, so a consumer can verify that the negative capability declarations it relies on were genuinely issued by the agent's authorizing entity.

Negative capabilities, once declared, are durable. Removing a declaration is itself an operation that requires structural authorization, generates a lineage event, and is visible to downstream consumers as a transition. There is no path by which a negative capability can quietly disappear; the table is append-only with respect to history, and the live state of the table is reconstructed by replaying the history. This durability gives downstream consumers a stable surface to plan against and gives auditors a complete record of the agent's evolving boundaries.

Operating Parameters

The mechanism is parameterized along several axes that determine its behavior in deployment. The first parameter is the granularity of operation naming. Negative capabilities can be declared at the level of individual operations, at the level of operation families, or at the level of the entire agent. Fine-grained declarations permit precise expression of boundaries but require the table to track many entries; coarse-grained declarations are compact but can express only blunt boundaries. The architecture supports both and permits an agent to mix granularities in a single table.

The second parameter is the conditions vocabulary. The conditions structure attached to each declaration is drawn from a defined vocabulary of constraint types: temporal windows, environmental probes, input predicates, dependency states, and authority attestations. Deployments can extend the vocabulary by registering new constraint types with the substrate, but every constraint type must provide a deterministic evaluation function so that the structural enforcement gate can decide membership without invoking application logic.

The third parameter is the propagation discipline. The downstream advertisement protocol can operate in eager mode, in which the full negative capability table is published to every consumer at the moment of interface query, or in lazy mode, in which negative capabilities are advertised only as they become relevant to a particular operation request. Eager mode supports planning at the cost of bandwidth; lazy mode minimizes bandwidth at the cost of late discovery. The architecture defaults to eager mode for stable declarations and lazy mode for declarations whose conditions are highly volatile.

The fourth parameter is the lineage retention horizon. The append-only history of negative capability declarations is retained according to a configurable horizon. Short horizons reduce storage at the cost of audit completeness; long horizons preserve full history at the cost of storage. The architecture preserves a cryptographic summary of pruned history so that even after a horizon-driven prune, the integrity of the surviving record can be verified against the discarded prefix.

A fifth parameter is the authorization scope governing who may declare, revise, or remove negative capability entries. The architecture supports unitary authorization, in which a single signing identity controls all entries, and stratified authorization, in which different classes of entries are reserved to different signing authorities. Stratified authorization permits, for example, a regulatory authority to declare negative capabilities related to legal restrictions while reserving operational negative capabilities to the agent's local operator. The scope of each authority is itself encoded structurally so that an attempt by one authority to alter entries reserved to another fails at the substrate level rather than relying on out-of-band convention.

A sixth parameter governs the latency budget allotted to the structural enforcement gate. Because the gate runs on every operation invocation before application logic executes, its evaluation cost is observable as a tax on every operation. The architecture permits the budget to be tuned: tight budgets favor coarse-grained matching against a small table, looser budgets accommodate richer condition vocabularies and larger tables. The budget is enforced at the substrate so that an implementation that would exceed the configured budget fails closed by treating the gate evaluation as a refusal rather than allowing the operation to proceed under partial evaluation.

Alternative Embodiments

The disclosed mechanism admits alternative embodiments. In one embodiment, the negative capability table is replicated across multiple agents that share a delegation relationship, so that a delegating agent inherits the negative capabilities of its delegate as a constraint on its own operations. In a second embodiment, negative capabilities are composed across pipelines of agents through a structural intersection rule: a pipeline can perform an operation only if no constituent agent has declared a negative capability covering that operation under the current conditions. In a third embodiment, the conditions vocabulary is extended with probabilistic constraints expressing that the agent cannot operate when a defined statistical bound is violated; the structural gate evaluates these constraints against streaming observations rather than discrete state. In a fourth embodiment, the negative capability table itself is subject to negative capabilities, encoding the principle that the agent cannot remove certain declarations under any circumstances. Each embodiment preserves the structural enforcement and downstream visibility properties of the disclosed mechanism.

Composition With Other Mechanisms

Negative capability declarations compose with the broader memory-resident execution architecture in defined ways. They compose with the persistent semantic object format by occupying a designated region of the object's memory, distinguished from positive capability and from accumulated state. They compose with the orchestration-free execution model by serving as the source of authoritative refusal when an operation request cannot be fulfilled; the architecture's commitment to autonomous execution does not weaken the structural force of a declared negative capability. They compose with the lineage system by writing every declaration, condition change, and removal as a lineage event whose integrity is bound to the rest of the agent's history. They compose with the trust-weighted voting protocols described in companion disclosures by treating a participant's negative capability in a domain as a structural exclusion from votes in that domain rather than as a soft preference. The composition rules are closed: any combination of these mechanisms produces a state that remains a valid memory-resident execution state.

Distinction From Prior Art

Prior approaches to expressing what a system cannot do fall into three broad categories. The first is exception-based signaling, in which an attempt to invoke an unsupported operation results in a runtime exception. Exception-based signaling is reactive rather than declarative; consumers learn of unsupported operations only by attempting them, and the absence of an exception is not a guarantee of support. The second is interface omission, in which an unsupported operation is simply absent from the published interface. Interface omission is structurally weak: it cannot express conditional unavailability, it cannot carry rationale, and it cannot be distinguished from accidental incompleteness. The third is policy-based denial, in which a separate policy layer evaluates each request and may refuse it. Policy-based denial introduces a second authority that can be misconfigured, bypassed, or fall out of synchronization with the agent itself.

Negative capability declarations differ from each of these. They are declarative rather than reactive, carrying a positive statement of what cannot be done. They are structurally typed and conditional, carrying full detail about the circumstances of unavailability. They are enforced by the same substrate that enforces positive capabilities, eliminating the bypass surface of an external policy layer. And they are visible to downstream consumers as first-class interface elements, supporting planning rather than only refusal. The combination is not present in prior art.

Beyond these categories, capability-based security systems such as those derived from KeyKOS and CapROS provide positive capability tokens that grant authority to perform operations but do not provide a corresponding structural form for the negation of authority; a missing capability token is indistinguishable from a token that has not yet been issued. Type system constructs such as effect types and refinement types can express that a function does not perform a particular operation, but they operate at compile time on source code rather than at runtime on persistent agent memory, and they cannot adapt to conditions that change after deployment. Service mesh policies expressed in systems such as Istio can refuse traffic at the network boundary, but they do not propagate to downstream consumers as a property of the agent itself, and they cannot bind the rationale for refusal to a tamper-evident lineage. The disclosed mechanism is distinguished from each by reference to its specific structural commitments.

Disclosure Scope

The disclosure encompasses the negative capability table data structure, the structural enforcement gate within the memory-resident execution substrate, the downstream advertisement protocol, and the lineage-bound history of declarations. The scope extends to embodiments in which any of these elements is implemented across a range of agent runtimes, persistence substrates, and transport layers, and to deployments in centralized, federated, and decentralized topologies. The scope does not depend on a particular signature scheme, a particular constraint vocabulary, or a particular advertisement transport, provided that the substituted components preserve the structural enforcement and downstream visibility guarantees described herein.