The project began with a question that kept surfacing as agentic systems proliferated in 2025 and 2026. When an AI agent invokes a capability — a tool, a function, an endpoint that does something — an entire stack of infrastructure exists to answer who is on the other end of the connection (TLS, PKI, workload identity) and whether this caller may proceed (OAuth scopes, IAM, policy engines). Almost nothing existed to answer a different compound question about the capability itself:

The project called this capability standing, and its central observation was that the question falls between existing layers. Package registries answer it for static artifacts, not live endpoints. Certificate infrastructure answers it for identities, not behavioral contracts. The agent protocols gaining adoption at the time — MCP and A2A — deliberately left it out of scope. The project's own strategic evaluation, commissioned in June 2026, examined this taxonomy skeptically and concluded the gap was real: “a genuinely missing layer at the spec level,” while warning in the same breath that it was “a premature abstraction at the operate-production-infrastructure level.”^[1]

Precision matters here, because this is the kind of claim that swells in the retelling. The project identified and characterized a class of gap, and it built a reference implementation to explore one possible response. It did not deploy into an external environment where the gap was causing harm and then close that gap. No external organization ran the software. The project never established that its architecture was necessary, sufficient, or superior to the alternatives that emerged alongside it. The thesis was a hypothesis about where agent infrastructure was heading; the implementation was an instrument for making the hypothesis concrete and testable, not a proof of it.

The publicly visible record begins in May 2026. The repository's initial commit, on 2026-05-18, already carried the v1.0.0 release — the specification drafting, implementation, and several audit cycles recorded in the project ledger predate the public repository. The repository was made public on 2026-05-19.^[2]

The project's specification stack ultimately comprised eight documents — a Namespace Standard, per-component specifications, a standards overview, and three governance documents (a Governance Framework, an operations charter for the trust authority, and a continuity protocol).^[3] Three services implemented the technical core, each a small Node.js program:

The Registry was the authoritative store. A capability was registered as a capability record: a named (research.market.intel.vendors), semantically versioned, behaviorally described unit — input and output schemas, permissions, protocol, endpoint — signed over ten of its fields with an Ed25519 key held by the project's trust authority, the DNSO (Dillweed Namespace Stewardship Office). The corresponding public key was published at a fixed URL with a documented SHA-256, so any relying party could verify record signatures locally without trusting the registry that served them. The registry exposed lookup and verification endpoints, an append-only audit log as a protocol obligation rather than an operational afterthought, and — the semantics the project's own reviewers judged most presently valuable — capability-level revocation: any individual record could be revoked with a mandatory, permanently logged reason, independent of every other record.^[4]

The DillClaw Resolver was the consumer side. It fetched the registry's catalog on a jittered refresh cycle, cached it under TTLs with a bounded stale-while-revalidate window, verified signatures against the published key, and answered queries — including wildcard and constraint queries (“any capability matching this category path, at this minimum trust tier, with these permissions”) — through a documented pipeline: parse, look up, gate by tier, check permissions, check signature validity, rank. Every resolution, including error paths, persisted a resolution trace: a reconstructable record of which candidates were considered, what was checked, and why the selected one won. Revocation propagated to resolvers within one refresh interval, a bound the integration suite exercised end to end.

Anthill was the observability service: an ingestion point for operational signals about the namespace itself — trust-tier drift, revocation cascades, deceptive path registrations, resolver abuse — with nonce and sequence-number replay protection. It is also where the project's most serious defect lived, which section 7 treats on its own.

A thin MCP adapter exposed resolve/lookup/verify operations as tools an MCP-speaking agent could call.

All of this ran as Profile A — the project's term for a single-host, local reference deployment — on one macOS machine, dill-p-001, under launchd. That deployment exercised the full lifecycle: register a capability, resolve it through DillClaw with signature verification, revoke it, observe the revocation propagate. A 19-check integration test walked that entire chain, and at the preservation endpoint the suites were executed independently for the record: registry 79/79, resolver unit 29/29, Anthill 58/58, integration 19/19, and a resolver conformance suite at 63 passed / 2 failed, with both residual failures investigated and classified as test-fixture artifacts rather than defects.^[5]

