Action-Typed Aliases: Behavioral Intent Embedded in the Namespace

Mechanism

An action-typed alias is a tuple comprising a target reference, an action-type tag drawn from a governed verb vocabulary, and a scope binding that ties the alias to one or more governance anchors. The action-type tag is not metadata appended after resolution; it is a structural component of the alias and is evaluated at every hop of the resolution chain. The four canonical action types disclosed are read (passive observation of state), write (mutation of state), signal (transient event emission with no persistent state change), and claim (assertion of authority, ownership, or intent to commit). Each action type is associated with a distinct admissibility predicate, a distinct quorum or witness requirement, and a distinct routing affinity.

When a caller submits a resolution request, the anchor first decomposes the alias into its target and action components. The action component is evaluated against the scope's action-policy table, which specifies, for each action type, the credentials required, the witnesses that must co-sign, the rate limits that apply, and the destination class to which the resolved request is forwarded. A read alias may be satisfied from any cache anchor that holds a sufficiently recent snapshot. A write alias must traverse to the governing anchor of record, where a write quorum is assembled before the mutation is committed. A signal alias is fanned out to subscribed listeners and is not persisted beyond its retention window. A claim alias is bound into a chain of custody that includes prior claims against the same target, enabling reasoning about authority continuity and conflict.

The action vocabulary is itself governed. Each action type is registered in a verb registry held by a credentialed namespace authority, and registration carries a schema declaring the type's admissibility predicate, quorum function, retention rules, and audit obligations. Adding a new action type — for example, a delegate verb that grants a scoped capability to another principal, or a revoke verb that withdraws a previously granted alias — is a governance action subject to the same composite admissibility rules that govern any other namespace mutation. The registry is itself addressable through an action-typed alias of action type read, and amendments to the registry are themselves action-typed aliases of action type write.

Resolution proceeds through a sequence of anchors, each of which independently evaluates the action component against its local policy. An action-typed alias may be admitted at one hop and rejected at another; the action type travels with the request, so each anchor sees the same declared intent. This eliminates the class of attacks in which a request is laundered through a permissive intermediary that strips action context before forwarding to a strict downstream — the action type is bound into the alias structure and cannot be removed without invalidating the credential that signed the original request.

Operating Parameters

A practical embodiment of action-typed aliases must specify the size and shape of the action vocabulary, the cardinality of action-policy tables, the latency budget for action-policy evaluation, the cache coherence model that applies to read-typed aliases, the quorum size for write-typed aliases, the fanout limit for signal-typed aliases, and the lifetime and revocation semantics for claim-typed aliases. The disclosure contemplates each of these parameters as tunable within bounds set by governance.

The action vocabulary is bounded but not fixed. A minimal embodiment uses the four canonical types — read, write, signal, claim — each represented by a single byte or short opcode. An expanded embodiment adds delegate, revoke, subscribe, unsubscribe, attest, and challenge, bringing the typical vocabulary to eight or ten verbs. The vocabulary may grow further to accommodate domain-specific intents, but each addition is a registry mutation subject to admissibility review. Implementations are expected to enforce a maximum vocabulary size — typical bound is 256 verbs — to keep the action-policy table small enough to evaluate in constant time.

Action-policy evaluation is on the critical path of every resolution. The disclosure contemplates evaluation latencies in the single-digit microseconds for cached policies and tens of microseconds for policies fetched from the governing anchor. The policy table is structured as a sparse matrix indexed by (action-type, credential-class) pairs, with the action axis bounded by the verb registry size and the credential axis bounded by the scope's credential schema. Policies are versioned, and each anchor caches the most recent version it has observed; stale policies trigger a refresh on first miss.

Read-typed aliases admit eventual consistency: a read alias may be satisfied from any cache anchor whose snapshot is no older than the freshness bound declared in the alias scope. Write-typed aliases require a quorum of governing anchors that together hold a majority of the scope's authority weight; the quorum function is supplied by the scope and may be a simple majority, a threshold over weighted credentials, or a more elaborate function such as a Byzantine fault tolerant agreement. Signal-typed aliases are best-effort by default, with retention windows on the order of seconds to minutes; durable signaling is available as an extension that promotes the signal to a write under the hood. Claim-typed aliases are persistent, conflict-detected, and chained — each new claim against a target references the prior claim and either supersedes, augments, or contests it.

Rate limits and quotas are applied per action type. A scope may permit a million reads per second against a target while permitting only ten writes per second and one claim per minute. Per-action-type quotas allow operators to provision differently for the cost profile of each action: reads are cheap and amenable to caching; writes are expensive and require coordination; claims are scarce but durable; signals are bursty but ephemeral.

Alternative Embodiments

The disclosure contemplates several alternative embodiments. In a first embodiment, the action type is encoded as a prefix on the alias string itself — for example, read:scope/path or write:scope/path — making the action type visible at the textual layer and allowing legacy resolvers to route based on simple string matching. In a second embodiment, the action type is encoded as a structured field in a binary alias representation, with the action type occupying a fixed-width opcode and the target reference occupying a variable-width body. This embodiment is preferred for high-throughput environments where parsing overhead matters.

