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

The existing 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.

Forthcoming Architectural Decisions

This specification is a v0.1.x line and is candid about its open questions. Several substantive architectural decisions remain to be resolved beyond the current revision, not merely refinements of drafting. These include: the cross-specification hook interfaces by which Registry and Resolver implementations emit signals to the aggregation layer (Anthill §3 and §5; Registry Specification Appendix A.5; DillClaw Resolver Specification Appendix A.7); the syntactic-versus-semantic distinction within ANT-DN signal payloads (Appendix A.5); the heartbeat-and-detection mechanism by which signal absence becomes itself an observable (Appendix A.6); the reporter-incentive architecture that resolves the principal-agent tension between faithful reporting and self-incrimination (Appendix A.7); the data-minimization model for relying-party signal submission in tension with the no-centralized-surveillance posture stated above (Appendix A.8); and whether to adopt the Registry-as-reference-monitor framing as the spec's organizing principle for signal evidentiary architecture (Appendix A.10), a framing decision with consequences for §3, §4, §5, §6, §11, and the priority of cross-specification hook design. The appendix entries name the design space; they do not commit to specific resolutions. As described in the Appendix A introduction, these revisions are expected to land as separable changes rather than as a single coordinated release, sequenced according to design readiness and operational conditions, with attribution to public-review contributors who surfaced the relevant tensions.

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 document is narrative and architectural; the normative content concentrates in §4 (signal metadata), §5 (aggregation immutability), §6 (stewardship cadences), and §8 (implementation behavior).

Anthill occupies the observational plane across the Dillweed stack — 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. Governance authority — who sets policy, who can exercise revocation, how decisions are accountable — is specified in the Governance Framework; operational procedure for exercising that authority is specified in the DNSO Operations Charter. Neither document is a layer of the technical stack; they are the governance instruments that direct DNSO behavior within it.

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.2 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 future capability and is addressed in Appendix A. 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.

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. Based on the review summarized in the Status Note above, 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.

Field Observation: Pre-Deployment Key Fetch Activity

On May 3, 2026, the DNSO public key (dnso_public.pem) was published at https://dillweed.com/dnso_public.pem for the first time, establishing the anchor for DNSO signature verification across the namespace stack. Within hours of publication, server access logs recorded multiple automated fetches of the public key by external systems — including at least one AI system crawler operating under a recognized user agent — ahead of any public announcement or documentation update pointing to the endpoint.

This observation is significant for two reasons. First, it confirms that once a DNSO signing key URL is published, external systems will begin attempting signature verification autonomously and without coordination — validating the operational reality that the Anthill ANT-TC monitoring class is designed to address. Second, it establishes that the gap between key publication and key fetch can be measured in hours rather than days, making the key lifecycle monitoring described in §4 an immediate operational concern rather than a future one. The Anthill aggregation layer is designed to make this class of activity continuously visible to the DNSO rather than discoverable only through manual log review.

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 — RFC 3339 date-time in UTC with the Z offset and second precision (YYYY-MM-DDTHH:MM:SSZ). Non-UTC offsets and fractional seconds MUST NOT be used. This matches the timestamp convention used across the Dillweed stack (see Registry Specification v0.1 §3.1).
• 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 MUST reject 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
• 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

Replay and Collision Handling

If the aggregation layer receives a signal whose signal_nonce matches a previously accepted signal from the same originating_node, the signal MUST be rejected as a replay attempt. The aggregation layer MUST additionally generate a CRITICAL-severity ANT-RA (Resolver Abuse) signal naming the offending node. Nonce collisions at 128-bit random generation are statistically negligible in the absence of a broken RNG, implementation bug, or deliberate replay; a collision therefore indicates one of those conditions and warrants escalation regardless of cause.

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 Node.js reference implementation of the Anthill aggregation layer is now operational in local deployment, consistent with the DillClaw Resolver and Registry reference implementations also operating in local deployment. Future packaging for distribution is tracked in Appendix A.

Resolver Node Instrumentation

DillClaw resolver nodes that participate in Anthill reporting 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.

Timestamp Integrity: Known Limitation

The current specification relies on two timestamp sources: signal_timestamp, which is supplied by the submitting node, and received_at, which is recorded by the aggregation layer at ingestion using its local system clock. Neither value is cryptographically bound to an external time authority. This creates a class of evidentiary limitation that implementers and relying parties should understand.

