Dillweed Namespace Project · Standards-Facing Overview · v1.0.10 · May 2026

Dillweed Namespace Stack

A proposed trust and coordination layer for portable agentic systems — a specification stack for multi-party trust management, naming authority, revocation, and neutral governance.

Agent state can move across runtimes and administrative domains. Trust cannot move unless naming authority and attestation evidence move with it. The Dillweed stack is an architectural proposal for that missing layer.

Document TypeStandards Briefing Note
Version1.0.10
IssuedMay 2026
MaturitySpecs Published; Implementations in Local Deployment
Stack Family2026.04
Domaindillweed.com (est. 1997)
§ 01

Executive Summary

The Dillweed Namespace Stack is a proposed trust and coordination layer for portable agentic systems. As agents become persistent software entities capable of moving across runtimes, providers, and administrative domains, the underdeveloped infrastructure layer is no longer primarily model capability — it is stable naming authority, trust-aware resolution, durable registry truth, and neutral governance continuity. As agent token economics tighten, the cost of selecting the wrong capability on the first try becomes structural; a resolution layer that gives agents a stable, attested means of finding the right capability reduces that cost. Without such a layer, agent trust is rebuilt from scratch at every provider boundary — fragmenting cross-domain reliability and recreating the same fragility with every new deployment.

The stack is organized around five core governance-and-resolution specifications covering multi-party trust management, cross-domain agent interoperability, cryptographic attestation, revocation, and operational accountability — supported by two cross-cutting documents (Anthill for observability and the Continuity Protocol for stewardship continuity), and intentionally aligned, by architectural analogy, with the PKI trust-root model underlying existing international identity standards including X.509.

Its neutrality thesis is structural: a namespace operated by a major platform participant would face an unavoidable neutrality challenge, because 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 structured to keep separate. The domain dillweed.com has been under continuous independent single-owner stewardship since 1997, providing an unusual independent provenance basis for a neutral naming authority layer, while leaving formal multi-party governance evolution to the Governance Framework and Operations Charter.

Central Thesis

Agent state can move across runtimes and administrative domains. Trust cannot move unless naming authority and attestation evidence move with it. The Dillweed stack is an architectural proposal for that missing layer.

What This Is Not

The Dillweed stack is not a model provider, agent runtime, application framework, or proprietary agent marketplace, nor a substitute for existing identity, PKI, or DNS infrastructure. It is a proposed neutral coordination layer for naming, resolution, attestation, revocation, governance continuity, and observability across agentic systems — designed to interoperate with the identity and PKI systems already in use rather than to replace them. Its purpose is not to own agent execution, but to make cross-domain capability discovery and trust resolution more stable, attestable, and governable.

§ 02

Specification Architecture

The stack is organized around five core governance-and-resolution specifications, each with a distinct authority boundary and a defined standards-relevant question it answers, supported by two cross-cutting documents (Anthill for observability, the Continuity Protocol for stewardship continuity). Technical semantics are separated from governance authority; operational practice is separated from specification contracts; founding-phase stewardship is designed to evolve toward multi-party institutional models. The five core specifications are listed below; the supporting documents are listed in §05.

01

Namespace Standard — Naming Authority and Trust Framework

What may exist?

Defines the semantic identity layer: canonical namespace paths, persistent capability naming, long-lived authority boundaries, trust tier definitions, neutrality principles, and governance compatibility across relying parties and operators. Establishes the trust framework within which all resolution and attestation operates.

02

DillClaw Resolver — Trust-Aware Resolution and Candidate Selection

How is the correct capability found?

Defines trust-aware resolution behavior: namespace lookup, relying party routing with trust policy enforcement, deterministic selection across trust tiers, traceable failure semantics, and resolver-side weighting of candidates by attested trust tier under a documented scoring profile. Provides verifiable audit trails for resolution decisions.

03

Registry Specification — Authoritative Truth Substrate with Cryptographic Binding

What actually exists?

Defines the authoritative data layer: cryptographically signed capability records using Ed25519 — consistent, by architectural analogy, with the PKI trust-root model underlying X.509 — durable append-only registration history, canonical metadata, revocation state with mandatory audit reason, mirror freshness semantics, and independent signature verification. Signed records establish cryptographic binding between namespace identity and capability endpoint, verifiable by any relying party without trusting the registry itself.

04

Governance Framework — Institutional Legitimacy and Neutrality Continuity

Who decides?

Defines institutional legitimacy through governance continuity stewardship, technical steering committee evolution, participant council review rights, neutrality preservation mechanisms, amendment and public disclosure controls, and succession continuity provisions. Design is consistent with durable commons governance practice. Explicitly prohibits arrangements that would transfer effective control to any single platform participant.

05

DNSO Operations Charter — Trust Practice and Attestation Evidence

How is trust practiced operationally?

Defines stewardship practice: trust tier attestation workflows with evidence retention obligations, DNSO key custody and planned rotation procedures, incident classification and response, public disclosure obligations, registry operational standards including backup and restoration targets, and founding-phase service level posture. Attestation evidence is retained for the lifetime of the attestation plus twelve months to support dispute resolution and governance review.

§ 03

Standards Relevance

This architecture is directly relevant to standards work in the following areas:

