What was wrong
A trust surface has one job that matters more than the others: never show more than the evidence supports. An else branch that defaults to verified inverts that. Any bug upstream, such as a renamed field, a new level string, a network error that left the level empty, or a typo in an embed, would have surfaced to a reader as a green verified badge.
The defect lived in three places, the two badges and the card, each with its own copy of the mapping, which is how it survived review. Fixing one would have left two.
One canonical module
packages/web/lib/trust-presentation.ts now enumerates the level names the product knows how to present and resolves everything else to a neutral, non-verified state. Every surface that shows a real agent's state reads its level from the authoritative response and routes it through this module.
/badge.js used to be a static file with its own table. It is now a route generated from the canonical module, so no consumer carries its own mapping and a future change lands everywhere at once.
- DECLARED renders amber. It sits below L1, and the panel states that no third party has checked the claims.
- L1_REGISTERED renders amber. L1 is a self-declaration.
- Anything unrecognized renders neutral grey. Not verified is never red, because absence of verification is not a negative finding.
/badge/<agenid>/shield.svgalways returns 200 and reads NOT REGISTERED in grey for an unknown identifier, since a non-200 would render as a broken image.
Why emerald is reserved
The brand guide reserves Verified Emerald strictly for verified state: a specific claim that a third party checked against evidence. Nothing the reference deployment issues today meets that bar. The reference deployment at agenid.com issues nothing above L1_REGISTERED today: L2 and higher require a VerificationAssertion signed by a root authority key, and that key has not been created yet. L5 is reserved and is not issuable at all.
So in practice no real agent's badge renders emerald today, and that is the correct result.
What a badge does not say
A badge reports an identity state. Which agent is acting is not the same question as what it is allowed to do. AgenID answers the first. Protocol v1.1.1 defines no signed authorization object, so permission stays with the operator and with the party on the other side.
A badge is also a convenience, not the check. A relying party that needs certainty should resolve the envelope and re-verify signatures itself, which the registry cannot forge.
How to try it
Embed the badge with /badge.js or reference /badge/<agenid>/shield.svg from a README, as described on the badge page. Point it at an identifier that does not exist and you will get a neutral grey badge, not an error and not a verified state. The Verification Card entry explains what the card shows.