Anthill is the Dillweed Namespace stack's cross-cutting observability plane for neutral infrastructure monitoring. This document specifies the Anthill Observability Layer — the sixth component of the Dillweed specification stack. Anthill defines the signal taxonomy, aggregation behavior, anomaly detection thresholds, and response protocols that enable the Dillweed Namespace Stewardship Organization (DNSO) to monitor the health, integrity, and fairness of the namespace ecosystem in operational deployment.

The existing five specification documents describe what the namespace is, how capabilities are resolved and registered, how governance authority is structured, and how the DNSO conducts its operations. Those documents describe obligations without specifying the tooling that fulfills them. Anthill closes that gap. It is the instrumentation layer that makes DNSO stewardship operationally credible rather than aspirationally documented.

Anthill occupies the observational layer above the Registry and DillClaw Resolver — it does not modify capability records, perform resolution, or make trust tier assignments. It observes, aggregates, and alerts. All authoritative operations remain with the Registry and DNSO signing authority as specified in the Registry Specification and DNSO Operations Charter.

The DNSO Operations Charter mandates that the DNSO monitor for capability abuse, trust tier integrity violations, and ecosystem concentration risk. Anthill is the specification of how those monitoring obligations are fulfilled. Where the Operations Charter describes the what, Anthill describes the how.

A governance framework that promises to detect abuse but specifies no mechanism for detection is not a governance framework — it is an aspiration. The Dillweed Namespace Project makes specific governance commitments that require operational visibility to fulfill:

• Trust tier integrity must be maintained across the full namespace lifecycle
• Revocation events must propagate correctly and completely across all resolver nodes
• No single capability provider should achieve ecosystem-level concentration that compromises namespace neutrality
• Resolver nodes must operate within their governance mandate and not serve fabricated or stale records
• Deceptive resolution attempts — agents attempting to circumvent attestation requirements — must be detectable

None of these obligations can be honored through document review alone. They require continuous observational infrastructure with defined signal types, aggregation behavior, and response thresholds. Anthill specifies that infrastructure.

Signal Origin Model

Anthill v0.1 defines three classes of signal origin: resolver nodes, registry operations, and DNSO-internal processes. A fourth origin class — relying-party reporting — is recognized as a planned v0.2 capability. In a mature zero-trust agent ecosystem, relying parties themselves are an important observational source: they encounter trust failures, stale revocation evidence, unexpected resolver behavior, and attestation mismatches that operator-side monitoring may not surface. Incorporating authenticated relying-party signal submission would transform Anthill from an operator-observable system into a genuinely ecosystem-observable system. This transition is identified as the primary v0.2 development path.

The Missing Observability Layer

As of April 2026, a substantial body of AI agent observability work exists at the application layer — what agents say, how they reason, which tools they invoke. No prior published specification addresses observability at the coordination layer — the infrastructure agents use to discover and invoke capabilities across organizational boundaries. Anthill fills that gap.

Anthill defines six primary signal classes. Each class corresponds to a distinct category of namespace ecosystem behavior that the DNSO is obligated to monitor. Signals are collected at resolver nodes and registry operations, transmitted to the Anthill aggregation layer, and evaluated against defined thresholds.

Signal Metadata Requirements

Each signal instance must carry the following metadata fields to support aggregation and audit:

• signal_class — one of ANT-TC, ANT-RC, ANT-DN, ANT-RA, ANT-WF, ANT-EC
• signal_timestamp — ISO 8601 timestamp of signal generation at the originating node
• signal_nonce — cryptographically random 128-bit value generated fresh for each signal instance; prevents signed signal replay attacks by ensuring no two signal submissions share an identical nonce
• node_sequence — monotonically increasing integer maintained per originating node; the aggregation layer rejects any signal whose node_sequence value does not exceed the last accepted sequence number for that node, preventing replay of previously accepted signals
• 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 as defined in the per-class schema below
• node_signature — Ed25519 signature over the canonical serialization of all preceding fields using the originating node's registered key; the signature must cover signal_nonce and node_sequence to ensure authenticity of replay protection fields

Anthill aggregation operates on a rolling time window basis. 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.

Aggregation Windows

Three aggregation windows are defined for different signal classes:

• 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

Threshold Escalation Model

Each signal class defines severity thresholds that trigger escalation from INFORMATIONAL through CRITICAL. Threshold values are operational parameters maintained by the DNSO and subject to adjustment as the namespace ecosystem matures. This specification defines the escalation structure; the DNSO Operations Charter governs response obligations at each severity level.

• 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; no immediate action required but pattern monitoring is 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 Operations Charter §6.3

Cross-Signal Correlation

The aggregation layer performs cross-signal correlation to identify compound anomaly patterns that do not individually exceed threshold but together indicate coordinated or systematic abuse. 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.

Anthill is not an autonomous enforcement system. It is an observational instrument that provides the DNSO with the visibility necessary to exercise its stewardship obligations as defined in the Governance Framework and DNSO Operations Charter. All enforcement actions — revocation, suspension, trust tier revision, resolver node decertification — remain with the DNSO and follow the procedures specified in those documents.

Stewardship Visibility Obligations

The DNSO steward is obligated to review Anthill aggregation outputs at the following cadences:

• Continuous — automated alerting for CRITICAL severity events; steward must acknowledge within 4 hours
• Daily — review of WARNING severity events generated in the prior 24-hour period
• Weekly — review of extended-window aggregation outputs for ANT-TC, ANT-WF, and ANT-EC signals; ecosystem health summary prepared for Participant Council visibility
• Monthly — full ecosystem health report submitted to Participant Council, including threshold breach counts by class, response actions taken, and any parameter adjustments made

Participant Council Transparency

Anthill aggregate health data — at the ecosystem level, not at the individual signal level — is reported to the Participant Council as part of the DNSO's transparency obligations under the Governance Framework. Individual signal records containing identifying information about specific resolver nodes or capability providers are not disclosed to the Participant Council absent a formal governance proceeding.

Neutrality Monitoring

The ANT-EC (Ecosystem Concentration Risk) signal class has specific relevance to the DNSO's neutrality obligations. The founding thesis of the Dillweed Namespace is that no single participant should achieve effective control over capability discovery. Anthill's concentration risk monitoring operationalizes this commitment — providing early warning when usage patterns approach concentration levels that would compromise the namespace's value as neutral infrastructure.

Each signal class has defined response protocol pathways that the DNSO follows when threshold escalation occurs. Response protocols are not automated — they are structured decision frameworks that the DNSO steward applies in evaluating the appropriate action given the signal context.

ANT-TC Response: Trust Tier Drift

Upon WARNING escalation, the DNSO initiates a trust tier audit for the affected capability. The audit evaluates whether the capability's operational attestation profile is consistent with its registered trust tier. If drift is confirmed, the DNSO may issue a formal notice to the capability registrant requiring either a trust tier elevation request or a reduction in operational scope. Unresolved drift at CRITICAL severity may result in trust tier revision through the Registry's administrative authority.

ANT-RC Response: Revocation Cascade

Revocation cascade failures — resolver nodes continuing to serve revoked capability records — trigger direct contact with the affected node operator. Node operators have 24 hours to resolve propagation failures upon WARNING escalation. Persistent propagation failure at CRITICAL severity may result in resolver node decertification per the DNSO Operations Charter.

ANT-DN Response: Deceptive Namespace Path Activity

Deceptive namespace path activity at WARNING severity triggers an investigation into the originating resolution requests. If the activity originates from a registered agent deployment, the DNSO notifies the relevant implementer organization. Activity that cannot be attributed to a registered participant is logged and monitored for pattern escalation. CRITICAL severity deceptive path activity may be referred to appropriate external parties depending on the nature and context of the activity.

ANT-RA Response: Resolver Abuse

Resolver abuse represents a direct violation of a node operator's governance obligations. WARNING escalation triggers immediate contact with the node operator and a 48-hour remediation window. Unresolved abuse at CRITICAL severity results in resolver node suspension pending investigation and, upon confirmation, decertification. The DNSO may additionally notify implementers relying on the affected node to redirect resolution traffic during the suspension period.

ANT-WF Response: Wildcard Fanout Anomalies

Wildcard fanout anomalies are evaluated in context — some high-frequency resolution patterns represent legitimate agent behavior at scale. DNSO investigation at WARNING severity focuses on distinguishing legitimate high-volume resolution from systematic capability enumeration. If enumeration is confirmed, the DNSO may implement rate limiting recommendations for the relevant resolver nodes and notify the Participant Council of the pattern.

ANT-EC Response: Ecosystem Concentration Risk

Ecosystem concentration risk does not trigger punitive action against any individual participant — high invocation volume is a consequence of market adoption, not a violation. The DNSO's response is analytical and communicative: issuing an ecosystem health advisory to the Participant Council, initiating outreach to encourage adoption diversity, and reviewing whether namespace structure or resolver behavior is inadvertently creating concentration pressure that could be mitigated through governance adjustment.

This version of the Anthill specification defines the conceptual architecture, signal taxonomy, aggregation model, and response protocol framework. A reference implementation of the Anthill aggregation layer in Node.js is planned as a packaged deployment artifact, consistent with the DillClaw Resolver and Registry reference implementations already published.

Resolver Node Instrumentation

DillClaw resolver nodes that wish to participate in Anthill reporting will require instrumentation additions to the reference implementation. The Anthill aggregation endpoint accepts signal submissions over HTTPS using Ed25519 signatures generated by the submitting node's registered key. Resolver node key registration follows the procedure defined in the DNSO Operations Charter.

Registry-Origin Signals

Certain signal classes — particularly ANT-TC (Trust Tier Drift) and ANT-EC (Ecosystem Concentration Risk) — are most accurately generated from Registry-side analysis rather than resolver observation. The Registry reference implementation will include hooks for generating these signals directly from registration and attestation activity, signed with the DNSO's canonical Ed25519 key.

Privacy and Data Minimization

Anthill signals must carry the minimum identifying information necessary to support the relevant analysis. Signal payloads must not include agent identity information, end-user data, or content of capability invocations. The observational scope of Anthill is limited to namespace infrastructure behavior — resolution patterns, trust tier transitions, revocation propagation — and does not extend to the content of agent operations conducted through the namespace.

Versioning and Parameter Management

Anthill operational parameters — aggregation windows, escalation thresholds, cross-signal correlation rules — are versioned separately from this specification document. Parameter versioning follows the Stack Family convention. This specification document version (v0.1) defines the normative framework within which operational parameters are applied; parameter values are maintained by the DNSO and published in the operational log.

Inquiries regarding the Anthill Observability Specification, implementation participation, or DNSO monitoring obligations may be directed through dillweed.com.