A submitting node may supply an arbitrary signal_timestamp value — backdated, forward-dated, or imprecise — without detection. The nonce and node_sequence replay-protection mechanisms specified in §4 prevent duplicate submission and out-of-order replay, but they do not validate temporal accuracy of the timestamp field itself. Similarly, if the system clock of the aggregation host is manipulated, received_at values recorded during the manipulation window will reflect the manipulated time. This does not corrupt the database structure or the nonce integrity of other records; it introduces only timestamp inaccuracy for signals received during that window.

The practical consequence is that the current v0.1.1 implementation satisfies the immutability requirement — records are written once and never mutated — but does not satisfy the stronger admissibility standard that Jeremy Bouedo identified in the context of this specification's public review: a neutral observer whose evidence must survive challenge before a regulator six months after the fact. An append-only log with manipulated timestamps is still append-only; it simply cannot prove what it claims about time ordering without external corroboration. For deployments where timestamp admissibility matters, RFC 3161 trusted timestamping is the appropriate upgrade path. See Appendix A.4.

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.2) defines the normative framework within which operational parameters are applied; parameter values are maintained by the DNSO and published in the operational log. Parameter publication format is addressed in Appendix A.

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

This appendix records items intended for a future revision of the Anthill Observability Plane Specification. It is non-normative: nothing in this appendix imposes conformance requirements on implementations of v0.1.2. It is included to disclose the anticipated direction of the specification so that implementers can make informed decisions about extensibility and ecosystem participants can plan for forthcoming changes.

The items in this appendix are not committed to a single coordinated release. The DNSO will sequence these revisions as separable changes, with each landing when its design work has matured and operational conditions warrant. This phased posture, suggested in public review of v0.1.2, reflects how working specifications typically evolve: by separable design decisions rather than monolithic versioning.

A.1 Relying-Party Signal Origin

The current specification defines three classes of signal origin: resolver nodes, registry operations, and DNSO-internal processes (§3). A future revision is expected to introduce a fourth origin class — relying-party reporting — allowing authenticated downstream consumers of the namespace to submit signals when they encounter trust failures, stale revocation evidence, unexpected resolver behavior, or attestation mismatches. This is among the primary subsequent development paths for the specification.

Introducing relying-party signal origin creates tension with the §8 Privacy and Data Minimization commitment: a relying party reporting a trust failure may reasonably wish to identify which agent encountered the failure, which begins to touch agent identity. A future revision is expected to resolve this tension by defining a constrained identity disclosure model in which relying parties identify themselves and the affected resolver node but do not disclose end-user or agent identity except under specific governance conditions. This change will affect §3 (signal origin model), §4 (signal metadata), and §8 (privacy).

A.2 Reference Implementation

A packaged Node.js reference implementation of the Anthill aggregation layer is planned, consistent with the reference implementations published for the DillClaw Resolver and the Dillweed Registry. The reference implementation will include: the HTTPS aggregation endpoint with Ed25519 signature validation; the nonce and node_sequence replay-protection logic specified in §4; the three aggregation windows specified in §5; a minimal threshold escalation engine; and an append-only log satisfying the immutability requirement in §5. Resolver-side instrumentation hooks and Registry-origin signal hooks described in §8 will ship as separate modules integrated into the existing reference implementations.

A.3 Operational Parameter Publication Format

Anthill operational parameters — threshold values per signal class, aggregation window tuning, cross-signal correlation rules — are versioned separately from this specification (§8). The exact publication format for operational parameters is not specified in v0.1.2. A future revision is expected to define: a machine-readable parameter schema (expected to be JSON with an accompanying JSON Schema validation document); a DNSO-signed parameter manifest that resolvers can fetch and validate; and a change-notification mechanism so that resolver operators can discover parameter revisions without polling. This change will affect §8.

A.4 External Timestamp Anchoring (RFC 3161)

The v0.1.1 reference implementation records two timestamp values per signal — signal_timestamp (supplied by the submitting node) and received_at (recorded by the aggregation host at ingestion). Neither is cryptographically bound to an external time authority. As documented in §8, this satisfies the immutability requirement but not the stronger admissibility standard — a manipulated system clock produces incorrect received_at values that the immutable log faithfully preserves without any indication of manipulation.

