Mechanism
An action-typed alias, termed an action-type alias in the disclosure, is an alias augmented with an action verb that expresses intended behavior and permits policy-driven restriction of operations at resolution time. The base alias is a human-readable, context-encoded name that resolves to a stable unique identifier irrespective of renames, delegation, or structural changes. The action type is an optional augmentation prepended to that name. It does not change what the alias resolves to. It makes the caller's intent explicit so that the system can restrict behavior based on predefined permissions, improving both efficiency and security.
The disclosed examples are pay user@elizabeth and view [email protected]/resume. In each, the verb (pay, view) states the operation the caller intends to perform against the named target, and the alias body (user@elizabeth, [email protected]/resume) names the target through the platform's hierarchical naming convention. The verb travels with the alias as a declaration of intent that the resolving anchor can evaluate against its policy before permitting the operation.
An Optional Augmentation, Not a Required Structure
The disclosure describes action types as optional. An alias resolves to its unique identifier with or without an action verb. When a verb is present, it adds intent that the system can act on. The naming convention itself, of the form [top-level domain]@[domain].[subdomain]/[subindices]/[asset], is unchanged by the presence of an action type. The verb is a prefix on the alias, not a rewrite of the resolution path. This keeps action-typed aliases backward-compatible with plain aliases and with the legacy fallback the disclosure describes, in which an alias that does not resolve within the network may fall back to a corresponding legacy domain.
Developer-Defined Verbs
The disclosure does not fix a closed set of action types. Developers may define their own action types or rely on common verbs aligned with application semantics. The verb vocabulary is therefore an application-level concern: a payments application may use pay, a document application may use view and edit, and another domain may define verbs that fit its own operations. The platform's contribution is not a canonical verb list but the mechanism by which any such verb, once attached to an alias, is consulted during resolution to restrict operations under policy.
Restriction at Resolution Time
The action type permits policy-driven restriction of operations at resolution time. In the disclosed architecture, alias resolution is performed by anchor-local registries, and each anchor validates access and mutation attempts against the permissions encoded for the target. Permissions in the platform are evaluated dynamically at resolution time, adapting access rights based on context such as user identity, the device in use, the network environment, and the sensitivity of the resource. The action type supplies the operation dimension to that evaluation: an anchor can permit a view against a document while restricting an edit, or permit a pay only for an authorized identity, because the verb makes the intended operation explicit at the moment the anchor consults its policy.
This places action-typed restriction inside the same resolution path that already governs access. The disclosure describes permissions that are encoded hierarchically and can evolve over time, with higher-level policies inherited by default and overridden at lower levels along a nested alias path. An action type is evaluated within that same scoped, anchor-local policy evaluation rather than at a separate downstream layer.
Composition With Other Disclosed Mechanisms
Action-typed aliases sit alongside the platform's other alias features. The disclosure describes permission hierarchies and expiration on aliases: a path such as [email protected]/phone might be readable only by the owning user, while a time-to-live may cause an alias to be reclaimed after expiry. Because permissions are scoped and recursive, propagating through nested index paths with inheritance and override, an action type attaches to the same alias that carries these permission and lifetime semantics. The verb expresses the operation; the surrounding anchor policy, ownership records, and contextual parameters determine whether that operation is admitted.
Action-typed aliases also remain subject to the platform's UID continuity. Because each alias resolves to a stable unique identifier that persists through renames, delegation, and structural mutation such as splitting, merging, or relocation, an action-typed reference continues to resolve correctly even as the underlying container moves or is re-aliased. The verb does not bind to a location; it qualifies an operation against whatever the alias currently resolves to.
Prior-Art Posture
The disclosure positions its alias system as an alternative to rigid, centralized registries such as the Domain Name System, where names are resolved without regard to what the caller intends to do with the result. By allowing an alias to carry an optional action verb that the resolving anchor evaluates against scope-local policy, the platform lets intent be declared as part of the name and restricted at resolution time rather than only at a later application layer. The disclosure presents this as a way to make alias intent explicit and to restrict behavior based on predefined permissions, contributing to both efficiency and security, while leaving the specific verbs to developers and application semantics.
Disclosure Scope
The action-type alias, defined as an alias augmented with an action verb that expresses intended behavior and permits policy-driven restriction of operations at resolution time, is disclosed in U.S. Application No. 19/326,036 within the alias resolution and naming conventions material and in the definitions. The disclosure provides the examples pay user@elizabeth and view [email protected]/resume, states that action types are optional, that they allow the system to restrict behavior based on predefined permissions for efficiency and security, and that developers may define their own action types or rely on common verbs aligned with application semantics. This article describes that disclosed mechanism. The scope extends to action verbs not enumerated, defined by developers or aligned with application semantics, and to evaluation of those verbs within the disclosed anchor-local, policy-driven, resolution-time access evaluation, provided the action type remains an intent-expressing augmentation of an alias that resolves to a stable unique identifier. It does not extend to fixed verb taxonomies, verb registries, per-verb quorum, fanout, or chain-of-custody machinery, or numeric policy-evaluation bounds, none of which are disclosed.
