A function, service, tool, or operation registered within the Dillweed Namespace and invocable through the resolver. Capabilities are the foundational unit of the namespace — what the namespace coordinates discovery and trust about. The Namespace Standard places capabilities in the L4 "Capability Layer" of the stack: tools, agents, data sources, and services that are registered and made invocable. A registered capability is represented by a Capability Record signed by the DNSO.

The signed, structured document that defines a registered capability — what it is, how it behaves, and how it is invoked. The Capability Record is the atomic unit of the resolution system: every namespace path resolves to a Capability Record. The schema is summarized in the Namespace Standard at the level needed to understand the namespace model, and governed in full by the Registry Specification §3, which is the authoritative source for field-level details. The record includes name, description, endpoint, protocol, input/output schemas, trust tier, permissions, version, signature (Ed25519, prefixed dnso_v1_), and last_updated timestamp.

See Namespace Path. The term "capability identifier" appears in the Dillweed Anthill Observability Plane Specification (§3, Appendix A.5, A.7) used descriptively to refer to the dllwd:// URI of a capability. It is not formally defined as a distinct term-of-art; the Namespace Standard's formal term for the same object is "namespace path." This glossary uses "namespace path" as the canonical headword.

The dot-separated sequence of components that follows a Dillweed URI scheme prefix and uniquely identifies a registered capability within the Dillweed Namespace. The Namespace Standard establishes that a capability's identity is its namespace path: trust accumulated against the path persists across endpoint and provider changes as long as the steward maintains the registration. Namespace paths are subject to normative naming rules defined in §3.3 of the Namespace Standard (lowercase ASCII letters, digits, and hyphens; component length 2–64; minimum two dot-separated components; hyphens not at component boundaries; uniqueness within category scope; optional version suffix appended with a colon).

The two scheme forms identifying a Dillweed namespace path. dillweed:// is the full form, preferred in human-facing documentation, standards submissions, and public communications. dllwd:// is the canonical short form, preferred in machine-readable contexts (code, configuration, resolver queries, registry records, infrastructure). Both forms are semantically equivalent and resolve through the same DillClaw resolver infrastructure to identical results; conformant implementations MUST treat the two forms as equivalent. Both schemes are reserved and governed solely by the DNSO. The dllwd:// short form is grounded in the dllwd.com domain registration held by the founding steward.

A single dot-separated unit within a namespace path. Components are subject to normative rules defined in the Namespace Standard §3.3: each MUST consist of lowercase ASCII letters (a–z), digits (0–9), and hyphens (U+002D); each MUST be between 2 and 64 characters inclusive; a component MUST NOT begin or end with a hyphen. A namespace path MUST contain at least two dot-separated components. The first three components in a typical path correspond to <domain>.<category>.<function>, though paths may contain additional components beyond function-level depth.

The founding-steward operational entity responsible for operating the Dillweed Namespace during the founding phase. The DNSO operates the authoritative registry, holds and uses the DNSO signing keypair, performs trust tier attestation, executes revocations, manages incidents, and maintains the cryptographic and procedural integrity of the namespace. The DNSO Operations Charter §1 frames it as "translat[ing] the authority structures defined in the Governance Framework into concrete procedures." The DNSO acronym expands consistently across the stack as "Dillweed Namespace Stewardship Office" — not "Operations" or "Organization" (verified across all eight spec documents).

The current sole holder of DNSO authority during the founding phase of the project. The founding steward has held the dillweed.com anchor domain asset since 1997 and developed the specification stack. During the founding phase, the founding steward retains full authority over specification evolution, trust tier attestation, key custody, and operational practice (subject to the amendment process and conflict-of-interest mechanisms in the Governance Framework §5). This authority is explicitly transitional — bounded by the published governance and continuity framework, and intended to evolve toward multi-stakeholder governance as adoption develops. The founding steward also retains a continuity seat in governance structures, framed as a structural protection of the namespace's neutrality rather than a personal privilege; the seat is bounded by the structural property it protects and may evolve or be retired as multi-stakeholder governance matures.

The designated individual or controlled entity authorized to receive the four succession objects — domain and trademark assets, DNSO cryptographic keys and operational credentials, specification authority, and outstanding governance commitments — and assume DNSO governance obligations upon a triggering condition (founding-steward incapacity, unavailability, voluntary succession, or death). The continuity trustee is designated by the founding steward in advance and serves as the primary external observer of trigger conditions during the founding phase. Distinct from the founding steward role, though a single individual may hold both designations across time as succession occurs.

A planned multi-stakeholder governance body in the intended evolution of the Governance Framework. Organizations that have adopted and implemented the Dillweed Namespace Standard in production systems will be eligible for representation. Defined authorities include: review of proposed specification changes (with a 30-day prior-review requirement on amendments), formal review-request initiation, and consultation on operational policy. The council does not hold authority over the core specification, and no single participant organization may hold a controlling interest in council proceedings (with the precise definition of "controlling interest" reserved for refinement when the council is constituted in practice). Status: As of the current revision, the Participant Council is an intended transition structure and has not yet been constituted.

A planned governance body in the intended evolution of the Governance Framework, responsible for governing specification evolution. Initial composition: three to five members, always an odd number. Membership is earned through demonstrated technical contribution to the specification or reference implementations. The TSC operates by consensus, with the founding steward holding the continuity seat described in §5.1; in the event of a tied vote, the founding steward's position prevails — except where the founding steward has abstained from a specific matter under the conflict-of-interest mechanism, in which case the TSC reaches decisions through majority of remaining voting members or defers to a subsequent session. The TSC also documents and holds any continuity trustee designation made by the founding steward. Status: As of the current revision, the TSC is an intended transition structure and has not yet been constituted.

A multi-purpose term used across the Dillweed Namespace Project in three distinct senses, each grounded in the Governance Framework:

1. Stewardship as a property of namespace governance — the durable, accountable holding of authority over the namespace asset base. Used in framings such as "continuity of stewardship" and "founding stewardship principles." This usage emphasizes that the namespace's credibility derives from continuous, single-owner stewardship rather than distributed or rotating control.
2. Stewardship as a normative obligation — the duties associated with holding the founding-steward role, including specification authority, key custody, attestation, and disclosure obligations. Used in framings such as "stewardship obligations" and "stewardship duties."
3. Stewardship as a formal arrangement — the institutional vehicle (e.g., a foundation or established standards body) that may, through a future licensing arrangement, assume specification stewardship without acquiring the underlying namespace assets. Used in framings such as "under the stewardship of an established standards body" and "licensing and stewardship agreement." Asset ownership and stewardship of specifications are separable in the Dillweed model; the founding steward retains the assets while specification stewardship may transfer.

See also Stewardship Arrangement for the current concrete instantiation under the DNSO. Sense 3 above (formal arrangement) describes a future transition; Stewardship Arrangement describes the present arrangement.