A third embodiment composes action-typed aliases hierarchically: a parent alias of action type claim may bind a set of child aliases of action types read and write, such that resolution of the children is conditioned on the validity of the parent claim. This enables the construction of capability-style authorities in which a claim establishes a context within which a bounded set of reads and writes is permitted. A fourth embodiment uses action types to express transactional intent: a begin verb opens a transaction scope, a commit verb closes it, and write-typed aliases issued within the scope are admitted only if the commit verb is eventually invoked.

A fifth embodiment integrates action types with content-addressed storage: read-typed aliases resolve to immutable content hashes, write-typed aliases resolve to mutable references that update the content hash atomically, and the action type determines which side of the addressing duality applies. A sixth embodiment specializes the action vocabulary for AI agent networks: an invoke verb represents a function call into a capability, a learn verb represents an observation that updates an agent's model, and a delegate verb represents the transfer of a scoped capability to a peer agent. A seventh embodiment specializes for content delivery: a fetch verb routes through CDN caches, a publish verb routes to origin, and a purge verb propagates invalidations.

The action vocabulary may be domain-extended without breaking compatibility with the canonical four. A domain extension declares its verbs as refinements of the canonical types — for example, a fetch verb is a refinement of read, and a publish verb is a refinement of write — so that resolvers that do not understand the extension can still route safely by falling back to the canonical action type.

Composition With Other Adaptive-Index Primitives

Action-typed aliases compose with the broader adaptive-indexing primitives disclosed in US 19/326,036. Composite admissibility evaluation can incorporate the action type as one input among many: a write alias may be admitted only if a sufficient number of witnesses have countersigned, the scope is in a non-quiesced operational state, and the credential of the originator is current. The action type is one of several governance dimensions that the admissibility evaluator considers, and the disclosure does not require that the action type be the dominant dimension — it is one structural input that, combined with credential, witness, scope state, and rate-limit context, determines admission.

Action-typed aliases compose with the alias-graph primitive: aliases that resolve to other aliases form chains, and each chain hop may carry a different action type. A read alias may resolve to a write alias only if the resolution is performed within a transactional scope that admits the action-type elevation. Composition with the witness primitive allows action-specific witness sets: a write alias may require witnesses from a specific witness class, while a read alias may require none. Composition with the audit primitive allows action-specific audit retention: claim aliases may be retained indefinitely for chain-of-custody purposes, while signal aliases may be retained only for a short observation window.

Action-typed aliases compose with the cross-scope routing primitive: a request that crosses scope boundaries carries its action type, and each scope's gateway evaluates the action type against the scope's admission policy before forwarding. This enables inter-scope policies that distinguish, for example, between scopes that admit reads from outside but require all writes to originate within the scope.

Prior-Art Posture

Conventional namespace systems are action-agnostic at the naming layer. The Domain Name System resolves a name to an address without regard to what the caller intends to do with the address; HTTP separates the URL from the method, with the method conveying intent only at the application layer. URI schemes such as mailto: or tel: encode a coarse-grained action class but do not parameterize the underlying naming infrastructure with action semantics. Capability systems including object-capability languages and capability-based operating systems carry action authority in the capability token rather than in the name; the name and the action are associated by token holdership rather than by structural binding within the namespace.

Access-control systems such as POSIX permissions, ACLs, and RBAC bind permissions to principals against named resources, but the binding is established at the resource layer and consulted after the name has been resolved. The naming layer itself does not differentiate by action. Service mesh frameworks express action policies at the gateway through method-level rules, but again the action is conveyed through the request method rather than through the alias itself, and the gateway's policy table is decoupled from the namespace.

Action-typed aliases are structurally distinct in that the action type is a component of the alias, evaluated at each resolution hop, governed by a credentialed verb registry, and bound into the credential that signs the resolution request. The disclosure does not claim novelty in the bare idea of associating actions with names; it claims novelty in the structural integration of action type into the alias resolution mechanism such that admissibility, routing, witnessing, and audit are all parameterized by the action type at the namespace layer rather than at a downstream application layer.

Disclosure Scope

The action-typed alias primitive is disclosed within US 19/326,036 as one of several governance-aware namespace mechanisms. The disclosure scope encompasses the four canonical action types (read, write, signal, claim), the verb-registry governance model, the action-policy evaluation mechanism, the cache, quorum, fanout, and chain-of-custody semantics applicable to each canonical type, and the alternative embodiments enumerated above including hierarchical composition, transactional scope, content-addressed integration, AI-agent specialization, and CDN specialization.

The disclosure scope contemplates implementation across centralized, federated, and decentralized deployment topologies. In a centralized topology, a single anchor evaluates action policy for the entire scope. In a federated topology, multiple anchors share a verb registry and apply consistent policies under a federation agreement. In a decentralized topology, anchors negotiate verb registry state through a consensus protocol and accept action types only after registry agreement. The action-typed alias primitive is independent of the consensus mechanism and operates over any anchor topology that supports the credentialed admissibility model of the broader disclosure.

Licensees implementing the action-typed alias primitive should expect to provide a verb registry, an action-policy table, an admissibility evaluator that consumes action type as a structural input, and integration with the broader scope, witness, and audit infrastructure. Conformance requires that the canonical four action types behave according to the semantics described in the operating parameters section, that domain extensions are registered as refinements of canonical types, and that the action type is bound into the credentialed signature of the resolution request. The disclosure scope does not require any particular wire format, encoding, or transport — it is a structural specification of the namespace primitive, and implementations are free to instantiate the primitive in any encoding that preserves the disclosed semantics.