A future revision is expected to address this through RFC 3161 trusted timestamping at the aggregation layer. Under this approach, upon accepting a valid signal, the aggregation endpoint computes a hash of the canonical signal record and submits it to a trusted timestamping authority (TSA) operating under RFC 3161. The TSA returns a signed timestamp token — a cryptographic assertion by the TSA that the submitted hash existed at a stated time. This token is stored alongside the signal record and is independently verifiable by any party with access to the TSA's public certificate chain, without requiring trust in the aggregation host's system clock.

This upgrade path does not require changes to the signal submission protocol or the nonce and sequence replay-protection mechanisms. It adds a post-ingestion step at the aggregation layer only. The resulting signal record would include a tsa_timestamp_token field containing the RFC 3161 token in base64 encoding, and a tsa_url field identifying the TSA used. Records ingested before this capability was enabled would have null values in these fields, providing a clear demarcation between pre- and post-anchored signal history.

The practical consequence, as Jeremy Bouedo observed in public review of this specification, is that the distinction between a neutral observer that exists and one whose evidence survives challenge is resolved at the timestamp layer. Nonce and sequence integrity prove that no signal was replayed. RFC 3161 timestamps prove that a signal existed at a stated time independently of the aggregation host's clock. Together they constitute an admissible record — one a regulator or auditor can evaluate without requiring trust in the DNSO's own infrastructure.

A.5 ANT-DN Failure-Class Distinction

The current ANT-DN signal class (§3) treats deceptive namespace path activity as a single category, framed primarily in adversarial terms — systematic probing of unregistered identifiers, impersonation of registered paths, bypass of the standard trust verification chain. In practice, the wire-level traffic produced by an adversary probing for unregistered paths is indistinguishable from the traffic produced by an agent built on a language model that hallucinates capability paths it expects to exist. Both produce well-formed queries against capability identifiers that do not resolve. Without a payload-level distinction, ANT-DN aggregation conflates integration immaturity with adversarial intent, and the response posture defined in §11 cannot differentiate operator-actionable signals (a deployed agent producing many semantic misses, indicating a model that needs better grounding) from security-actionable signals (a coordinated probing campaign, indicating an attempted attack).

A future revision is expected to add a lookup_failure_class field to the ANT-DN signal payload schema with two enumerated values: syntactic for parse errors, malformed identifiers, length violations, or other failures detectable before any registry lookup is attempted; and semantic for well-formed queries against capability identifiers that have no matching record. Aggregation logic at the DNSO would then evaluate syntactic-heavy and semantic-heavy patterns against distinct thresholds, with syntactic-heavy patterns producing operator-coordination guidance to the affected agent operator and semantic-heavy patterns producing the security-oriented response described in §11. The signal class name and description would also be revised to acknowledge the broadened scope: ANT-DN surfaces both adversarial probing and integration anomalies, and the response protocol in §11 would gain a corresponding integration-anomaly path. This change will affect §3, §6.1, and §11.

A.6 Signal-Absence Detection

The current signal taxonomy (§3) defines six classes of positive observation — events the resolver and registry layers report when something noteworthy happens. The taxonomy does not address the converse case in which a node previously emitting signals goes silent. From the aggregation layer's perspective, a compromised resolver whose signal-generation code has been disabled, a network partition that isolates a node from the aggregation endpoint, and a node operating normally but with no anomalies to report are presently indistinguishable: all produce the same quieter feed. In a distributed observability plane intended to detect coordinated abuse of the namespace, the absence of expected signals is itself a load-bearing observable — particularly under threat models in which an attacker's first move is to silence the monitor.

A future revision is expected to address this through a heartbeat-and-detection pair. Each node generating Anthill signals would emit a periodic INFORMATIONAL signal (provisionally named ANT-HB, Heartbeat) at a defined interval, attesting continued operation, current signal-generation code version, and active signing key identifier. The aggregation layer would maintain expected-heartbeat tracking per registered node and would generate a derived anomaly signal (provisionally named ANT-NU, Node Unavailability) when expected heartbeats fail to arrive within tolerance. Heartbeat interval and missed-heartbeat thresholds would be DNSO-maintained operational parameters versioned per Appendix A.3. The interaction with the no-centralized-surveillance posture stated in §1 requires careful design: heartbeats convey only liveness and version state, not behavioral telemetry, and the aggregation layer's expected-set is derived from public node enrollment rather than from inferred activity. This change will affect §3, §4, §5, §8, and §11, and may warrant promotion of the heartbeat-and-detection pair to a §3 signal-class entry rather than treatment as an Appendix A future-work item alone, depending on the design path selected.

