Structured model tags

Model and workspace frontmatter uses a map from your own keys to lists of strings. The suggested keys are team, source_data, topic and curated. They are suggestions, not an enum or an eligibility gate.

1
tags:
2
  team: [marketing/lifecycle, sales]
3
  source_data: [ga4]
4
  topic: [sessions, paid_media]
5
  curated: []

• Defaults. Leaving tags out means {}. An explicit empty map clears tags. An empty value list records that the key is present.
• Tags grant nothing. Model tags never infer ownership or certification. A field’s @tags stays an unkeyed list of strings.
• Case counts. Keys and values are case-sensitive.
• Matching. A selector map such as {"team": ["marketing"], "curated": []} matches any criterion: the exact value or slash descendants (marketing/lifecycle) under the same key, or the presence of curated even when its list is empty. Slash paths make a hierarchy within a key, and values under different keys stay distinct. A bare key wins over value limits for the same selector key.
• JSON. MCP and operation JSON use tags: {"team": ["marketing/lifecycle", "sales"]}.

# List models tagged for marketing, or marked curated
kater model list --select "tag:team=marketing tag:curated"
# Tag a new semantic model for two teams
kater new semantic-model --target-path PATH --name NAME --tags team=marketing/lifecycle --tags team=sales
# Clear the tag map while you create a model
kater new semantic-model --target-path PATH --name NAME --metadata '{"tags": {}}'

Workspace creation accepts an optional from_model: a unique model name, canonical address or typed identity. --from-model MODEL selects the first shared source. Without it, the workspace’s analytics are not set up until you run kater workspace source use MODEL --scope WORKSPACE.