A downstream consumer of namespace resolution — typically an agent, an agent operator, or an integrating system — that depends on resolver and registry state to make trust decisions about discovered capabilities. The Dillweed Anthill Observability Plane Specification recognizes a fourth class of signal origin (in addition to resolver nodes, registry operations, and DNSO-internal processes) for relying-party reporting: in a mature ecosystem, relying parties themselves are an important observational source because they encounter trust failures, stale revocation evidence, unexpected resolver behavior, and attestation mismatches that operator-side monitoring may not surface. (The spec stack does not formally define "relying party" as a term-of-art; this definition is inferred from consistent usage across the Dillweed Anthill specification, primarily in §3, Appendix A.1, and Appendix A.8. Relying-party signal submission is a forward-pointing capability, not yet normative as of v0.1.2.)

A generic term used across the Dillweed Namespace Project for an entity that runs a piece of namespace infrastructure. Used in scoped variants:

• Resolver operator — entity running an instance of the DillClaw resolver
• Registry operator — entity running a registry instance (authoritative, local development, or mirror modes per Registry Specification §3.4)
• Mirror operator — entity running a read-only mirror of the authoritative registry
• Capability operator — entity running a registered capability's underlying service or endpoint
• Agent operator — entity running an agent that consumes namespace resolution

The DNSO Operations Charter and Registry Specification distinguish operator roles where it matters for normative requirements (e.g., conformance obligations differ between authoritative and mirror operators per Registry Specification §3.4 and §10.3). The Dillweed Anthill specification anticipates operator-level trust signals distinct from capability-level trust tiers, on the basis that operator stewardship reputation is architecturally distinct from capability authenticity. (The spec stack does not formally define "operator" as a term-of-art; this entry surfaces the umbrella usage and the scoped variants.)

A normative classification of a capability's reliability, identity verification status, and standing in the namespace, expressed as one of four named tiers (lowest to highest): experimental, trusted, verified, and canonical. Trust tiers are the central trust-classification primitive of the Dillweed Namespace; the Namespace Standard frames them as the layered alternative to binary trust ("trust is layered, not binary"). Each tier has defined meaning and promotion criteria specified in the Registry Specification §9. Tiers are assigned at registration and may be updated through promotion or demotion via the registry's /promote endpoint. Tier demotions (from a higher tier to a lower one) are permitted and logged, allowing a capability that has become unreliable to be demoted without revocation.

The lowest of the four trust tiers. Default starting tier for new registrations. Indicates limited validation or early-stage capability. The Namespace Standard notes that experimental-tier capabilities should be used "with explicit acknowledgment of provisional status." Self-service registration with no promotion criteria — assignment is automatic at first registration.

The second of the four trust tiers. Indicates demonstrated reliability and usage history; the registered endpoint has been tested and found stable over a meaningful period. Promotion criteria per the Registry Specification §9: minimum 3 months continuous registration, consistent endpoint liveness, and no revocation history. Promotion from experimental to trusted is governed but does not require formal DNSO attestation.

The third of the four trust tiers. Indicates the capability's identity has been confirmed by the DNSO, the endpoint has been tested, and DNSO review is complete. Designated as suitable for production use by agents without explicit trust override. Promotion criteria per the Registry Specification §9: DNSO identity verification of the registrant, schema validation passed, and 6+ months active registration. Verified-tier promotion requires Trust Tier Attestation per the DNSO Operations Charter §4.1.

The highest of the four trust tiers. Designates the DNSO-preferred reference implementation for a capability category. Assigned sparingly and only by the DNSO. Per the Registry Specification §9, canonical promotion is "DNSO determination only" — there is no externally claimable promotion path. Canonical-tier promotion requires Trust Tier Attestation per the DNSO Operations Charter §4.2.

The formal process by which the DNSO confirms that a self-declared verified or canonical tier declaration is substantiated. The DNSO Operations Charter §4 frames this distinction explicitly: "Until the DNSO issues attestation, such declarations are provisional and resolvers apply weighting penalties as specified in the Registry Specification §7." The attestation process applies only to verified and canonical tiers (experimental and trusted have separate promotion paths governed by the registry directly). The verified-tier attestation process (§4.1) requires an attestation request, identity verification (typically via DNS TXT record challenge or organizational contact confirmation), endpoint review with a minimum 30-day registration history, and either issuance via POST /promote with an audit-trail log entry, or formal decline with a remediation path. Attestation evidence MUST be retained in the DNSO operational log "for at least the lifetime of the attestation and 12 months thereafter."

A general term for an authoritative DNSO assertion about a capability's status. Used in scoped variants across the spec stack:

• Trust tier attestation — the formal process described above (DNSO Operations Charter §4)
• Stewardship attestation — referenced in governance and continuity contexts
• Attestation evidence — the supporting documentation retained per the §4 retention requirement
• Attestation request — a registrant's initiating communication for attestation review (DNSO Operations Charter §4.1)

The spec stack uses "attestation" as a general term-of-art without a single formal definition. The Trust Tier Attestation entry captures the most operationally significant variant.

A deterministic numerical score in the range [0.0, 1.0] computed by the DillClaw Resolver and used to rank candidates that survive hard eligibility filters. Distinct from trust tier (which is categorical); the trust score is a continuous-valued ranking signal derived in part from the trust tier. Computed as a weighted sum of four signals per the dillclaw-spec §6.2 default scoring profile (dillclaw-default-v1):

• Trust tier (weight 0.40): canonical=1.0, verified=0.85, trusted=0.65, experimental=0.30
• Usage history (weight 0.30): linear in months registered, clamped at 24 months
• Signature validity (weight 0.20): valid=1.0, absent=0.5, invalid=0.0
• Endpoint liveness (weight 0.10): reachable=1.0, unchecked=0.5, unreachable=0.0

The aggregate score MUST be rounded to three decimal places using banker's rounding (IEEE 754 roundTiesToEven). Conformant resolvers MUST produce byte-identical rounded values for the same inputs. The trust score ranks candidates that survive hard eligibility filters; it does not override tier gates, permission checks, signature policy, or caller-defined constraints. Scoring is a ranking mechanism applied to already-eligible candidates, not an authorization decision.

A versioned identifier for the deterministic algorithm used to compute trust scores. The default profile is dillclaw-default-v1, with weights and signal value mappings as defined in the dillclaw-spec §6.2. Future governance-approved profiles may revise weights or signal mappings; profile identifiers are returned in resolver responses and MUST be present in conformant output (scoring_profile field). The determinism guarantee applies within a profile, not across profiles. Profile versioning is independent of the DillClaw Resolver Specification's document version: the profile identifier tracks scoring behavior, not document edits. Callers comparing scores across responses MUST verify that the responses share the same scoring profile.

A design principle of the Dillweed Namespace: trust signals build over time against a stable namespace path, rather than being re-established at each resolution. The Namespace Standard §7.2 articulates this as a structural property — capabilities that maintain valid registrations, stable endpoints, and consistent schemas accrue a usage history visible to resolvers. Resolvers may expose this history to consuming agents as a contextual trust signal, and the DNSO may promote capabilities across tiers based on demonstrated reliability. Trust accumulation is enabled by the namespace-anchored identity property (§7.3): a capability's identity is its namespace path, so accumulated trust persists across endpoint and provider changes as long as the steward maintains the registration.