A.7 Reporter-Incentive Alignment

The current Anthill design assumes that resolver nodes are reliable reporters of their own behavior. Several signal classes — most directly ANT-RA, but indirectly ANT-DN, ANT-WF, ANT-RC, and ANT-EC — require nodes to emit signals that may become evidence in subsequent governance review of those same nodes. This creates a principal-agent tension: an operator who reports faithfully exposes themselves to audit attention, while an operator who suppresses noisy reporting reduces that exposure. Over time, the population of "compliant" reporters becomes the population that has not yet had a serious incident, while operators who have had incidents have learned to report less. The current specification offers no mechanism that resolves this tension; it relies on operator goodwill and on the broader incentives of namespace participation.

A future revision is expected to address this through one or both of the following architectural directions. Reporter-reputation registers — a separate operator-level register, distinct from capability-level trust scores, that reflects observability-reporting fidelity and surfaces in operator-facing contexts (DNSO partnership decisions, mirror operator selection, trustee eligibility) rather than in caller-facing trust scores. The cleanest design preserves the layering boundary: trust tiers continue to express capability authenticity, while operator stewardship reputation runs alongside on its own surface. External corroboration is a tool available within this direction: signals that can be cross-validated against Registry-side records, peer-resolver observations, or relying-party reports carry stronger evidentiary weight than signals that stand alone, and a reputation register can reflect that distinction without committing to a specific reward or penalty schedule. Verifiable signal-completeness attestation — a complementary cryptographic mechanism in which each node periodically signs and publishes a Merkle root over the signals it generated in a window, such that suppression becomes retrospectively detectable when other observers (relying parties, peer resolvers, audit reviewers) report signals that should have been included but were not. This shifts a portion of the problem from incentive design to verifiable-completeness design, which is more aligned with the rest of the Dillweed stack's reliance on signed records and append-only logs. Reputation registers and completeness attestation address different temporal scales — reputation surfaces patterns that emerge over operational windows of weeks or months, while completeness attestation provides per-event cryptographic evidence within a single window. The two are architecturally complementary across the time dimension rather than alternatives within the same time scale. Either or both directions may be selected; the design choice will balance mechanism complexity against attack surface. This change will affect §4, §5, §8, and §11, and is one of the substantive architectural decisions to be resolved in subsequent revisions of this specification.

A reputation-register design must also address the bootstrap problem for new operators. When the first non-DNSO-operated resolver node comes online, it has no reputation history, and the principled answer to "what initial value does it receive" is not obvious. A zero-reputation seed creates a chicken-and-egg barrier in which the only way to earn standing is to operate, but operating requires standing. A full-reputation seed creates Sybil exposure in which an adversary can spin up fresh nodes for short-horizon misbehavior and discard them before reputation degrades meaningfully. The architectural shape of a workable answer is likely to derive newcomer seed values from primitives the stack already provides — most plausibly the Registry's own attestation tier for the operator's identity record, such that an operator entering at the Registry's verified tier seeds at a different reputation than one entering at the experimental tier, with reputation maturation tracked over operational time. This couples Anthill operator reputation to Registry attestation rather than treating them as independent surfaces, and it makes the bootstrap problem a cross-specification design point rather than an Anthill-internal one.

A.8 Relying-Party Data Minimization

Appendix A.1 anticipates a fourth origin class for signals — relying-party reporting — in which agents and other namespace consumers submit observations of trust failures, stale revocation evidence, unexpected resolver behavior, and attestation mismatches that operator-side monitoring may not surface. A diagnostic-quality relying-party signal must carry enough detail for a DNSO investigator to determine why a trust verification failed: the queried capability identifier, the resolver node consulted, the trust signals received and the relying party's evaluation, the failure mode encountered, and the timestamp. Several of these fields are sensitive from the relying party's perspective. They reveal the relying party's invocation patterns, network topology, operational policy, and definition of acceptable behavior. The aggregate of such reports submitted to a central log is, from the relying party's perspective, indistinguishable from surveillance — directly in tension with the no-centralized-surveillance posture stated in §1.

