Dillweed Namespace Project · Standards-Facing Overview · April 2026

Dillweed Namespace Stack

A proposed trust and coordination layer for portable agentic systems — five-layer architecture 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
IssuedApril 2026
MaturityPublished Specifications
Stack Family2026.03
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 missing infrastructure layer is no longer model capability — it is stable naming authority, authoritative resolution, durable registry truth, and neutral governance continuity.

The stack addresses this gap through a five-layer architecture designed for multi-party trust management, cross-domain agent interoperability, cryptographic attestation, revocation, and operational accountability — intentionally aligned with the PKI trust root architecture that underpins existing international identity standards including X.509.

Its neutrality thesis is structural: no major platform company can credibly operate a neutral multi-party coordination namespace. The domain dillweed.com has been under continuous single-owner operation since 1997 — an independent provenance that satisfies the structural condition required for a neutral naming authority layer.

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.

§ 02

Layered Architecture

The stack comprises five layers, each with a distinct authority boundary and a defined standards-relevant question it answers. 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.

L1

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.

L2

DillClaw Resolver — Authoritative Resolution with Trust Policy Enforcement

How is the correct capability found?

Defines authoritative resolution behavior: namespace lookup, relying party routing with trust policy enforcement, deterministic selection across trust tiers, traceable failure semantics, and resolver-side weighting of provisional versus attested tier declarations. Provides verifiable audit trails for resolution decisions.

L3

Registry Specification — Authoritative Truth Substrate with Cryptographic Binding

What actually exists?

Defines the authoritative data layer: cryptographically signed capability records using Ed25519 — consistent with the PKI trust root architecture 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.

L4

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. Draws on Ostrom's design principles for durable commons governance. Explicitly prohibits arrangements that would transfer effective control to any single platform participant.

L5

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
Stack LayerStandards DomainRelevant Standards Work
Namespace StandardNaming and identityCanonical naming authority, trust framework definitions, trust tier taxonomy
DillClaw ResolverResolution and routingAuthoritative resolution, relying party routing, trust policy enforcement, DNS architecture analogy
Registry SpecificationCryptographic trust infrastructureEd25519 signing model consistent with PKI trust root architecture, revocation semantics, X.509 lineage compatibility
Governance FrameworkInstitutional governanceMulti-stakeholder governance, neutrality preservation, amendment procedures, Ostrom commons principles
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 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.

§ 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

No major platform company can credibly operate a neutral multi-party coordination namespace — any such namespace controlled by a single platform participant would be regarded with justified suspicion by the others. The dillweed.com domain has been under continuous single-owner operation since 1997, satisfying the structural condition for independent provenance that cannot be replicated by a platform entrant.

§ 05

Current Maturity and Availability

The stack currently exists as published technical specifications, a governance framework, a DNSO operations charter, and published Node.js reference implementations. All documents are publicly available at dillweed.com.

ComponentStatusURL
Namespace Standard v0.4Published specificationdillweed.com/namespace-standard.html
DillClaw Resolver Spec v0.1Published specification + Node.js reference implementationdillweed.com/dillclaw-spec.html
Registry Specification v0.2Published specification + Node.js reference implementationdillweed.com/registry-spec.html
Governance Framework v1.0Published — canonical releasedillweed.com/governance.html
DNSO Operations Charter v1.0Published — canonical releasedillweed.com/dnso-operations-charter.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

The SG17 workshop consensus — 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 — maps 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 working implementation of the namespace, resolution, registry, governance, and operational layers that the pre-standardisation conversation requires as a reference point.

Inquiries and engagement may be directed through dillweed.com.