It is important not to blur what the record keeps separate. Specified and implemented and locally exercised: the registry, resolver, and Anthill services; signing and local verification; capability-level revocation with bounded propagation; resolution traces; the MCP adapter. Specified but never realized: mirror deployments (the specification named a mirror mode, but a deployment-focused gap analysis concluded a would-be mirror operator had “no happy path at all” — no synchronization protocol existed in spec or code); multi-organization operation; registrant identity (v1 write access was a single shared admin token); verification of Anthill's per-node signatures.^[6] Proposed but not built: the entire v2 design — authenticated identity, delegation, transparency logging, offline verification. Documented but not independently verified: essentially everything, in the sense that matters most — the review corpus was AI-assisted and steward-commissioned, not independent third-party assessment, a distinction the next section takes up directly. And two governance-layer facts deserve plain statement: the four deployment profiles beyond the local stack were never supported, and the trust tiers that fed the resolver's scoring were, in v1, self-declared by registrants and scored at face value — a limitation the project's charter itself conceded.^[7]

The most distinctive thing about the project may not be the protocol design at all. It is what the project did to its own work.

Between May and July 2026 the project subjected itself to a layered review program, all of it AI-assisted, all of it commissioned and curated by me as steward, and all of it preserved in the repository. The project ledger records the provenance rule explicitly (item AI-008): these were generalist AI review rounds conducted under the steward's direction — not independent third-party assessment, not peer review — and the preservation record repeats that qualification wherever the reviews are cited.^[8] Within that provenance, the discipline was real, and it had structure:

• Multi-round consistency review. Six rounds over the specification stack and implementations in June 2026, run until convergence — meaning the later rounds existed to verify the fixes from earlier ones. They found things worth finding: a formula for trust scoring that two implementations computed differently, phantom mechanisms asserted in one document and existing nowhere, layer-numbering contradictions across four documents. Notably, three of the five fix cycles introduced at least one new defect or overclaimed a fix — each caught only by the post-fix verification pass. “Verify after fix” became standing practice because the record showed what happened without it.^[9]
• Per-component architecture reviews of the registry, resolver, and Anthill, which produced the P0/P1 findings that anchored the later disposition work.
• Cross-service trust-boundary analysis, which asked, for every boundary between services, what the consumer assumes about the producer's data and whether anything enforces the assumption. This stage produced findings no component review had surfaced — a sequence-counter poisoning attack, a revocation-freeze window exploitable by an on-path adversary — and it assigned the project's only CRITICAL severity (section 7).
• Adversarial second-implementer analysis: could an independent team build a conforming implementation from the specifications alone? The answer was no — 88 gaps, nine of them blockers, from unpinned response serialization to an undefined wire protocol for Anthill.^[10] Deployment-oriented variants of the same exercise produced the mirror-operator verdict quoted above.
• Finding disposition and temporal maintenance. In June 2026 the roughly 230 raw findings scattered across fourteen documents were normalized into 70 canonical findings in a single disposition index, each with a controlled status (OPEN, CLOSED, PARTIALLY CLOSED, DEFERRED, and so on), a last-verified baseline commit, and evidence citations into the code. The index also maintained a stale-document register — which historical reviews now contained outdated claims, and where the current truth lived — and a table of sixteen known contradictions between documents and code. At the c999fdd baseline the tally was: 5 closed, 6 partially closed, 30 open, 22 deferred to v2, 4 accepted for v1, and a handful of superseded, not-a-defect, and unverified entries.^[11]

Why did this matter? Because early trust infrastructure has a specific failure mode: documents and code drift apart silently, fixes render old reviews stale, and a reader has no way to know which claims still hold. The disposition discipline was the project's answer, and the record shows it catching the project's own errors repeatedly — including a reviewer false-positive (a HIGH-severity claim about an uncovered private key that git check-ignore disproved) that was kept on the record deliberately, as evidence that reviewer claims got verified too.

In July 2026 these practices were extracted into a working methodology paper — an evidence-layered, temporally maintained review method for agentic trust infrastructure.^[12] The paper's own disclosure statement carries the caveat that must be repeated here: the methodology is derived retrospectively from a single case study, its own. It has not been independently validated across multiple projects. Its broader applicability is a reasonable hypothesis and a proposed contribution, not a demonstrated general result.

In April 2026, an Internet-Draft for version 2 of the Agent Name Service (ANS) was submitted to the IETF as an individual submission by authors from GoDaddy, OWASP, Cisco, and others. On 2026-06-23, the Linux Foundation announced its intent to launch ANS as a hosted project, with supporting quotes from GoDaddy, Cloudflare, Infoblox, Salesforce, Cisco, and OWASP, among others.^[13]

The announcement could have prompted a defensive reaction. Instead it prompted a structured comparison: a boundary analysis, completed 2026-07-01, that read the ANS draft and its reference implementation against the Dillweed corpus, concern by concern, across roughly forty rows of a responsibility matrix.^[14]

