# Tag Badge Semantics Contract — Tag Badge Catalog (v1)

This feature does not introduce HTTP APIs. These contracts define stable UI semantics for tag-like (metadata) badges across the admin panel.

## Scope (v1)

### In scope (tag-like / metadata)
- Policy type and policy category.
- Platform.
- Tenant environment.
- Visibility/lifecycle tags when used as metadata chips (not health/status).
- Snapshot type.

### Out of scope (status-like)
- Status/health/progress signals (queued/running/completed; succeeded/failed/partial; enabled/disabled; availability; severity/risk).
- Any status-like boolean that is intentionally “attention-worthy”.

## Neutral palette policy (v1)

### Allowed colors
- `gray`
- `primary`
- `info`

### Forbidden colors for tag-like badges
- `success`
- `warning`
- `danger`

## Domain → color mapping (v1)

Tag colors are assigned per domain (domain → color), not per individual tag value:

- Policy type → `gray`
- Policy category → `primary`
- Platform → `info`
- Tenant environment → `primary`
- Visibility/lifecycle → `gray`
- Snapshot type → `gray`

## Canonical labels (v1)

### Platform casing
Platform labels must be Title Case:
- “Windows”, “Android”, “iOS”, “macOS”, “All”

### Unknown / unmapped values
Unknown/unmapped values must render as:
- Label: “Other: <value>” (normalized)
- Color: neutral (from allowlist)

## Invariants (v1)

- Tag-like badges must not masquerade as health/status (no `success|warning|danger` colors).
- Unknown values must render safely and transparently (“Other: …”), never as an “official” curated tag.
- Tag badge mapping must be pure and must not trigger outbound HTTP, queued work, or DB lookups beyond already-loaded data.
