This charter defines the operational practices of the Dillweed Namespace Stewardship Organization (DNSO) — the founding steward body responsible for operating the Dillweed Namespace during the founding phase. It translates the authority structures defined in the Governance Framework into concrete procedures: how trust is attested, how keys are managed, how revocations are executed, how incidents are handled, and what operational commitments the DNSO makes to the ecosystem.

This charter is a working document. It describes what the DNSO actually does, not aspirational standards that exceed current operational capacity. Commitments stated here are commitments the founding steward can keep.

This charter governs DNSO operational practice during the founding phase of the Dillweed Namespace Project. It operates within a defined stack of governing documents, each with distinct authority over different aspects of the project.

2.1 Conflict Resolution

In the event of an apparent conflict between this charter and any of the above documents, the following precedence order applies: Governance Framework, then Namespace Standard, then Registry Specification, then DillClaw Resolver Specification, then this charter. Conflicts should be logged as amendment candidates for the affected document rather than resolved through informal interpretation. The founding steward is responsible for identifying and surfacing such conflicts.

The DNSO is the operational steward of the Dillweed Namespace. Its mission is to maintain the namespace as a neutral, trustworthy, and durable coordination layer for AI agent capability discovery — operated in the interest of the ecosystem, not any single participant.

3.1 Core Responsibilities

• Registry operation — Maintain the authoritative Dillweed Registry at a stable endpoint, ensuring records are durably stored, cryptographically signed, and accurately served.
• Trust attestation — Review and confirm trust tier elevations to verified and canonical for qualifying registrants.
• Key custody — Maintain exclusive custody of the DNSO Ed25519 signing keypair with appropriate security and backup procedures.
• Revocation authority — Exercise revocation authority promptly when required by governance or security events.
• Public disclosure — Maintain transparency with the ecosystem through timely disclosure of governance events, key operations, and material operational changes.
• Spec stewardship — Maintain and evolve the specification stack in accordance with the governance framework's amendment procedures.
• Neutrality preservation — Decline arrangements that would compromise the namespace's neutrality thesis, as defined in the Governance Framework §3.

Trust tier attestation is the process by which the DNSO confirms that a self-declared verified or canonical tier declaration is substantiated. Until the DNSO issues attestation, such declarations are provisional and resolvers should apply weighting penalties as specified in the Registry Specification §7.

4.1 Attestation Process — Verified Tier

4.2 Attestation Process — Canonical Tier

The canonical tier is DNSO-designated only and is not available by registrant request. The DNSO may designate a canonical capability when a clear reference implementation exists for a namespace category and no reasonable dispute about its primacy exists. Canonical designations are logged publicly and may be withdrawn if circumstances change.

4.3 Attestation Response Time

During the founding phase, the DNSO targets a response to attestation requests within 14 calendar days. This is a target, not a guarantee. See §10 for the full service level posture.

The DNSO Ed25519 signing keypair is the cryptographic root of trust for the entire namespace. All Capability Records are signed with the DNSO private key. Its integrity and security are the single most critical operational responsibility of the DNSO.

5.1 Key Custody Requirements

• Storage — Private key stored at file mode 0600 on the registry host, outside the database, never in version control.
• Backup — Minimum two encrypted backup copies on physically separate media (e.g. encrypted USB drive in a separate physical location, encrypted password manager vault). Backup integrity verified at least monthly.
• Transmission — Private key never transmitted over any network interface. Public key published at dillweed.com/dnso_public.pem over HTTPS.
• Access — Private key access restricted to the founding steward during the founding phase. Access log maintained.

5.2 Planned Key Rotation

The DNSO should perform planned key rotation at intervals no greater than 24 months. Rotation procedure:

5.3 Emergency Keypair Reset

If the private key is compromised or lost, an emergency keypair reset is required. This is a registry trust reset event: all existing signatures become unverifiable under the old key. The DNSO must immediately generate a new keypair, publish the new public key, re-sign all active records, and issue a public disclosure with the nature of the incident and remediation steps taken. Emergency resets are logged as critical incidents under §8.

Revocation is the governance mechanism that makes trust tiers meaningful. The DNSO exercises revocation authority to remove bad actors, retire stale capabilities, and maintain the integrity of the namespace.

