This charter defines the operational practices of the Dillweed Namespace Stewardship Office (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.

Conformance Terminology

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC 2119] [RFC 8174] when, and only when, they appear in all capitals, as shown here. Most of this charter is operational prose; normative language is used sparingly and concentrates in §5 (key custody), §6 (revocation), §7 (disclosure windows), §8 (incident response), and §9 (registry operations). Internal organizational language about how the DNSO conducts its own work is deliberately left in plain prose. The service-level posture in §10 is stated as honest best effort during the founding phase and is not written as RFC 2119 commitments.

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.

Cross-document version references in this and other Dillweed specifications are shown at major.minor granularity (e.g., v0.4 rather than v0.4.1) by deliberate convention, to keep architectural cross-references stable across patch releases. Exact current versions of each document are tracked in the Standards Overview's maturity table.

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 DNSO Operations Charter, then Anthill Observability Plane Specification. For matters of stewardship succession, key custody transfer, or continuity transition, GSP-01 (Continuity Protocol) controls within the scope delegated to it by the Governance Framework. 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, initially in local founding-phase deployment and later at a stable public 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 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 acknowledges attestation requests within 14 calendar days of receipt. Substantive attestation decisions are targeted as capacity permits and are not subject to a fixed completion deadline. Acknowledgment is a commitment to confirm receipt and note that review is underway; it is not a commitment to a substantive decision within the same window. See §10 for the full service level posture.

The DNSO Ed25519 signing keypair is the cryptographic root of trust for the entire namespace. During the founding phase, all authoritative 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 MUST be stored at file mode 0600 on the registry host, outside the database, and MUST NOT be committed to version control.
• Backup — At minimum two encrypted backup copies on physically separate media (for example, an encrypted USB drive in a separate physical location, and an encrypted password manager vault) MUST be maintained. Backup integrity MUST be verified at least monthly.
• Transmission — Private key MUST NOT be transmitted over any network interface. The public key is published at dillweed.com/dnso_public.pem over HTTPS.
• Access — Private key access is restricted to the founding steward during the founding phase. An access log MUST be 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 MUST be disclosed publicly within 48 hours of execution.

Where immediate public disclosure of technical detail would materially worsen active exploitation, the DNSO may withhold technical detail from the initial disclosure while still disclosing that an emergency revocation has occurred and naming the affected capability. Full technical detail MUST follow within 30 days of the emergency revocation, or within 7 days of the upstream vulnerability being patched, whichever comes first. The 30-day hard cap protects the disclosure commitment while preserving the active-exploitation carve-out; it is not extensible by the DNSO acting alone.

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 the DNSO MUST:

• 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 prioritizes registry restoration and communicates status and estimated restoration time through the public disclosure channel during extended outages.

9.1 Backup and Durability

• Database backup frequency — A daily automated backup of data/registry.db MUST be written to at least one off-host location.
• Keypair backup — As specified in §5.1. Backup integrity MUST be verified monthly.
• Backup restoration test — Full restoration from backup MUST be tested at least once every six months. The target restoration time from the most recent verified backup is 24 hours during the founding phase.
• Audit log retention — The registration log MUST be retained indefinitely. No rows may be deleted or modified.
• Operational log integrity — Operational log entries MUST be append-only and MUST NOT be altered retroactively except through superseding correction entries that reference the original entry being corrected. This immutability requirement mirrors the registry's audit discipline and ensures the log remains a reliable governance record.

9.2 Software Maintenance

• Node.js runtime and better-sqlite3 dependency SHOULD be kept within one major version of current stable release.
• Security advisories for dependencies MUST be reviewed within 7 days of publication.
• Registry software updates MUST be tested against the existing database before deployment to the authoritative registry 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 Anthill Observability Plane (v0.1) specifies the cross-stack signal taxonomy, aggregation windows, and DNSO review cadences; it specifies how several monitoring obligations described in this charter may be instrumented, aggregated, and reviewed as the project matures.

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 a canonical disclosure record maintained by the DNSO.

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.