Claims & terminology
This page exists because the words VIA ID uses to describe itself are a deliberate, load-bearing choice — not marketing color. If you're writing about VIA ID, integrating it, or presenting a badge to someone else, use this language.
Say this, not that
| Say | Never say |
|---|---|
| Tamper-evident — if the log is altered, verification shows it | Tamper-proof, tamper-safe |
| A badge is evidence | A badge is a guarantee or certification |
| VIA ID attests identity, signatures, and log integrity | VIA ID attests the agent is safe, correct, or compliant |
| A verdict reports what it actually checked | A verdict means "everything the agent did was fine" |
| Capability claims require actual evaluation (GraphSmith-backed) | A self-declared capability counts as "approved for X" |
What a VALID verdict actually means
It means: the agent_id really is the hash of the badge's own inception event, the owner /
agent / Witness signatures all check out, the key-rotation chain (if any) is internally
consistent, the log's hash chain is unbroken, and the badge hasn't expired or been revoked.
It does not mean the agent is safe, well-behaved, bug-free, or compliant with anything. If
a badge has evidence attached (a GraphSmith evaluation), the verdict's coverage field says
exactly what was evaluated and what passed — never "everything," always the specific scope.
"Not approved for" — shown, never softened
When a capability evaluation explicitly fails, that shows up as a downgraded_profile — shown
plainly, never hidden and never shown as a soft yellow "maybe." A capability with no evaluation
at all is not the same as a failed one, and the two are never conflated on a verify page.
Heuristics that are explicitly not security boundaries
Two places in the product do a lightweight plausibility check that is deliberately not a security control, and both say so in their own source comments:
- Download-gate's "is this a work email" check (
lib/email-gate.mjs) — a lead-quality filter, not identity verification. It doesn't confirm the email is real, owned by the submitter, or deliverable. Someone can trivially type a fake-looking corporate address and pass it. - Contact-form spam protection (honeypot + optional per-IP rate limit) — reduces obvious bot noise, doesn't stop a determined human spammer, and isn't meant to.
Neither of these should be described anywhere as verifying a person's identity or blocking abuse with certainty. If you need real assurance in either case, that's a different (and currently unbuilt) feature — see Enterprise.
Why this discipline exists
A tamper-evident log that gets oversold as "tamper-proof" or "certified" is worse than no badge at all — it invites exactly the kind of misplaced trust VIA ID exists to prevent. Every piece of copy, every API response, and every CLI message follows this table on purpose.