A future revision is expected to address this tension explicitly, recognizing that no clean global resolution is available — the design choice will likely be made per signal class rather than uniformly. Three architectural directions are under consideration. Pseudonymized payload with relying-party-held de-pseudonymization key — relying parties report under a stable pseudonym signed by their own key, with the binding to operator identity held privately by the relying party. The DNSO observes patterns of failure across the ecosystem but cannot identify individual relying parties without voluntary de-pseudonymization. Tiered detail with relying-party-controlled disclosure — initial signals carry only the minimum information necessary to detect the failure category; the DNSO acknowledges receipt and may request additional detail through a structured back-channel, with the relying party deciding whether to provide it. Analogous to the way RFC 9162 Certificate Transparency proves an event occurred without requiring identification of the reporter. Aggregated submission via trusted intermediaries — relying parties submit to operator-level or industry-level aggregators that collapse multiple raw signals into a single anonymized population signal before submitting to Anthill. This loses individual-incident granularity but preserves population-level signal. Different signal types likely warrant different mechanisms: population-health signals plausibly via aggregation; specific-resolver-misbehavior signals plausibly via pseudonymization with per-incident de-pseudonymization. This change will affect §1, §2, §3, §4, and §11, and is one of the substantive architectural decisions to be resolved in subsequent revisions of this specification.

A.9 Implementation Onboarding Documentation

This specification is a normative architecture and signal-taxonomy document. It does not host implementation-level guidance — sample configuration files, environment-variable schemas, quickstart command sequences, integration test fixtures, or operator-facing runbooks for deploying a conformant Anthill participant node. As the Node.js reference implementation matures and as external operators begin configuring resolver nodes that emit Anthill signals, that material will become important to ecosystem participation but does not belong inside this specification: configuration shapes evolve faster than specifications, and mixing the two would commit the spec to a maintenance burden inconsistent with its standards-facing role.

A separate implementation guide, developer portal, or operator handbook is the appropriate venue for this material and is anticipated as a future deliverable of the DNSO. The spec text will reference such documentation when it exists, but will not absorb it. This appendix entry exists to make the gap explicit so that reviewers and prospective implementers can locate it as an intentional boundary of scope rather than an oversight.

A.10 Registry as Reference Monitor for Signal Verification

The current specification (§3) defines six signal classes as architectural peers, all flowing into the aggregation layer with equal evidentiary status. This framing is correct at the wire level but obscures a deeper structural pattern: the six classes do not all originate at the same architectural layer, and their evidentiary weight depends on whether the originating layer is the authoritative source of the underlying truth claim. ANT-EC (Ecosystem Concentration Risk), ANT-RC (Revocation Cascade), and ANT-TC (Trust Tier Drift) are Registry-native in the sense that the Registry holds the authoritative state against which the claim is made — namespace-wide capability distribution, revocation log state, attestation tier transitions. Resolver-side observations of these phenomena are partial and local; the Registry sees the whole. ANT-RA (Resolver Abuse), ANT-DN (Deceptive Namespace Path Activity), and ANT-WF (Well-Formedness) are resolver-native with Registry verification: the resolver observes the field event, but the claim that the event is anomalous is verifiable only by comparison against canonical Registry state.

If this pattern is accepted as the spec's organizing principle for evidentiary architecture, the Registry occupies the position of reference monitor for signal verification — the authoritative source against which other layers' claims become confirmable, contradictable, or shown to be inconsistent with canonical state. This has three consequences worth surfacing. First, signal-class metadata in a future revision could explicitly document each class's corroboration model: origin layer, corroboration layer, and the canonical state the claim is verifiable against. Second, the aggregation layer's threshold calculation (§6) and response posture (§11) could weight signals by corroboration depth — a standalone resolver-side claim carries some evidentiary weight; the same claim corroborated by Registry-side divergence detection carries substantially more. Third, this framing partially strengthens the response to the principal-agent tension named in A.7: a resolver emitting false claims about its own behavior is detectable through Registry-side verification against canonical state, narrowing the surface for fraudulent reporting independently of operator goodwill.