Dillweed Anthill Signal Class 1. Monitors gradual or incremental accumulation of attestations that approach or exceed a capability's declared trust tier without a corresponding formal tier elevation request. Detects capabilities effectively operating at a higher trust level than their registered designation. Per the Dillweed Anthill Specification §6, ANT-TC is one of three "Registry-native" signal classes (alongside ANT-RC and ANT-EC) — the Registry holds the authoritative state against which the claim is made (attestation tier transitions). ANT-TC signals are most accurately generated from Registry-side analysis rather than resolver observation. Aggregation is performed in the extended (24-hour) window, since trust tier drift represents gradual ecosystem trends rather than acute events.

The component of the Dillweed stack that resolves namespace queries to invocable capability endpoints, applying trust evaluation and candidate selection between the Namespace Layer and the Capability Layer. The DillClaw Resolver is the L3 layer in the stack architecture, sitting between the Namespace Standard (L2) and the Capability Layer (L4). Its functional scope is "query parsing, registry lookup, trust evaluation, candidate ranking, and invocation target selection" — the operational bridge between namespace and capability. The DillClaw Resolver is specified in the DillClaw Resolver Specification, which is the L3 governance document for the stack. Conformant resolvers expose a minimal HTTP API (/resolve, /health) and operate against the authoritative Registry as their canonical data source.

The resolver does not sit in the invocation path — it returns invocation metadata to the calling agent; the agent invokes the capability directly. Deployment topology (resolver-as-service, resolver-as-library, regional mirrors) is implementation-specific and outside the scope of the resolver's normative behavior.

The process of mapping a namespace query to an invocable capability endpoint with verified trust state. The Namespace Standard §5 frames it as: "A resolver takes an agent's intent, queries the namespace, applies trust and policy filters, and returns an invocable capability." Both a process (the act of resolving) and an architectural concept (the resolution model). Resolution is intentionally protocol-agnostic at the invocation layer: a resolver may return endpoints for MCP servers, REST APIs, A2A-compatible agents, or custom protocols (Namespace Standard §5.2). The resolution protocol, trust-scoring algorithm, and API contract are specified in full by the DillClaw Resolver Specification.

The normative five-step sequence by which a resolver maps a namespace query to an invoked capability, defined in Namespace Standard §5.1:

1. Parse — Validate the namespace URI against the syntax rules in §3.3. Reject malformed paths before any network request.
2. Registry Lookup — Query the authoritative Dillweed Registry for candidate Capability Records matching the path.
3. Trust Filter — Apply the caller's trust policy. Reject entries below the required trust tier. Callers may require verified status or apply custom logic.
4. Contextual Selection — If multiple candidates remain, select the best-fit capability based on context, version preference, and required permissions.
5. Invoke — The calling agent invokes the capability directly using the endpoint and protocol returned in the Capability Record. The resolver does not sit in the invocation path unless a separate implementation explicitly chooses to proxy.

The DillClaw Resolver Specification expands this five-step flow into an operational pipeline with parsing, validation, and ranking detail (dillclaw-spec §2 architecture, §3 protocol, §6 trust evaluation pipeline).

An individual deployed instance of a DillClaw Resolver, distinguished from "the resolver" in the abstract sense. The Dillweed Anthill Specification uses "originating_node" in signal payload schemas to identify the specific resolver node generating an observability signal. Resolver nodes are the operator-deployed unit that produces resolution output for a population of agents and is the unit at which several Dillweed Anthill signal classes (ANT-RA, ANT-DN, ANT-WF) are generated and attributed. (The spec stack does not formally define "resolver node" as a term-of-art; the term is used consistently across the Dillweed Anthill specification and the Registry specification to denote a deployed resolver instance.)

A request submitted to a DillClaw Resolver for capability resolution. Per the DillClaw Specification §3.1, a valid query carries a namespace path (or pattern), a minimum trust tier, required permissions, and optional context hints. Queries have three structured forms defined in §4 (Query Language):

