# Classes

> How Black Ice structures your product terminology as a connected ontology.

**Category:** Core Concepts | **Tab:** features

---

Classes are the foundation of your ontology. They define the *type* of thing each concept represents — giving structure, meaning, and governance rules to your terminology.

## What is a class?

A class is a category that groups related concepts. Think of classes as the taxonomy layer of your ontology:

- **Feature** — A specific capability or function in your product
- **Plan** — A pricing tier or subscription level
- **Platform** — A top-level product or ecosystem
- **Campaign** — A marketing initiative or promotional concept

Every concept belongs to exactly one class.

## Creating a class

Navigate to **Classes** in the sidebar and click **Add Class**.

| Field | Description |
|-------|-------------|
| **Name** | The class label (e.g., "Feature"). Used to generate concept ID prefixes. |
| **Description** | What this class represents. Helps team members understand when to use it. |
| **Color** | Visual identifier used throughout the UI and knowledge graph. |
| **Translation policy** | Sets the default localization rule: Prefer Adapt or Do Not Translate. Can be overridden per market. |

## Translation policies

Each class carries a translation policy that governs how its concepts should be handled during localization:

| Policy | Meaning |
|--------|---------|
| **Prefer Adapt** | Localize if a good equivalent exists; English fallback acceptable |
| **Do Not Translate** | Verbatim. No adaptation, no substitution |

The policy is applied at creation — a contributor adding a term to a class marked "Do Not Translate" gets the constraint before they type anything, not after a linguist catches it in QA.

## Market overrides

When reality is more nuanced, market-level overrides let you flip the policy for specific locales without changing the class default.

For example, a product name class might be "Do Not Translate" globally — but Japan and China need adapted forms. Instead of creating a separate class, you add market overrides:

```text
Class: "Plan"
Default: Do Not Translate
Override: ja-jp → Prefer Adapt
Override: zh-cn → Prefer Adapt
```

To manage overrides, open the **Overrides** dialog from the Classes table. Each row shows whether a market inherits the class default or has an explicit override. You can set or clear overrides per locale.

The design principle: **status describes intent, scope describes where.** Geography is never encoded in the policy name.

## Class-based concept IDs

When you create a concept, Black Ice auto-generates a unique ID based on the class name. For example, a concept in the "Feature" class might get the ID `feat_00000001`. This ensures IDs are:

- **Human-readable** — You can tell the class from the prefix
- **Unique** — Sequential numbering prevents collisions
- **Stable** — IDs never change, even if the concept name does

## Managing classes

You can edit a class's name, description, color, and translation policy at any time. Deleting a class requires removing all concepts in that class first.

> Classes are workspace-specific. Each workspace maintains its own set of classes independent of other workspaces.