What ANS covered, per that analysis: versioned agent identity anchored to DNS domains, validated by ACME domain control; dual X.509 certificates; a Merkle-tree transparency log with offline-verifiable receipts; layered trust-root distribution; monitoring designed around a report-don't-act, quorum-gated governance posture. Where Dillweed overlapped with that, the comparison was blunt. Dillweed's own v2 design — drafted before the comparison — had independently converged on the same patterns: transparency logs, signed checkpoints, offline roots, domain-proof registration. The analysis put the consequence directly: where Dillweed planned, ANS shipped, with stronger cryptography, three SDKs, multi-vendor authorship, and institutional sponsorship. Its verdict, of the five permitted, was “complementary profile”: ANS subsumed most of Dillweed's identity, trust-root, transparency, and mirror ambitions, and several Dillweed components — the bespoke trust-root distribution, the unbuilt mirror protocol, the hand-rolled append-only logs, the unverified trust-tier mechanism — duplicated what ANS or older infrastructure did better and should be retired.

The analysis kept its evidentiary standing honest in both directions. ANS was an individual draft, not an adopted standard; the Linux Foundation announcement was an intent, not a completed governance structure; no public production ANS deployment was identified. The comparison was between two early projects — but one with institutional momentum a solo project could not match and had no reason to duplicate.

What remained distinguishable on Dillweed's side was narrow and specific. ANS's unit of registration and lifecycle is the agent version; the unit of invocation in agent systems is the capability. In ANS, capabilities are metadata inside an agent's Trust Card — no independent identity, no independent version, no independent revocation. The comparison worked this through ten concrete scenarios, and the clearest was the simplest: if one of an agent's ten capabilities is compromised, ANS can revoke the whole agent version or replace it with a new one — either way, the log never records which capability was the problem — whereas capability-granular revocation with a logged reason was Dillweed's native operation.^[15] Alongside that granularity, the analysis found one Dillweed artifact with no ANS analog even in design: the resolution trace, a reconstructable record of why a particular candidate was selected under a particular policy. Those — capability-granular lifecycle and revocation, resolution-time evidence, reconstructable decision traces — plus the review methodology itself, were judged the durable remainder.

But the same analysis was explicit about what that remainder did not justify: nothing in the capability-standing question requires a bespoke trust root, a parallel namespace, a bespoke transparency mechanism, or a competing registry. The concept survives; the packaging does not. The evidence no longer supported continuing a separate general-purpose infrastructure stack merely to preserve the project's original scope.

None of this was a contest that Dillweed lost, and it would misread the record to cast ANS as an antagonist. The two projects were built independently, converged on the same prior art — Certificate Transparency, ACME, SCITT, TUF — and the comparison's closing recommendation was interoperability: the capability-standing ideas expressed as a profile consuming ANS identity, not a stack beside it. What changed was the evidentiary basis for one person continuing to build the infrastructure layer alone.

The strategic evaluation of 2026-06-12 had already framed the choice before ANS entered the picture. Its verdict — “technically credible but early” — came with a mandatory narrowing requirement: the stack was roughly three times broader than its defensible core, external validation was zero, and continuation was made conditional on external facts materializing (an independent operator, specialist review, signs of pull).^[16] Those facts did not materialize. The ANS boundary analysis then removed the remaining rationale for the widest version of the project: building v2's authenticated identity, distribution, and transparency infrastructure would have reproduced, single-handedly, work being addressed by an institutionally supported project with stronger cryptography and broader participation.

So the project stopped building. Not by abandonment — by a written plan.^[17] The Preservation and Transition Plan, prepared 2026-07-02 and executed on 2026-07-21, recorded the controlling decision as settled: Dillweed v1 is the final implementation state of the original parallel namespace architecture. There will be no W1 implementation phase and no continued development of that architecture. The plan then defined what “stopping well” meant:

• Complete v1 as a study artifact. The final behavioral commit was identified precisely (8c87a85, 2026-06-10 — the last change to executable runtime behavior), with the later documentation-only commits individually classified.
• Verify the endpoint rather than assert it. On 2026-07-21 the five test suites were executed against the running deployment — the first independent execution for the record, superseding previously reported counts — the three release tarballs were extracted and audited against their published SHA-256 values, and the live site and trust root were reconciled against the repository. The tarball audit turned a previously noted size anomaly into a verified finding: the Anthill package had been built from a post-install working tree rather than a clean source export. That defect was left open, verified and disclosed, rather than quietly repackaged — the preservation endpoint freezes with disclosed open findings, and says so.^[18]
• Preserve the review record. The finding-disposition index was reconciled to the endpoint; fifteen steward reports whose absence had itself been a tracked finding were located, checked, and committed, resolving it.
• Seal a reproducible baseline. A single preservation commit (58e51e6) carrying the preservation record, manifest, and reconciled documentation, under the annotated tag dillweed-v1-preservation-baseline, with a machine-readable manifest recording versions, hashes, runtime, and unresolved findings.
• Decommission the reference deployment. On 2026-07-21 all three services on dill-p-001 were stopped and verified down. The host operator subsequently and independently chose to restart the preserved software locally; the record notes this as independent host-operator activity, outside project scope. The project asserts no operational deployment from that date. Nothing described in this essay is currently operated by the project.^[19]
• Do not proceed to v2. The v2 design and its tracker were dispositioned as superseded future architecture, closed by banner rather than deletion.

One aspect of this deserves emphasis, because it is the closest thing the project has to a thesis about itself: stopping was an output of the review discipline. The same apparatus built to test the architecture — structured comparison, evidence classification, disposition tracking — was eventually pointed at the justification for continuing the architecture, and the project accepted the result. The preservation plan states the chain plainly: the strategic evaluation set conditions; the conditions were not met; the boundary analysis found the infrastructure ambition subsumed; the evidence did not support continuing; therefore v1 is final.

What worked

The review discipline worked, in the specific sense that the record shows it catching real defects at every layer it was designed for: cross-implementation divergence in a scoring formula, false safety claims in published specs, an unimplementable mirror mode, fix cycles that introduced new defects, and reviewer claims that were themselves wrong. The disposition index worked as designed: at the end, a reader can trace all 70 canonical findings to code, commits, and dated status changes.

The capability-standing framing held up under hostile examination. Both the strategic evaluation and the ANS comparison — documents that recommended shrinking or stopping the project — independently affirmed that the compound standing question was real and unanswered at capability granularity by anything surveyed.

The willingness to revise and retract held up, and in one case turned inward in a way worth recording. The methodology paper's original headline example credited the cross-service analysis stage with the project's CRITICAL finding. While preparing the paper's own evidence tables, that claim was found to be overstated — the defect had been disclosed earlier by the component review and the specification itself; the cross-service stage assigned its severity rather than discovering it — and the paper corrected its own account rather than quietly dropping the example.^[20] Small, but it is the discipline demonstrating on its author what it was built to catch in the project.

The preservation process worked: a verified, tagged, reproducible endpoint with tests executed rather than reported, artifacts audited rather than trusted, and open defects disclosed rather than laundered. And the record itself is the product: a complete, inspectable account — specifications, implementations, roughly 230 raw findings, their normalization and disposition, the comparison that ended the project, and the plan that closed it.

What did not work

A solo-built comprehensive infrastructure stack entered a field increasingly occupied by institutionally supported projects, and the comprehensiveness was the mistake. The strategic evaluation's arithmetic — scope roughly three times wider than the defensible core — was written by the project's own commissioned reviewer and was correct. The governance corpus institutionalized councils and succession mechanisms for a project with no documented external participant community.

No external adoption is documented in the sealed project record. At the last measurement recorded before preservation: no third-party implementation, no externally registered capability, no external issues, and a resolver trace corpus consisting entirely of one day of local test traffic. I am not aware of any external production deployment.

Distribution never became real. Mirrors were specified but unbuildable; multi-organization operation was a design document; the public read-only resolver deployment was gated on hardening requirements (TLS, a threat model) that were never completed. The single-key, single-steward construction contradicted the project's own neutrality thesis — every record signed by one key held by one person — and the cure, delegation under multi-party adoption, required exactly the adoption that never came. The strategic evaluation called this a circular dependency that might never break. It never broke.

The most serious internal finding remained open at the end (next section). And the broader architecture did not establish a sufficient case for continued independent development. That is not a euphemism for bad luck or bad timing. The project's own comparison concluded that most of what remained to build was being built elsewhere, better; continuing would have been duplication its own reviews warned against.

The project closed with its most serious finding unresolved, and no honest account can leave it out.

FDI-ANT-001: Anthill, the observability service, defined a per-node signature field (node_signature) intended to authenticate the operational signals nodes submitted about the namespace. The implementation accepted the field, stored it — and never verified it. It did not even require it. The submitting node's identity (originating_node) was a free-form string. The consequence: any party able to submit signals to Anthill could forge them. Such a party could fabricate signals attributed to any node; a companion finding showed an attacker could poison a victim node's sequence counter to suppress its legitimate signals; a third showed the replay-protection mechanism itself could be turned into a framing device.^[21]

