docs: add "Implementations in the wild" section (refs #26, #66) - #71
docs: add "Implementations in the wild" section (refs #26, #66)#71YE-YI7 wants to merge 1 commit into
Conversation
…ards-project#66) Creates the section proposed in ards-project#26 and lists the ASM tool-selection catalog, following the invitation in ards-project#66. Verified with this repo's conformance CLI v0.5.0 against the live endpoint before opening: PASS, 0 critical errors, 30 warnings — all of them the media-type finding that ards-project#66 asks about. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Another candidate for the section when it lands: the Desvela ARD Registry, Verified with this repo's CLI immediately before writing: The registry run failed when I did it this morning, so the honest version of that claim is that it passes as of today: the spec allows an entry to carry its payload inline in I have deliberately not opened a competing PR, since this one creates the section. Happy for it to land as is and to add a row afterwards, or for @YE-YI7 or a maintainer to fold it into this PR, whichever is less work for you. One thing for whoever ends up maintaining the list: Disclosure: I run Desvela. |
|
Thanks @mrenzo20 — Desvela and the independent WellKnownHQ crawler are exactly the kind of evidence that makes an implementations section useful rather than vendor-specific. I have not changed this PR's branch without maintainer direction, but either row can be folded in here or added immediately after merge. One factual update on the ASM row now that its reproduction path exists:
conformance/bin/conformance-test manifest https://asm-spec.onrender.com/.well-known/ai-catalog.jsonNo normative field or allowlist change is requested by this PR. This is my one follow-up; I will leave the listing and candidate rows with maintainers from here. |
|
Thanks — I independently reran the repo's v0.5.0 conformance CLI against Neuronto just now. The manifest and registry payloads do pass with 0 errors and 0 warnings once the request carries a non-default User-Agent. One reproducibility note: the default commands return HTTP 403 from my machine because the live service rejects Python urllib's default User-Agent: Piping a curl fetch (which uses a different default User-Agent) into the manifest validator, or adding a curl User-Agent header to the registry command, both produce PASS with 0 errors and 0 warnings. Because the v0.5.0 manifest command has no header option, the 403 appears to be a WAF/User-Agent filter rather than a schema issue. Would it be possible to either allow the CLI's default client through the filter, or document a stable request-header requirement? That would make the conformance claim fully reproducible with the published commands. I'll leave the PR branch unchanged pending maintainer direction. |
|
Two things, one on the table format and one for maintainers. On format: there are three PASS claims in play now and they are not the same claim. ASM passes with 30 media-type warnings, which @YE-YI7 put in the row rather than leaving implicit. Desvela passes 0/0, though the registry run failed the morning I posted it and I fixed it before writing. And #87 passes 0/0, but the published commands returned 403 from YE-YI7's machine because of a User-Agent filter. On that last one, for whatever it is worth: from my machine Which is really the point. A column that just says PASS renders those three identically, and that is the least useful version of this section. YE-YI7 already did the right thing unprompted, noting the warnings inline so the row does not read as a clean bill of health. I think that should be the rule rather than a courtesy: every row carries the exact command, the date it was run, and anything that stops it reproducing. A row that cannot say how to reproduce it is a logo, not evidence. Probably worth recording who ran it, too. Self-reported and independently reproduced are different things and readers can weigh them themselves. For maintainers, the more useful question: this has been open a month and there are at least three implementations waiting to add rows to a section that has not landed. Before anyone spends more time on wording, is the section wanted? If it is, landing it with just the ASM row would unblock everyone and the rest can go in one at a time. If it is not, better to say so and close #26 with it. Same disclosure as before, I run Desvela, so I have a row to gain from this existing at all. |
|
Neuronto author here. Answering the reproducibility question directly, because between your two theories the geo-dependent one is much the worse and it is not the right one. It was Cloudflare's Browser Integrity Check. It returns error 1010 and bans a small legacy user-agent list that includes Worth adding why it was invisible: of 16 clients I tested afterwards, only Current state, published commands, no workaround, run 2026-09-01: On the format proposal: agree, and I would rather be held to it than not. Exact command, date, and who ran it are the three columns that make the difference between evidence and a logo, and a warnings count belongs inline exactly as @YE-YI7 did it, since 0/0 and 0/30 are not the same claim. I would add that "independently reproduced" is worth distinguishing from "self-reported": this thread is a fair example, since the 403 was found by one person and the fix confirmed by another, and neither was me. Same disclosure as you both: I run Neuronto, so I have a row to gain from the section existing. |
|
Confirmed independently after the change. I reran the exact public v0.5.0 commands on 2026-09-01 with no custom headers: That resolves the reproducibility issue I observed. Thanks for tracing and removing the Browser Integrity Check, and for documenting the root cause. I also agree that self-reported and independently reproduced runs should remain distinct evidence states. I will keep the PR branch unchanged until maintainers decide the table format and candidate rows. |
3 participants
Creates the
Implementations in the wildsection proposed in #26, and adds the ASM tool-selection catalog to it — following @mindpower's invitation in #66.Per the README's contribution split this is a non-normative documentation change (no edits to
spec/ard.mdorspec/schemas/), so I'm opening it directly as a PR rather than an issue.Conformance
Verified against the live endpoint with this repo's CLI (v0.5.0) immediately before opening:
All 30 warnings are the same finding —
Media type 'application/asm+json' is not one of standard discovery types— which is exactly what #66 asks about. I've noted that inline in the table rather than leaving it implicit, so the row doesn't read as a clean bill of health while that question is still open. If you'd rather the section only list types already in the allowlist, I'm happy to drop the row until #66 is resolved.One more caveat, also in the table: the catalog is hosted on a free tier that sleeps when idle, so the first request after a quiet period can be slow or need a retry. Flagging it up front so a timeout doesn't get read as a dead endpoint.
On #26
#26 proposed this same section back in June for five conformance-tested deployments (SnowSure, SnowData, Afore, LUXSKI, Ski Limone), and the section itself doesn't appear to have landed — so this PR creates it.
I've deliberately not added those five, since their conformance status isn't mine to assert. @mikeslone — happy to include them in this PR if you'd like, or maintainers can land them separately. Placement, ordering, and wording are all yours to change; I have no attachment to the table format.
(Implementation and this PR drafted with Claude, at my direction and with my approval.)