This recognition is not a new mechanism — the six signal classes already function evidentially in this way in any deployment. It is a framing decision about whether the specification should make the pattern explicit and organize subsequent revisions around it. The question is appropriate to resolve deliberately in a subsequent revision: adopting the reference-monitor framing would elevate the cross-specification hook interfaces tracked in Registry Specification Appendix A.5 from a peripheral coordination concern to a foundational evidentiary mechanism, and would justify the design effort that the hook interfaces require. Declining the framing would leave the six signal classes architecturally peer-level and the Registry-side hooks as one coordination concern among many. This change will affect §3, §4, §5, §6, §11, and the cross-specification coordination scope of A.5 in the Registry Specification.

The reference-monitor framing in this entry does not subsume the mechanisms named in A.6 (Signal-Absence Detection) or A.7 (Reporter-Incentive Alignment). The three appendix items address distinct failure modes and are architecturally complementary rather than alternatives. A.6 detects node absence — the case where a node has stopped emitting any signals and the aggregation layer must distinguish silence from quietude. Reference-monitor verification has no purchase on signals that were never sent; the Registry can observe that no signals are arriving, but doing so is itself a heartbeat-detection mechanism in different clothing, and the Registry's own observations of resolver query traffic are ambiguous between a silenced node and a node operating from cache (DNSO Operations Charter §8.3). A.10 detects false claims — the case where a node emits signals that diverge from canonical state. A.7 detects suppression — the case where a node emits some signals while withholding others, which neither heartbeat nor canonical-state verification can identify because the suppressed signals are syntactically absent from the stream and the emitted signals are individually consistent with canonical state. An attacker capable of evading all three mechanisms must simultaneously maintain heartbeat flow, keep emitted claims canonically consistent, and produce coherent Merkle-root completeness attestations over windowed signal sets — a substantially harder attack surface than evading any single mechanism. A.10 enriches A.6 (the Registry can verify heartbeat content against the operator's canonical attestation record) and enriches A.7 (completeness attestations can be Registry-corroborated against expected signal patterns), but it does not replace either.

A.11 Node Key Registration and Signature Verification

The Signal Metadata Requirements in §4 mandate that each signal carry a node_signature — an Ed25519 signature over the canonical serialization of all preceding metadata fields, generated using the originating node's registered key. The §4 text states explicitly that the signature MUST cover signal_nonce and node_sequence to ensure authenticity of the replay-protection fields. The "Resolver Node Instrumentation" subsection of §8 further notes that resolver node key registration follows the procedure defined in the DNSO Operations Charter.

The current Anthill specification does not itself define the node-key registration procedure, the format of the registered-key store, or the verification semantics the aggregation layer applies when a signal arrives with a node_signature field. These properties are referenced as existing elsewhere (the Operations Charter), but the dependent specification — Operations Charter §-tbd — has not yet been drafted with the level of detail needed for an implementation to verify signatures end-to-end. The v0.1.x reference implementation accepts the node_signature field, stores its value, but does not verify cryptographically. This is a known gap between spec language and implementation behavior; both sides are awaiting the registration procedure to land.

A future revision is expected to address this through coordinated work across three documents. The Operations Charter would define the node-registration procedure: how a resolver node submits its public key to the DNSO, what attestation accompanies the submission, how registrations are revoked or rotated, and where the resulting registered-key store is published or accessed. The Anthill specification would then incorporate verification semantics in §4: when a signal arrives, the aggregation layer fetches the originating node's registered key, verifies the signature over the canonical metadata serialization, and rejects the signal with a documented error code if verification fails. The DillClaw Resolver Specification would describe the node-side instrumentation: how a resolver loads its registered key at startup, how it constructs the canonical serialization, and how it handles key rotation in coordination with the Operations Charter procedure.

Until that coordinated revision lands, the replay-protection mechanisms specified in §4 (signal_nonce uniqueness and node_sequence monotonicity) function at the protocol level but do not provide cryptographic authenticity guarantees — a node that knows another node's identifier and current sequence number can submit signals impersonating that node, and the aggregation layer cannot detect the impersonation. This is an architectural gap, not an implementation defect; it cannot be closed by changes to the Anthill reference implementation alone. This change will affect §4, §8, the Operations Charter, and the DillClaw Resolver Specification. It is the largest single deferred work item identified in the v0.1.2 conformance review.