Clawdbase
>
npx clawdbase verify <agent>CLI preview for public registry lookup. REST is the developer contract.
Documentation
Registry & ownership

Registry card anatomy

Read the information hierarchy used by Clawdbase result cards.

Registry cards are dense decision surfaces, not marketing cards. Each visible field must answer a scanning question without nesting additional bordered containers.

Primary identity

The name, Page type, source or repository and verified state identify the subject. Clicking the card opens its canonical Page.

Score pair

Trust and Confidence use two small donuts derived from the Page's stored score fields. The card and full Page must show the same values and the same missing/loading state.

Source facts

Provider, repository, creator and category provide context. A verified badge means provider-native control was established; it does not mean the artifact is universally safe.

States

  • Loading: placeholders preserve the card dimensions without showing sample facts.
  • Unscored: show an explicit pending or unavailable label; never insert sample data.
  • Error: preserve the last confirmed data where appropriate and offer a retry.
  • Empty: explain what filter produced no matches and provide one clear reset action.

Field reference

FieldMeaningInteraction
NameCurrent display name for the canonical subjectOpens the canonical Page
TypeAgent, Skill, Creator, X account or Telegram accountHelps compare like with like
SourceRegistered or discovered originIndicates provenance, not score quality
VerificationProvider-native ownership/control stateOpens registration context when applicable
TrustAuthoritative Trust value or unavailable stateUses the shared score color rules
ConfidenceEvidence coverage and quality valueNever merged with Trust
Creator or repositoryOrigin context for executable artifactsLinks to the related Page when available
UpdatedLast authoritative scoring timeSupports freshness policy

Interaction contract

The complete card is a predictable navigation target, while secondary actions remain explicit buttons with accessible names. Do not place unrelated menus, explanations or nested cards inside the result. Hover may strengthen the border, background and elevation slightly, but it must not move adjacent cards or hide score labels.

At keyboard focus, show a visible focus ring and preserve the same information hierarchy as hover. The card must remain usable without hover at 390 px. Long repository names wrap or truncate with an accessible full label; they do not widen the grid.

Score consistency

The two donuts show the same authoritative trust and confidence values used by the public Page. Values may be unavailable; they are never converted to zero. After Refresh Score, the Console and public Page must converge on the same score version and timestamp.

type RegistryScore = {
  trust: number | null
  confidence: number | null
  status: string | null
  scoredAt: string | null
}

Accessibility checklist

  • Expose Page type and verification in text, not color alone.
  • Give both donuts an accessible label and numeric value when present.
  • Keep button targets at least 40 px high on touch layouts.
  • Do not announce skeleton values as real content.
  • Preserve logical heading and tab order when cards reflow.