• Exact Match — a fully qualified namespace path matching a single capability registration
• Wildcard Matching — a path containing the * wildcard at one or more component positions
• Version Pinning — a path with an explicit version constraint appended via colon (e.g., dllwd://research.market.intel.vendors:1.2.0)

Query constraints (minimum trust tier, required permissions) are applied by the resolver as hard eligibility filters before trust scoring. Malformed queries return immediately with a structured error — no registry contact occurs.

The authoritative persistence layer of the Dillweed Namespace. The Registry stores Capability Records as signed, structured documents; cryptographically signs each record at registration time using the DNSO private key; exposes a governed HTTP API for registration, lookup, revocation, and trust tier management; and maintains an append-only audit trail of all registry actions. The Namespace Standard §2 establishes a key conceptual distinction: a registry stores entries (answers "what exists?"), while a namespace organizes meaning, accumulates trust, and enables contextual selection (answers "what should be used?"). The Dillweed Registry is the authoritative substrate for the namespace, but is not itself the namespace; the namespace is the broader coordination structure of which the registry is one component. The Registry is operated in three deployment modes: authoritative (single source of truth, DNSO-operated), local development (testing instance), and mirror (read-only synchronized cache).

The act of submitting a new capability to the Registry, resulting in a signed, persisted Capability Record. Submitted via the POST /register endpoint. The Registry enforces normative validation rules on submitted records: name (namespace path conformance per the Namespace Standard §3.3), description (non-empty), endpoint (valid URL, HTTP/HTTPS only), protocol (one of rest, mcp, a2a, grpc, custom), trust_tier (one of the four named tiers), and version (semver string, unique with name among active records). Submissions failing any rule are rejected with 422 VALIDATION_FAILED and a structured errors array listing every failure simultaneously. Registrants MAY submit provisional tier declarations up to and including canonical, but these are accepted as provisional claims subject to resolver-side weighting penalties until DNSO attestation is established.

The removal of a Capability Record from active resolution while preserving it in the database for audit purposes. The Registry Specification frames revocation as the governance mechanism that makes the trust layer meaningful: "a namespace that cannot revoke bad actors cannot be trusted." Revocation has five normative properties: it takes immediate effect on the registry's /lookup and /list endpoints (resolver caches may serve a revoked record until their TTL expires, mirroring DNS TTL semantics); it requires a documented reason; it may be scoped to a single name:version pair or applied to all active versions of a capability; the slot is freed for re-registration; and the revoked record is retained in the database with revoked=1, the revocation reason, and a timestamp — never deleted. Revocation is performed via the /revoke endpoint by a caller holding a valid admin token; in the founding phase, the admin token is held exclusively by the DNSO steward.

Cross-spec note: anthill-spec §3 Signal Class 2 (ANT-RC) refers to "the grace period specified in the Registry Specification" for revocation propagation; registry-spec §8.1 uses "TTL" terminology consistently with DNS conventions. The two terms refer to the same operational period but are not currently harmonized across documents. This is a surfaceable inconsistency for future stack revision.

The Registry's revocation storage model: revoked Capability Records are marked with a revoked=1 flag and a revoke_reason rather than physically removed. Per Registry Specification §6.2 ("Soft-Delete Revocation"), "this preserves the audit trail: a revoked record demonstrates that a capability existed, was registered by a real party, and was retired for a documented reason. All API read responses filter on revoked=0 unless explicitly querying history. When a revoked name:version pair is re-registered, the implementation must insert a new row rather than mutating the existing revoked row — the revoked row is immutable and must remain in the audit log unchanged." The soft-delete pattern is the storage discipline that supports the Revocation semantics; together they implement the namespace's auditability commitment. See also Append-Only Log for the broader storage discipline.

The cryptographic signing algorithm used by the DNSO for signing Capability Records and DNSO operational commitments. The Registry Specification §5.1 specifies Ed25519 (Edwards-curve Digital Signature Algorithm, RFC 8032) for all record signing, chosen for its combination of strong security, compact signatures (~88 base64url characters), fast verification, and wide cross-language support (Node.js built-ins, Python, Go, Rust, browser WebCrypto APIs). The DNSO Ed25519 keypair is the cryptographic root of trust for the entire namespace; its integrity is the single most critical operational responsibility of the DNSO. All authoritative Capability Records are signed with the DNSO private key during the founding phase. The DNSO public key is published at the canonical URL https://dillweed.com/dnso_public.pem for independent verification by any party.

A deterministic, byte-identical JSON serialization profile used as the input to Ed25519 signature computation, ensuring signatures are stable regardless of storage format, field ordering, or whitespace. Per Registry Specification §5.2, canonical JSON includes the signed fields with keys sorted alphabetically and no whitespace. The input_schema and output_schema fields are included when present (since they define executable behavior and must be tamper-evident) and omitted entirely when absent (rather than represented as null). Signatures are serialized as a prefixed base64url string: dnso_v1_ followed by the base64url-encoded raw Ed25519 signature bytes (IEEE P1363 encoding); the version prefix enables future algorithm migration without breaking existing parsers. The last_updated field uses RFC 3339 date-time in UTC with the Z offset and second precision; non-UTC offsets and fractional seconds MUST NOT be used, to guarantee byte-identical canonical JSON across implementations.

A structural property of registry storage: the registration log is append-only — entries may be added but no rows may be deleted or modified. The Registry Specification §3.3 names the registration log as one of the registry's core components: "Append-only audit trail of all registry actions: registrations, revocations, and tier promotions. Must be queryable for governance review. Never modified or deleted." Per §6 (Persistence), revoked records are not deleted but are marked with a revoked=1 flag and a revoke_reason, preserving the audit trail. The append-only property is foundational to the namespace's auditability: a revoked record demonstrates that a capability existed, was registered by a real party, and was retired for a documented reason. Append-only structure also recurs in continuity-protocol.html §5 (the canonical disclosure record maintained by the DNSO) and in anthill-spec.html §4 (signal aggregation logs).

The Ed25519 cryptographic keypair held and operated by the DNSO, used to sign all authoritative Capability Records and DNSO operational commitments. The terms "DNSO key," "signing key," "DNSO signing key," and "DNSO Ed25519 keypair" all refer to this single object across the spec stack. The DNSO Operations Charter §5 frames it as "the cryptographic root of trust for the entire namespace." The keypair is subject to specific operational requirements: exclusive custody by the DNSO steward, monthly backup integrity verification, planned rotation with a minimum 30-day overlap window during which both current and prior public keys remain discoverable, and emergency reset procedures for compromise or loss. Records signed under a prior key remain valid during the overlap window; at the close of the window all active records MUST be re-signed under the new key and the prior key retired. (This entry consolidates the multiple terms used across the spec stack — keypair, signing key, DNSO key — into a single canonical headword.)

The current organizational phase of the Dillweed Namespace Project, characterized by single-steward governance prior to the constitution of multi-stakeholder governance bodies. During the founding phase, the founding steward retains full authority over specification evolution, trust tier attestation, key custody, and operational practice (subject to the conflict-of-interest mechanisms and amendment processes in the Governance Framework). Per the Governance Framework §4.2, the founding phase is expected to conclude when one or more conditions are met: a significant institutional partner or implementer has adopted the standard, multiple independent implementations exist, or sufficient community interest exists to constitute a multi-stakeholder governance body. The founding-phase specification family (Stack Family 2026.04) is preserved permanently as the constitutional founding corpus of the namespace.

The structural property that the namespace is not controlled by any participant in the ecosystem it coordinates. Neutrality is the central strategic premise of the Dillweed Namespace Project: per the Governance Framework §03, "a capability coordination namespace for AI agents derives its value precisely from its neutrality." A namespace operated by a major platform participant would face an unavoidable structural challenge — the operator would simultaneously occupy two roles (provider of competing services and arbiter of discovery and trust policy among them) that the namespace's coordination function is designed to keep separate. Neutrality is structural, not asserted: it derives from the configuration of who operates the namespace, not from the operator's claims about themselves. Neutrality is preserved over time through the governance instruments described in the Governance Framework rather than from the founding stewardship alone.

The property that the dillweed.com domain has been under continuous independent single-owner stewardship since 1997 — a 28-year provenance establishing the domain as one of the longest-held independent namespace assets on the internet. Per the Governance Framework §3.1, this continuity of stewardship is "foundational to the project's credibility and neutrality thesis." Provenance is the basis on which the neutrality argument rests: an independently held, long-provenance namespace is positioned to serve as the neutral coordination layer that platform participants would struggle to provide credibly for themselves. Per the Standards Overview §04, provenance provides "an unusual independent provenance basis for a neutral naming authority layer" — it is the necessary basis for neutrality, while formal multi-party governance evolution is left to the Governance Framework and Operations Charter. Provenance alone does not constitute neutrality; the governance instruments do the institutionalizing work that makes neutrality durable across stewardship transitions. See also Asset Provenance for the portfolio-level expression.

Normative restrictions on how the DNSO may exercise its authority, defined in Namespace Standard §8.3:

• All namespace decisions MUST be logged and reviewable
• Registration criteria MUST be published and applied consistently
• Revocation actions MUST include documented justification
• Dispute resolution mechanisms MUST be defined and accessible
• Stewardship may expand over time without breaking continuity of existing registrations

These constitute a specific subset of the Governance Framework's content — the binding limits on DNSO action that any conformant Dillweed implementation must satisfy regardless of the specific stewardship arrangement.

A versioned identifier tracking the architectural revision of the Dillweed specification stack as a whole, distinct from per-document version stamps. Currently 2026.04. Stack Family appears as a metadata field in spec document covers and footers across the stack. (The spec stack consistently uses Stack Family as a metadata field but does not formally define its versioning conventions in any normative section. The convention applied across this week's revisions — Stack Family bumps only on architectural changes, not editorial or document-level revisions — is a working convention rather than a documented rule. A future revision of the Standards Overview or Governance Framework may formalize it.) Per Continuity Protocol §7 (Archival Preservation), the founding-phase specification family (Stack Family 2026.04) is preserved permanently as the constitutional founding corpus of the namespace.

The current concrete instantiation of namespace governance — the specific structure under which dillweed.com is operated. Distinguished in Namespace Standard §8 from "the abstract governance model" that any coordination namespace requires. Per §8.2, the Dillweed implementation of the abstract model is governed by the DNSO, whose purpose is "continuity assurance — ensuring the namespace persists, remains trustworthy, and remains accessible across time — not control for its own sake." The arrangement rests on three structural properties: 28 years of single-owner domain provenance, registered trademark protection across three classes, and a domain portfolio of approximately 200 assets. These are framed not as claims of authority but as continuity properties — the answer to "will this namespace still exist and mean the same thing in ten years?" The arrangement is explicitly designed to transfer; governance instruments are structured so that the namespace can outlive any individual steward. See also Stewardship sense 3 for the future formal-arrangement framing; this entry describes the present arrangement.

(1) The document governance.html that defines the governance philosophy, current authority structure, and intended evolution of the Dillweed Namespace Project. (2) The conceptual framework defined by that document — the institutional structure under which DNSO authority is currently exercised and is intended to evolve toward multi-stakeholder governance. The Governance Framework establishes the founding-phase authority structure (founding steward retaining full authority, subject to conflict-of-interest mechanisms), the intended governance evolution (Technical Steering Committee, Participant Council, founding-steward continuity seat), the amendment process (concurrence requirement for governance-framework and asset-continuity changes), and the precedence order for cross-document conflict resolution. The current published version is v1.1.3.

A class of protocol document that operates alongside the core specification stack to support governance, interpreted consistent with — but not superseding — the core specifications. Currently the only published Governance Support Protocol is GSP-01 (the DNSO Continuity and Stewardship Transition Protocol), which specifies succession mechanics, key custody transfer, and governance continuity procedures. Per Governance Framework §5.7, GSPs sit alongside the spec stack and are interpreted as governance-supporting rather than spec-modifying. For matters of stewardship succession, key custody transfer, or continuity transition, GSP-01 controls within the scope delegated to it by the Governance Framework. The GSP class is open: future protocols within this class may be added to address other governance support functions, each numbered sequentially (GSP-02, GSP-03, etc.).

The cross-cutting observability plane of the Dillweed Namespace stack. Dillweed Anthill defines the signal taxonomy, aggregation behavior, anomaly detection thresholds, and response protocols that enable the DNSO to monitor the health, integrity, and fairness of the namespace ecosystem in operational deployment. Per the Dillweed Anthill Specification §1, Dillweed Anthill "is the instrumentation layer that makes DNSO stewardship operationally credible rather than aspirationally documented." The design principle is non-surveillance aggregation: Dillweed Anthill does not perform centralized surveillance; it aggregates weak signals distributed across resolver nodes, registry operations, and DNSO-internal processes into a coherent ecosystem picture — analogous to the stigmergic coordination of an ant colony, where no single agent holds complete knowledge and emergent behavior arises from distributed local signals. Dillweed Anthill occupies the observational plane across the Dillweed stack rather than at any specific layer, and it does not modify capability records, perform resolution, or make trust tier assignments. Dillweed Anthill™ is a trademark of Richard McClelland.

The architectural concept of which Dillweed Anthill is the specific named instance — the layer of the Dillweed stack responsible for observation, aggregation, and alerting without participating in authoritative operations. Per Dillweed Anthill Specification §2, the observability plane "occupies the observational plane across the Dillweed stack — it does not modify capability records, perform resolution, or make trust tier assignments. It observes, aggregates, and alerts." The term "observability plane" is used in the spec stack both as the abstract architectural concept and as a near-synonym for Dillweed Anthill itself, with context determining the referent.

The fundamental unit of Dillweed Anthill's data model — a discrete, structured observation submitted by an originating node to the aggregation layer. Per Dillweed Anthill Specification §3, each signal MUST carry the following metadata fields:

• signal_class — one of ANT-TC, ANT-RC, ANT-DN, ANT-RA, ANT-WF, ANT-EC
• signal_timestamp — RFC 3339 date-time in UTC with Z offset and second precision
• signal_nonce — cryptographically random 128-bit value (prevents signal replay)
• node_sequence — monotonically increasing integer maintained per originating node (additional replay protection)
• originating_node — resolver node identifier or REGISTRY for registry-origin signals
• capability_ref — the capability identifier under observation, if applicable
• severity — one of INFORMATIONAL, ADVISORY, WARNING, CRITICAL
• signal_payload — class-specific structured data per the per-class schema

Signals are designed to be individually verifiable and aggregable rather than authoritative on their own; emergent anomaly patterns are identified at the aggregation layer rather than at individual nodes.

A category of signal corresponding to a distinct class of namespace ecosystem behavior. Six normative signal classes are defined in Dillweed Anthill Specification §3: ANT-TC (Trust Tier Drift), ANT-RC (Revocation Cascade), ANT-DN (Deceptive Namespace Path Activity), ANT-RA (Resolver Abuse), ANT-WF (Wildcard Fanout Anomalies), and ANT-EC (Ecosystem Concentration Risk). Each signal class has a defined detection trigger and a corresponding response protocol in Dillweed Anthill Specification §7. Two additional signal class identifiers — ANT-HB (Heartbeat) and ANT-NU (Node Unavailability) — are proposed in Appendix A.6 as forward-pointing future work and are not part of the current normative taxonomy.

The architectural layer or entity that emits a signal to the aggregation layer. Per Dillweed Anthill Specification §3, three classes of signal origin are currently defined: resolver nodes, registry operations, and DNSO-internal processes. A fourth origin class — relying-party reporting — is recognized as a planned future capability and is addressed in Appendix A.8. The signal origin classes are architecturally distinct from signal classes (which categorize what is being observed); origin classes categorize who is observing. Per Dillweed Anthill Specification §6 (Signal Origin and Evidentiary Architecture), some signal classes are "Registry-native" (ANT-EC, ANT-RC, ANT-TC — the Registry holds the authoritative state against which the claim is made) while others are "resolver-native with Registry verification" (ANT-RA, ANT-DN, ANT-WF — the resolver observes the field event but the claim that the event is anomalous is verifiable only by comparison against canonical Registry state).

Dillweed Anthill Signal Class 2. Tracks the downstream effects of a revocation event across the resolver network. Measures propagation completeness, propagation latency, and any resolver nodes that continue to serve a revoked capability record beyond the grace period specified in the Registry Specification. Per Dillweed Anthill Specification §6, ANT-RC is one of three "Registry-native" signal classes (alongside ANT-TC and ANT-EC) — the Registry holds the authoritative state against which the claim is made (revocation log state). Aggregation occurs in the short (1-hour) window, since revocation cascade requires time to assess propagation completeness across the resolver network.

Dillweed Anthill Signal Class 3. Identifies resolution attempts that probe namespace paths in patterns consistent with circumventing attestation requirements — including systematic probing of unregistered capability identifiers, impersonation of registered paths, or resolution requests that bypass the standard DillClaw trust verification chain. Per Dillweed Anthill Specification §6, ANT-DN is one of three "resolver-native with Registry verification" signal classes (alongside ANT-RA and ANT-WF) — the resolver observes the field event, but the claim that the event is anomalous is verifiable only by comparison against canonical Registry state. Aggregation occurs in the immediate (60-second) window, since ANT-DN signals may indicate active abuse requiring rapid response. (Per Appendix A.5, the syntactic-versus-semantic distinction within ANT-DN signal payloads is one of the open architectural questions to be resolved in a future revision.)

Dillweed Anthill Signal Class 4. Monitors DillClaw resolver nodes for behavior outside their governance mandate — including serving capability records not present in the canonical Registry, cache poisoning indicators, anomalous resolution latency patterns, and systematic misrepresentation of trust tier scores. Per Dillweed Anthill Specification §6, ANT-RA is one of three "resolver-native with Registry verification" signal classes. Aggregation occurs in the immediate (60-second) window, since ANT-RA may indicate active abuse requiring rapid response. ANT-RA also serves as a system-level signal in nonce-collision and replay-detection cases: per §3, "if the aggregation layer receives a signal whose signal_nonce matches a previously accepted signal from the same originating_node, the signal MUST be rejected as a replay attempt. The aggregation layer MUST additionally generate a CRITICAL-severity ANT-RA (Resolver Abuse) signal naming the offending node."

Dillweed Anthill Signal Class 5. Detects unusual resolution patterns consistent with automated capability harvesting — including high-frequency resolution of wildcard-adjacent namespace paths, systematic enumeration of registered capabilities, and resolution volume patterns that suggest machine-driven discovery rather than legitimate agent invocation. Per Dillweed Anthill Specification §6, ANT-WF is one of three "resolver-native with Registry verification" signal classes. Aggregation occurs in the extended (24-hour) window, since ANT-WF represents gradual ecosystem trends rather than acute events.

Dillweed Anthill Signal Class 6. Measures the distribution of capability invocations across registered providers. Identifies when a disproportionate share of agent activity routes through a single capability provider or organizational group, creating systemic fragility and potential neutrality risk in the namespace ecosystem. Per Dillweed Anthill Specification §6, ANT-EC is one of three "Registry-native" signal classes (alongside ANT-TC and ANT-RC) — the Registry holds the authoritative state against which the claim is made (namespace-wide capability distribution). Aggregation occurs in the extended (24-hour) window. ANT-EC is the signal class most directly connected to the namespace's neutrality property: concentrated invocation patterns across a small number of providers are a structural-neutrality indicator that the DNSO is obligated to monitor.

The component of the Dillweed Anthill observability plane that receives, deduplicates, indexes, and analyzes signals from across the namespace ecosystem. Per Dillweed Anthill Specification §5, "signals from distributed resolver nodes are collected at the DNSO aggregation endpoint, deduplicated by node identifier and timestamp, and evaluated against defined thresholds. No resolver node has visibility into the aggregate signal picture — each node reports its local observations independently, and emergent anomaly patterns are identified only at the aggregation layer." The aggregation layer is the architectural locus where individual signals become an ecosystem-level view; per the design principle in §1, the layer aggregates without performing centralized surveillance, since each node retains visibility only into its own observations.

A defined time interval over which signals of a particular class are aggregated for threshold evaluation. Per Dillweed Anthill Specification §5, three aggregation windows are defined:

• Immediate window (60 seconds) — ANT-DN and ANT-RA signals, which may indicate active abuse requiring rapid response
• Short window (1 hour) — ANT-RC signals, which require time to assess propagation completeness across the resolver network
• Extended window (24 hours) — ANT-TC, ANT-WF, and ANT-EC signals, which represent gradual ecosystem trends rather than acute events

Aggregation windows are calibrated to the temporal character of the underlying ecosystem behavior the signal class detects: acute events have shorter windows; gradual ecosystem trends have longer windows.

The framework defined in Dillweed Anthill Specification §5 by which individual signals are converted into severity classifications for DNSO response. Each signal class defines severity thresholds that trigger escalation through four named severity levels:

• INFORMATIONAL — logged to the immutable operational log; no immediate action required; visible to Participant Council in periodic reporting
• ADVISORY — logged and queued for DNSO review within 72 hours; pattern monitoring elevated
• WARNING — logged and escalated to DNSO steward within 24 hours; response protocol initiated; affected parties notified if applicable
• CRITICAL — logged and escalated to DNSO steward immediately; emergency revocation or suspension authority may be invoked per DNSO Operations Charter §6.3

Threshold values are operational parameters maintained by the DNSO and subject to adjustment as the namespace ecosystem matures. The Dillweed Anthill Specification defines the escalation structure; the DNSO Operations Charter governs response obligations at each severity level.

The aggregation layer's mechanism for identifying compound anomaly patterns — signals from multiple classes occurring together that, individually, do not exceed escalation threshold but collectively indicate coordinated or systematic abuse. Per Dillweed Anthill Specification §5, "a resolver node simultaneously generating ANT-DN and ANT-WF signals, for example, warrants escalation even if neither signal individually reaches WARNING severity." Cross-signal correlation rules are maintained by the DNSO and versioned as operational parameters. Correlation operates across signal classes, while threshold escalation operates within a single signal class — the two mechanisms are architecturally complementary.

A normative requirement on Dillweed Anthill operational records. Per Dillweed Anthill Specification §5, "all Dillweed Anthill signal records, aggregation results, threshold breach events, and DNSO response actions MUST be written to the immutable operational log defined in the DNSO Operations Charter §9.1. No signal record may be deleted, overwritten, or suppressed after initial write." This requirement is "foundational to the auditability of DNSO stewardship behavior." The immutability requirement aligns with the append-only log structure used elsewhere in the Dillweed stack (registry-spec §6 registration log; continuity-protocol §8 disclosure record) — observability records are governed by the same audit-trail discipline as registration and continuity records.

Forward-pointing — Appendix A.6. Provisional signal class identifier proposed in Dillweed Anthill Specification Appendix A.6 as part of the heartbeat-and-detection mechanism that would address signal-absence detection. Each node generating Dillweed Anthill signals would emit a periodic INFORMATIONAL ANT-HB signal at a defined interval, attesting continued operation, current signal-generation code version, and active signing key identifier. Heartbeat interval and missed-heartbeat thresholds would be DNSO-maintained operational parameters. Heartbeats convey only liveness and version state, not behavioral telemetry, to remain consistent with the no-centralized-surveillance posture of §1. Status: not part of the current normative taxonomy. Proposed for a future revision.

Forward-pointing — Appendix A.6. Provisional signal class identifier proposed in Dillweed Anthill Specification Appendix A.6 alongside ANT-HB. The aggregation layer would maintain expected-heartbeat tracking per registered node and would generate a derived ANT-NU anomaly signal when expected heartbeats fail to arrive within tolerance. ANT-NU is the detection-side counterpart of the ANT-HB heartbeat signal: heartbeats provide presence; ANT-NU detects absence. Status: not part of the current normative taxonomy. Proposed for a future revision.

Forward-pointing — Appendix A.7. A proposed operator-level reputation surface, distinct from capability-level trust scores, that would reflect observability-reporting fidelity and surface in operator-facing contexts (DNSO partnership decisions, mirror operator selection, trustee eligibility) rather than in caller-facing trust scores. Per Dillweed Anthill Specification Appendix A.7, the architectural intent is to "preserve the layering boundary: trust tiers continue to express capability authenticity, while operator stewardship reputation runs alongside on its own surface." Reporter-reputation registers address the principal-agent tension between faithful reporting and self-incrimination noted in §6. Status: forward-pointing future-work concept; not yet adopted in normative spec body.

Forward-pointing — Appendix A.7. Also referred to as Merkle-Root Completeness Attestation. A proposed cryptographic mechanism in which each observability node periodically signs and publishes a Merkle root over the signals it generated in a window, such that suppression becomes retrospectively detectable when other observers report signals that should have been included but were not. Per Dillweed Anthill Specification Appendix A.7, this approach "shifts a portion of the problem from incentive design to verifiable-completeness design, which is more aligned with the rest of the Dillweed stack's reliance on signed records and append-only logs." Reporter-reputation registers and completeness attestation address different temporal scales — reputation surfaces patterns over weeks or months; completeness attestation provides per-event cryptographic evidence within a single window — and are architecturally complementary across the time dimension. Status: forward-pointing future-work concept; not yet adopted in normative spec body.

Forward-pointing — Appendix A.10. A proposed architectural framing in which the Registry serves as the authoritative source for verifying claims made by other layers' signals, rather than treating all signal classes as architectural peers at the wire level. Per Dillweed Anthill Specification Appendix A.10, the framing distinguishes Registry-native signal classes (ANT-EC, ANT-RC, ANT-TC) where the Registry holds the authoritative state, from resolver-native signal classes (ANT-RA, ANT-DN, ANT-WF) where the resolver observes but the Registry verifies. The reference-monitor framing is architecturally complementary to (rather than replacing) the signal-absence detection of A.6 and the reporter-incentive mechanisms of A.7: A.6 detects node absence, A.7 detects suppression, A.10 detects false claims. Status: forward-pointing organizing principle; not yet adopted in normative spec body. Adoption would affect §3, §4, §5, §6, §7, and §11.

The specific events that activate stewardship transition under the Continuity Protocol. Per GSP-01 §3, trigger conditions are classified as either self-declared (initiated by the founding steward) or externally observed (initiated by the continuity trustee or, in future phases, the Technical Steering Committee). The six normative trigger conditions:

Trigger conditions remain binding regardless of which body observes them.

The written instrument by which the founding steward designates the continuity trustee. Per Continuity Protocol §4, the CDI specifies: trustee identity, scope of authority, trigger conditions activating the trustee's authority, access instructions for sealed recovery materials, succession limitations (including obligations to seek distributed governance within a defined timeframe), and successor designation authority. The CDI is held in at least two locations: a sealed physical copy held by a trusted third party (attorney, notary, or equivalent legal custodian), and an encrypted digital copy stored independently of the founding steward's personal systems and accessible to the continuity trustee upon trigger. The existence of a CDI is publicly acknowledged; the identity of the designated trustee is held privately until a triggering condition occurs. The founding steward SHALL review the CDI at intervals not exceeding 12 months and SHALL update it if circumstances change materially. (As of the initial publication of GSP-01, the CDI is in preparation; this is publicly acknowledged as an open obligation.)

The set of physical and cryptographic materials maintained by the founding steward in escrow, accessible to the continuity trustee upon a triggering condition. Per Continuity Protocol §5, these materials include:

• The DNSO private key in encrypted form, with decryption instructions
• The canonical public key location and process for updating it
• Registry database access credentials and backup location
• Domain registrar access credentials for namespace asset continuity
• Hosting account access for dillweed.com and associated infrastructure
• A current inventory of all defensive domain registrations and their renewal status

The sealed predecessor private key exists for emergency continuity and archival verification; in planned succession, the preferred procedure is successor-key generation and trust-anchor transition rather than long-term operation under the predecessor private key.

The procedure by which DNSO signing keys move from one steward to the next during stewardship succession. The Continuity Protocol §5 frames key transfer as "the most technically sensitive event in any stewardship succession" and distinguishes two procedures:

Planned Key Transfer — The continuity trustee generates a new Ed25519 keypair in their own secure environment; the founding steward co-signs a transition attestation confirming the transfer; the new public key is published at the canonical URL with a minimum 30-day overlap period; all active registry records are re-signed under the new key during the overlap; the old key is formally retired and its retirement publicly disclosed; resolver operators are notified of the new trust anchor.

Emergency Key Transfer — The continuity trustee accesses sealed recovery materials, takes the registry offline if key compromise is suspected, generates a new Ed25519 keypair, publishes the new public key, re-signs all active capability records, discloses the succession event publicly within 48 hours per §08, and marks the predecessor key status in the operational log.

A compromised or lost key does not invalidate namespace governance — governance obligations are role-bound and continue regardless of key state — but does require a trust-root reset event affecting verifiability of existing signatures.

The treatment of Capability Record signatures made under a predecessor DNSO key after key transition. Per Continuity Protocol §5, predecessor-signed records retain their signatures in the registry as archival evidence of governance state at time of signing. They are annotated with the predecessor key identifier and the date of key transition. Relying parties may treat predecessor-signed records as historically valid but should obtain re-verification under the successor key before relying on them for high-trust invocations.

The procedure by which specification stewardship may transition from the DNSO to a neutral standards body (e.g., a 501(c)(6) trade association, the Linux Foundation, or an established standards organization). Per Continuity Protocol §7, the continuity trustee may determine that migrating specification stewardship to a standards body is in the namespace's interest, subject to three constraints: the Dillweed® trademark and registered rights remain with the designated stewardship entity (not with the standards body); neutrality covenants in the Governance Framework are intended to continue with the namespace assets regardless of where specification stewardship is housed; and prior published versions remain accessible under the original publication terms. Standards body migration is a transfer of specification stewardship, not of namespace assets — the asset/specification separability is structural to the Dillweed model.

The transfer of specification authority — the right and obligation to maintain and revise the Dillweed specification stack and any governance support protocols — from the founding steward to the continuity trustee upon stewardship succession. Per Continuity Protocol §7, the continuity trustee may issue minor revisions (x.x.1 increments) to any specification document to correct errors, clarify language, or address operational necessities arising from succession. Major revisions (x.1 or x.0 increments) require either a 30-day public comment period with documented rationale, or confirmation from a Technical Steering Committee if one has been constituted at the time of succession. The founding steward's published versions are preserved as archival references and are not retroactively altered.

Three closely related conceptual primitives used across the Dillweed Namespace Project, each with a distinct architectural meaning:

1. Coordination Problem — what the Dillweed Namespace exists to solve. Per Namespace Standard §1, "agentic AI systems face a coordination problem that protocols alone cannot solve — they can connect to tools, but cannot reliably find, trust, and use them across providers, at scale." The coordination problem is distinct from the connection problem solved by protocols like MCP and A2A.
2. Coordination Layer — what a namespace is, architecturally. The layer of infrastructure that addresses the coordination problem. Per the Namespace Standard cover tagline, the Dillweed Namespace is "A Governed Coordination Layer for Agentic AI Systems." The layer provides naming, trust accumulation, resolution, governance, and continuity across agentic capability ecosystems.
3. Coordination Namespace — the specific architectural primitive. The combination of namespace structure, registry substrate, resolution semantics, and governance instruments that together constitute a working coordination layer. The Dillweed Namespace is one such coordination namespace; the model could in principle be implemented by a different operator with different governance.

The dillweed.com domain itself, considered as the originating asset of the Dillweed Namespace Project, together with the broader portfolio of namespace assets it anchors. Used in the Governance Framework §6 as the formal object of asset-protection logic — the founding-steward continuity seat exists to preserve "the integrity of the founding asset base," and the amendment-concurrence requirement is "limited to governance-framework and asset-continuity amendments and is intended to prevent changes that would compromise the neutrality thesis or transfer effective control of the founding asset base." The founding asset is the architectural object that the governance instruments protect: not merely the domain, but the structural neutrality the domain's provenance enables.

The portfolio-level continuity claim that supports the namespace's governance model. Per Namespace Standard §12, "the Dillweed implementation is anchored in a controlled asset portfolio with documented long-term provenance. This provenance supports the governance model's continuity claim — it demonstrates the kind of durable, single-steward control that a coordination root requires to be taken seriously as infrastructure." The portfolio comprises:

• dillweed.com — primary domain, single-owner provenance of 28 years
• dillweed.ai, dill.ai, DillClaw.ai, DillForge.ai — primary AI-specific domain variants, resolver and tooling brand domains
• ~200 defensive registrations — covering variant spellings, extensions, and related terms
• TM 35 / 41 / 42 — trademark coverage across retail/advertising, education/technology, and scientific/software services

Distinguished from Independent Provenance, which is the property of single-owner stewardship of dillweed.com since 1997. Asset Provenance is the portfolio-level expression of that property — the broader asset base that the provenance argument anchors. The two terms are related but architecturally distinct.

The class of software systems exhibiting autonomous or semi-autonomous goal-directed behavior — the audience the Dillweed Namespace serves. The Standards Overview §02 frames the relevant class: "agents become persistent software entities capable of moving across runtimes, providers, and administrative domains." Used consistently across the spec stack as the descriptor for the systems whose coordination needs the namespace addresses. The term covers AI agents, agent-based applications, agent runtimes, agent frameworks, and the infrastructure they collectively require. (The spec stack does not formally define "agentic AI" as a term-of-art; the term is used consistently as understood, with definition implicit in the contrast with non-agentic systems that lack autonomous goal-direction.)

External standard. The IETF specifications governing the interpretation of normative keywords (MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL) when written in capitals. Every Dillweed specification document includes a Conformance Terminology section invoking these references. BCP 14 (Best Current Practice 14) is the umbrella designation that combines RFC 2119 (1997) and RFC 8174 (2017).

External references: RFC 2119, RFC 8174

External standard — Edwards-Curve Digital Signature Algorithm (EdDSA). The IETF specification of the Ed25519 signature algorithm used by the DNSO for signing all Capability Records and operational commitments. Referenced in Registry Specification §5.1 as the basis for the registry's signing model.

External reference: RFC 8032

External standard — Date and Time on the Internet. The IETF specification of the date-time format used throughout the Dillweed stack: UTC with Z offset and second precision. Referenced in Registry Specification §3.1 (the last_updated field), Dillweed Anthill Specification §3 (signal_timestamp), and elsewhere where temporal precision matters.

External reference: RFC 3339

External standard — Time-Stamp Protocol (TSP). The IETF specification for cryptographic timestamping using a trusted time-stamping authority. Referenced in Dillweed Anthill Specification Appendix A.4 as the basis for Dillweed Anthill's external timestamp anchoring proposal — a forward-pointing mechanism for binding signal evidence to verifiable third-party time signatures. Status: not part of the current normative Dillweed Anthill spec body.

External reference: RFC 3161

External standard — IDNA 2008 (Internationalized Domain Names in Applications). The IETF specification for internationalized domain name encoding using punycode. Referenced in Namespace Standard Appendix A.1 and Registry Specification §3.1 / §7 as the expected basis for future internationalized namespace components — the current namespace syntax is restricted to lowercase ASCII, but internationalized names are reserved for a future revision and are expected to follow IDNA 2008 conventions.

External reference: RFC 5891

External standard — Certificate Transparency. The IETF specifications for Certificate Transparency, which provides append-only public logs of issued X.509 certificates as a verifiability mechanism for PKI infrastructure. Referenced in Dillweed Anthill Specification §3 as a "Standards Parallel" — the architectural analogue for the Dillweed stack's stance on operationally serious infrastructure backed by observable, auditable monitoring behavior. Also referenced in Dillweed Anthill Appendix A.8 as architectural analog for the tiered-disclosure relying-party reporting model. (RFC 6962 is the original 2013 specification; RFC 9162 is the 2021 revision.)

External reference: RFC 9162

External protocol. An external protocol introduced by Anthropic for standardizing agent-to-tool connections. Referenced across the Dillweed spec stack as a named comparator for the connection-problem layer that Dillweed's coordination layer sits above. Per Namespace Standard §1, MCP "standardizes agent-to-tool connections" while leaving "naming, invocation target selection, long-term identity" for the namespace layer to provide. The Registry Specification §7 and DillClaw Resolver Specification §3 list MCP as one of the protocols a registered capability may use (protocol: "mcp"); the namespace and resolver are intentionally protocol-agnostic at the invocation layer. (MCP is an external protocol not authored by the Dillweed Namespace Project; the spec stack references it as a named comparator and integration target rather than defining it.)

External protocol. An external protocol for inter-agent communication, referenced across the Dillweed spec stack as a named comparator alongside MCP. The Namespace Standard §5.2 notes that Dillweed resolution is "intentionally protocol-agnostic at the invocation layer. A resolver may return endpoints for MCP servers, REST APIs, A2A-compatible agents, or custom protocols." The Registry Specification §7 lists A2A as one of the protocols a registered capability may use (protocol: "a2a"). (A2A is an external protocol not authored by the Dillweed Namespace Project; the spec stack references it as a named comparator and integration target rather than defining it.)

External organization — Internet Corporation for Assigned Names and Numbers. The organization governing the global Domain Name System (DNS). Referenced in Dillweed governance contexts to clarify scope: Dillweed does not compete with or replace ICANN-governed DNS infrastructure. Per Namespace Standard's "What This Is Not" callout, "the Dillweed Namespace is not... a replacement for DNS, PKI, or identity infrastructure." The DNSO is the steward of the Dillweed capability namespace, not an ICANN equivalent for DNS.