The finding's history carries a methodological subtlety the project's own paper was careful to preserve, and it should be preserved here too. The defect was not hidden and not first discovered by the project's most dramatic review. It was disclosed from early on: the project ledger tracked it from 2026-05-15, the Anthill component architecture review raised it at P0 severity, and the Anthill specification itself disclosed it in an appendix as the largest single deferred work item. What the cross-service trust-boundary analysis contributed — and it was the analysis's decisive contribution — was the severity: by constructing the concrete fabrication, suppression, and framing attack chains across service boundaries, it escalated a known, disclosed, deferred item to CRITICAL. The lesson the methodology paper draws is about severity assignment, not detection: a defect can be openly catalogued while no review stage has yet recognized how bad it actually is.

The remediation — per-node key enrollment and mandatory signature verification — was assigned to the v2 identity wave. V2 was never built, so the finding was never remediated. At preservation it stands open, CRITICAL, disclosed in the preservation record, the manifest, the finding index, and the repository README. Its practical blast radius at the endpoint is bounded by the deployment reality — a decommissioned, local-only reference stack whose signals nothing consumed for governance — and the preservation record marks every profile that would make the finding dangerous (public exposure, multi-organization use, any evidentiary reliance on Anthill data) as explicitly unsupported. But bounded is not fixed. Preservation recorded the defect; it did not resolve it.

What is left, and what it may be worth, stated at the confidence the record supports:

The review methodology, extracted as a working paper, is the contribution most likely to travel. Its practices — evidence-layered claims, cross-service boundary analysis, second-implementer review, controlled finding disposition with temporal maintenance, provenance discipline for AI-assisted review — may be useful to other early trust-infrastructure projects facing the same conditions: no production telemetry, no adversarial users, heavy reliance on AI-assisted review. That is a hypothesis. The method has been applied to one project — its own — and has not been independently validated.

The reference implementation and review corpus are available as a study artifact: a complete, locally reproducible three-service stack with pinned baselines, executed test results, and a finding record that traces every defect from discovery through disposition. The preservation record documents exactly what a future reader may and may not conclude from it.

The capability-standing thesis survives as a dated, publicly preserved technical record. The distinction it drew — agent identity versus capability standing; the agent version as ANS's unit of lifecycle versus the capability as the unit of invocation — is worked out concretely in the boundary analysis, with scenarios and a responsibility matrix. If later work, including possible ANS extensions, takes up capability-granular lifecycle, capability-specific revocation, or resolution-time evidence, this record is a documented antecedent that may help establish the history of those concepts. Whether it will inform such work is not something the record can say; no influence on later work is documented in it.

The experience itself is documented with unusual completeness: a solo builder specifying and implementing an infrastructure layer, encountering institutional consolidation of the same territory, and running a structured comparison instead of a competition. The record of how the project decided to stop — evaluation, conditions, disconfirmation, preservation — may be the most reusable part of the story for other independent builders, who face this situation more often than the literature about it would suggest.

And there is the close itself. The project ended with its claims reconciled to its evidence, its defects disclosed, its deployment decommissioned, and its endpoint reproducible. An honest close is not a consolation prize for an unproven thesis; it is simply worth more than continued overextension would have been — to the record, and to anyone who later wants to build on the parts that hold.

The Dillweed Namespace Project was a 2026 attempt to specify and implement capability standing — verifiable, current, revocable status for the individual capabilities agents invoke. It produced eight specifications, a three-service reference implementation exercised end to end on a single local deployment, and a review corpus of roughly 230 raw findings normalized into a maintained disposition index. It ended because its own evidence process concluded it should: the conditions its strategic evaluation set for continuing were not met, and a structured comparison found its broader infrastructure ambitions subsumed by an institutionally supported effort, leaving a residue — capability-granular lifecycle, resolution-time evidence, and a review methodology — too narrow to justify an independent parallel stack.

What is preserved is a sealed, reproducible baseline: tag dillweed-v1-preservation-baseline, verified tests, audited artifacts, and a complete finding record including an open CRITICAL defect, disclosed rather than resolved. What remains potentially useful is the methodology, the study artifact, and a dated record of the capability-standing idea. What remains unproven is everything the project did not get to test: that the architecture was the right response to the gap, that the methodology generalizes beyond its single case, and that capability standing will matter at the scale the thesis assumed. The record is public so that, if any of those questions become live again, the work does not have to be re-derived — only re-examined.

This retrospective, like much of the project's analytical corpus, was AI-assisted and steward-authored.