In plain words: can a machine, not a human reading marketing copy, find, verify, and use what Sylvera has already built and opened up? Credit-first, because two of these five findings are genuinely strong: an open standard with our exact field already in it, and a validation we ran ourselves and can show you the output of.
No jargon: here is what each gap below is worth to Sylvera in plain terms.
The developer front door renders empty to anything that doesn't execute JavaScript, so an integrator (or its assistant) checking whether to build on Sylvera's Assessment API gets nothing usable and can quietly move on.
Nothing currently tells a generic AI what Sylvera's ratings or CDOP work even is, so Sylvera can be absent at the exact moment a buyer's tool is looking for exactly what it offers.
retirement_beneficiaryCDOP's own Unit_Description.schema.json, public, MIT-licensed, in a repo pushed as recently as 2026-07-13, defines a field, id 141, named retirement_beneficiary, described verbatim as "Entity name on behalf of which the retirement occurred." That is EcoWealth's own standing law, the retire beneficiary is never the sender, expressed almost word-for-word by a standard Sylvera helped write. A sibling field, retirement_detail (id 142), holds free-text context, exactly the shape of a settlement narrative. Neither field carries an enum constraint; both accept a plain string, which is all a settled EWP retirement receipt needs to supply.
Sources: github.com/Carbon-Data-Open-Protocol/Carbon-Data-Open-Protocol/json_schema/Unit_Description.schema.json · repo license (MIT) and last-push date confirmed via api.github.com/repos/Carbon-Data-Open-Protocol/Carbon-Data-Open-Protocol
CDOP's repo documents validation via pip install check-jsonschema or its own scripts/validate.py (7,588 bytes, present in the repo today). We built a JSON record carrying the substance of EcoWealth's real, settled EWP work packet: beneficiary, serial-equivalent identifier, quantity, retirement status, shaped to CDOP's Unit_Description schema, and validated it locally with their own tool, not a copy. Told the truth on the first try: it caught a real formatting mistake in our own draft (a bare year where the schema requires a full ISO date), we fixed it, re-ran, and it passed clean. That's what a genuine schema-conformance claim should look like: independently checkable, including the mistake.
Sources: github.com/…/scripts/validate.py (existence confirmed via GitHub contents API) · full record + commands in evidence.json and the demo page
On www.sylvera.com, every standard agent-discovery path, llms.txt (the file AI assistants read first), ai.txt, .well-known/agent-card.json, .well-known/ai-plugin.json, .well-known/security.txt, .well-known/x402, returns HTTP 404. That's a real gap: nothing tells a generic agent what Sylvera's Assessment API or CDOP participation even is. But it deserves a more precise read than "broken": llms.txt/ai.txt and a nonsense-path control all return the SAME ~22 KB branded Webflow 404 page (true 404, not faked), while every .well-known/* path returns an even more honest, distinct 88-byte body, {"Invalid .well-known request"}-shaped text, rather than pretending to be content. Klima Protocol and Oimpact, two other targets we've reviewed, found soft-200/soft-400 catch-alls that lie about existence; Sylvera's platform (Webflow) does not do that here. robots.txt is real, clean, and points to a real sitemap.
Sources: www.sylvera.com/.well-known/agent-card.json · www.sylvera.com/llms.txt · www.sylvera.com/robots.txt · nonsense-path control
docs.sylvera.com is a client-only shellSylvera's product copy describes an "Assessment API" for programmatic ratings retrieval, hosted at a real, separately-deployed documentation site (docs.sylvera.com, title "Sylvera API Documentation"). A plain GET returns a Vite-built single-page app shell, a nearly-empty <div id="root"> and two bundled asset files, with zero endpoint, schema, or auth-scheme text in the raw response. No public OpenAPI spec, Postman collection, or machine-readable schema for this API was found anywhere without an account. An agent (or a human skimming curl output) gets nothing usable from the one URL that's supposed to be the developer front door.
Sources: docs.sylvera.com/ (root HTML)
Sylvera's /pricing page names three tiers, Freemium, Essentials, Enterprise, but the rendered page text contains no numeric price anywhere above the free tier: every call-to-action above Freemium reads "Request a demo" or "Get a quote." That's a gentle contrast, not a criticism: EcoWealth's own x402 endpoints publish an exact USD-per-call price with no signup, which is simply a different model suited to a different kind of product. Worth crediting in the same breath: Sylvera explicitly ring-fences its Ratings analysts from its commercial Methodology Toolkit / Assessment Services teams, "ratings are produced independently of commercial outcomes", a structural answer to the industry's standing "Rating the Raters" critique that's a genuinely thoughtful trust design, independent of pricing.
Sources: www.sylvera.com/pricing · independence framing from www.sylvera.com/governance and /research (recon session, 2026-07-16)
Nothing here is a security problem or a broken product. Sylvera is genuinely strong on the thing that matters most for this brief: an open, well-governed, actively-maintained data standard with a field-for-field match to how EcoWealth already thinks about retirement, and it's honest where it has gaps (real 404s, not fake ones). The concrete, low-effort next step lives entirely on EcoWealth's side: file the mapping doc as a real pull request against CDOP's own open repo. No Sylvera action, account, or contact required.
→ See the EWP receipt fitted into CDOP's schema, validated live