Trust Management Naming Authority Governance Continuity Cryptographic Attestation Trust Tiers Revocation and Disclosure Cross-Domain Agent Interoperability Multi-Party Namespace Neutrality Relying Party Trust Frameworks PKI Lineage Attestation Evidence Retention Succession and Continuity
SpecificationStandards DomainRelevant Standards Work
Namespace StandardNaming and identityCanonical naming authority, trust framework definitions, trust tier taxonomy
DillClaw ResolverResolution and routingTrust-aware resolution, relying party routing, trust policy enforcement, DNS architecture analogy
Registry SpecificationCryptographic trust infrastructureEd25519 signing model, revocation semantics, PKI trust-root architectural analogy (e.g., X.509)
Governance FrameworkInstitutional governanceMulti-stakeholder governance, neutrality preservation, amendment procedures, durable commons governance practice
DNSO Operations CharterOperational trust practiceTrust tier attestation evidence workflows, key management lifecycle, incident response, disclosure obligations
PKI Lineage Note

The Registry Specification uses Ed25519 signatures over canonical JSON with versioned signature prefixing. The trust root model — where a signing authority publishes its public key at a stable, TLS-protected URL and signs all registry records — follows, by analogy, the same architectural pattern as X.509 certificate authority infrastructure. Any relying party can independently verify registry records without trusting the registry itself, using only the published public key.

Forum Relevance

The specification domains above map most directly onto the work of ITU-T Study Group 17 (Security), and in particular Working Party 1 on Digital Identity and PKI. The trust tier model, cryptographic attestation approach, and PKI lineage position the stack as a natural discussion input for SG17's ongoing work on digital identity and trust frameworks for multi-party environments. The stack is also relevant to IETF working groups addressing agent coordination and cross-domain naming, and to NIST work on trust frameworks and identity. The forum most appropriate for standards discussion is a decision for the standards community rather than this project to make; this note identifies the natural mappings, not a claimed allegiance.

§ 04

Why Neutral Naming Authority Matters

A portable agent ecosystem cannot rely indefinitely on hardcoded provider endpoints, proprietary registries, prompt-local tool selection, or single-platform identity systems. As agents become persistent, stateful, and cross-domain entities, these dependencies create structural fragility in the trust layer.

The Dillweed proposal introduces a neutral naming authority layer capable of supporting cross-provider trust continuity, canonical identity preservation across administrative boundaries, verifiable resolver behavior, transparent revocation with mandatory audit evidence, and standards-aligned governance evolution toward multi-party institutional models.

The structural role is analogous to prior infrastructure layers:

Addressability
DNS
Stable naming above provider infrastructure
Trust Roots
PKI / X.509
Cryptographic binding independent of endpoint
Portability
Unix / POSIX
Composable primitives across execution contexts

The Dillweed stack proposes to play a structurally equivalent role for agent capability coordination: stable naming authority above the provider layer, cryptographic trust binding independent of the capability endpoint, and composable resolution primitives across administrative and runtime boundaries.

Neutrality Structural Condition

A namespace operated by a major platform participant would face an unavoidable neutrality challenge, because 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 structured to keep separate. The dillweed.com domain has been under continuous independent single-owner stewardship since 1997, providing an unusual independent provenance basis for a neutral naming authority layer that a platform entrant would struggle to replicate credibly, while leaving formal multi-party governance evolution to the Governance Framework and Operations Charter.

§ 05

Current Maturity and Availability

The stack currently exists as published technical specifications, a governance framework, a DNSO operations charter, and Node.js reference implementations now operational in local deployment for the Registry, the DillClaw Resolver, and the Anthill Observability Plane. All specification documents are publicly available at dillweed.com; the reference implementations are running on local development infrastructure and are not yet exposed at public endpoints.

The stack is currently in its founding phase, with reference implementations now operational in local deployment, and is intended for standards dialogue and early experimentation rather than immediate production adoption.

ComponentStatusURL
Namespace Standard v0.4.3Published specificationdillweed.com/namespace-standard.html
DillClaw Resolver Spec v0.1.3Published specification; Node.js reference implementation deployed locallydillweed.com/dillclaw-spec.html
Registry Specification v0.1.4Published specification; Node.js reference implementation deployed locallydillweed.com/registry-spec.html
Governance Framework v1.1.3Published — canonical releasedillweed.com/governance.html
DNSO Operations Charter v1.0.3Published — canonical releasedillweed.com/dnso-operations-charter.html
Anthill™ Observability Plane Spec v0.1.2Published specification; Node.js reference implementation deployed locallydillweed.com/anthill-spec.html
Continuity Protocol GSP-01 v1.0.3Published — Founding Phasedillweed.com/continuity-protocol.html
Glossary v1.0.2Published — source-grounded reference companion (86 entries)dillweed.com/glossary.html

The immediate standards objective is dialogue around trust management, governance neutrality, trust tier attestation models, and cross-domain naming authority for portable agent ecosystems. The founding-phase governance structure is explicitly designed to evolve toward multi-stakeholder institutional models as adoption develops — the transition trigger is ecosystem participation rather than a fixed date.

§ 06

Discussion Prompt for Standards Bodies

Themes commonly raised in SG17-adjacent trust management discussions — that discovery requires a significant zoom in, that trust management is the common denominator between human and agentic AI, and that a digital identity stack agreed by all parties is needed — map directly onto the architectural problem this stack addresses.

Framing Question

How should trust, naming authority, trust tier attestation, revocation, and governance continuity operate when portable agents move across administrative and provider boundaries — and what structural conditions must a neutral naming authority satisfy to be credibly trusted by all parties?

The Dillweed stack is offered as a concrete architectural proposal for that discussion — a published reference architecture with accompanying reference implementations now operational in local deployment, covering the namespace, resolution, registry, governance, and operational layers that the pre-standardisation conversation requires as a reference point.

The Dillweed Anthill™ Observability Plane, listed as a supporting document in §05, provides operational visibility across this stack and is now in local deployment alongside the core reference implementations.

Inquiries and engagement may be directed through dillweed.com.