How it works in AgenID
Required members include assertion_id, subject, subject_type, level, a typed claim, authority, an evidence pointer, verified_at, expires_at, scope, manifest_digest and key_id. Claim types map to levels: registration, domain_control, organization_identity and deployment_conformance. It is signed with pure Ed25519 over RFC 8785 bytes by an authority key.
subject_type is agent for the first three levels and deployment for L4, where the subject is a platform-scoped deployment identifier rather than the agent's own.
Why it matters
Every field a relying party needs is mandatory, so a claim without evidence, authority, scope or time cannot be a valid assertion. The digest binding means an edited manifest makes an old assertion assertion_not_applicable_to_current_manifest rather than silently reused. Evidence is a pointer, such as a DNS name, never the evidence itself, so the registry does not become a store of private documents. Scope is explicit as well: an authority publishes the scope identifiers it uses, and a verifier reads an assertion as covering that scope and nothing more.
What it does not mean
An assertion shows that an authority asserted a claim, not that the claim is true, and it implies nothing outside its scope: domain control is not organizational identity. It says nothing about what the agent is allowed to do. The endpoint that would store assertions is not deployed.