6.1 Revocation Triggers

• Endpoint failure — A registered endpoint has been unreachable for 90 consecutive days with no registrant contact.
• Identity fraud — A registrant is found to have misrepresented their organizational identity during attestation.
• Malicious capability — A registered capability is found to cause harm to consuming agents or their operators.
• Governance violation — A registrant has violated the terms under which a tier was attested.
• Registrant request — The registrant requests retirement of their own capability.
• Namespace collision — A registration is found to conflict with an existing canonical capability in a way that creates harmful ambiguity.

6.2 Revocation Process

6.3 Emergency Revocation

For malicious capabilities or active security incidents, the DNSO may execute immediate revocation without advance notice. Emergency revocations are disclosed publicly within 48 hours of execution.

Transparency is a core operating principle of the DNSO. The following events require timely public disclosure at dillweed.com or an equivalent canonical disclosure channel:

8.1 Incident Classification

8.2 Private Key Compromise Response

A compromised private key is the most severe incident the DNSO can face. Upon confirmed or suspected compromise:

• Take the registry offline immediately to prevent further signing under the compromised key
• Execute emergency keypair reset per §5.3
• Issue public disclosure within 48 hours including the nature of the compromise, the scope of potentially affected records, and the remediation steps taken
• Notify any known implementers or institutional partners directly
• Document the incident fully in the operational log for governance review

8.3 Registry Unavailability

DillClaw Resolvers are designed to operate from cached records during registry downtime, disclosing staleness to callers. Extended unavailability degrades the namespace's utility but does not break existing resolution. The DNSO should prioritize registry restoration and communicate status and estimated restoration time through the public disclosure channel during extended outages.

9.1 Backup and Durability

• Database backup frequency — Daily automated backup of data/registry.db to at least one off-host location.
• Keypair backup — As specified in §5.1. Backup integrity verified monthly.
• Backup restoration test — Full restoration from backup tested at least once every six months. Target restoration time from the most recent verified backup is 24 hours during the founding phase.
• Audit log retention — Registration log retained indefinitely. No rows may be deleted or modified.

9.2 Software Maintenance

• Node.js runtime and better-sqlite3 dependency kept within one major version of current stable release.
• Security advisories for dependencies reviewed within 7 days of publication.
• Registry software updates tested against the existing database before deployment to the production instance.

9.3 Monitoring

During the founding phase the DNSO operates with best-effort monitoring appropriate to a single-steward operation. The /health endpoint is the primary operational signal. External uptime monitoring is recommended but not required in the founding phase. As adoption grows and institutional partners appear, monitoring expectations will be formalized.

The Dillweed Namespace is operated by a single founding steward. This section states the honest service level posture for the founding phase — not enterprise SLAs, but clear expectations that registrants and implementers can rely on.

During the founding phase, all DNSO communications are channeled through dillweed.com. The following contact categories are recognized:

• Attestation requests — Registrants seeking trust tier attestation should initiate contact through dillweed.com with the capability name, version, and evidence of operator identity as described in §4.1.
• Registration inquiries — Questions about namespace path selection, protocol compatibility, or the registration process may be directed through dillweed.com.
• Security disclosures — Responsible disclosure of security vulnerabilities or operational concerns should be sent to the DNSO contact channel. The DNSO commits to acknowledging security disclosures within 7 days.
• Institutional partnership — Organizations seeking implementer, contributor, infrastructure partner, or governance participant relationships should initiate contact through dillweed.com, referencing the Governance Framework §7 for the categories of engagement available.
• Public disclosures — Operational disclosures required under §7 will be published at dillweed.com and referenced from the governance document's disclosure log.

This charter is subject to the amendment process defined in the Governance Framework §5.6. During the founding phase, amendments require concurrence of the founding continuity seat. Once the Technical Steering Committee is constituted, amendments additionally require TSC majority concurrence and 30-day Participant Council review.

Operational changes that do not alter the charter's stated commitments or conflict with the governing documents may be implemented by the founding steward without formal amendment. Changes that reduce stated commitments, alter disclosure obligations, or affect registrant or implementer expectations require formal amendment.