Classifications

Describe how sensitive your data is with classification schemes and levels, derived automatically and shown as badges across the platform.

Classifications let you define one or more schemes (for example a confidentiality scheme with the levels Public, Internal, Restricted, and Sensitive). Each scheme holds an ordered set of levels. You can start from a preset such as GDPR or TLP, or define a scheme yourself.

Classifications surface as badges in two places. On a data product, the effective level per scheme is derived from its output-port data contracts and its linked semantic concepts, and can be used to filter the data product list. On a data contract, one badge per scheme appears in the header, and each schema column carries its own level or inherits one from its linked semantic concept.

Schemes and Levels

Classifications are managed under Governance > Classifications. The page lists each scheme with its levels. A scheme whose custom property is classification is serialized to the standard classification field.

Starting from a preset

The Add Scheme dropdown offers a library of ready-made schemes alongside the option to build one from scratch. Each entry opens a preview showing the scheme's levels before you import it, and importing creates a normal, fully editable scheme — presets are a starting point, not a managed template.

Preset	Levels
Classification	Public, Internal, Restricted, Sensitive
GDPR	Non-personal, Personal data, Special category, Criminal offence
TLP 2.0	TLP:CLEAR, TLP:GREEN, TLP:AMBER, TLP:AMBER+STRICT, TLP:RED
US Government (CUI)	UNCLASSIFIED, CUI, CONFIDENTIAL, SECRET, TOP SECRET
NATO	NATO Unclassified, NATO Restricted, NATO Confidential, NATO Secret, Cosmic Top Secret

Classification is the same scheme every new organization is seeded with, offered here in case it was deleted. It is also the only preset that may claim the standard classification field: importing it into an organization that has no default scheme makes it the default. The other presets always serialize to their own custom property (classification.<id>), so they sit alongside the default rather than replacing it.

Importing a preset whose ID already exists fails rather than overwriting the existing scheme. Preset level names, descriptions, and criteria are English-only.

Classification Scheme

A scheme groups related levels and controls how they are serialized.

• Name: The display name of the scheme (e.g. "Confidentiality").
• ID: A canonical key auto-generated from the name (e.g. confidentiality). It is used in the serialized custom-property name (classification.<id>) and is immutable after creation.
• Description: Optional. Explains what the scheme classifies and how its levels are meant to be used.
• Custom Property: The property this scheme is serialized to. Use classification for the standard ODCS/ODPS classification field. Leave it blank to derive classification.<id>.
• Show on data product list: When enabled, this scheme's badge is shown on the data product list and a matching filter appears.

Classification Level

Each level is one value within a scheme.

• Name: The display name of the level (e.g. "Sensitive"). This is also the value written into data contracts and concepts.
• Level: A numeric sensitivity rank. A higher number is more sensitive and wins when a data product carries several levels.
• Description: What this level means.
• Criteria: Markdown describing the handling rules for data at this level.
• Color and Icon: Control how the badge looks.

How Classifications Are Derived

A data product does not store a classification directly. Instead, the effective classification per scheme is derived from:

• The output-port data contracts of the data product (these contribute via the standard classification field, so only to the scheme mapped to it).
• The data product's linked semantic concepts (these contribute to every scheme, via each scheme's custom property).

When several sources contribute different levels, the most sensitive level wins and is shown on the badge. A +N hint indicates how many other distinct levels are present.

You can override the derived value per data product in the data product editor. Each scheme offers an Auto option (the derived value) plus the explicit levels; choosing a level pins it regardless of the sources.

On the Data Product List

When a scheme has Show on data product list enabled, two things happen on the marketplace data product list:

• The data product shows the scheme's badge with its effective (most sensitive) level.

• A Classification filter appears (one per flagged scheme, after the Certification filter). The options are the scheme's levels plus "Not set".

The filter matches a data product if any level it carries is selected, not only the effective one shown on the badge. For example, a product whose badge shows Sensitive but that also carries Restricted will appear when you filter for Restricted.

On the Data Contract

A data contract carries classifications at two levels: once for the contract as a whole, and once per schema column.

Contract header

The header shows one badge per scheme, in scheme rank order. For each scheme the value is either:

• Authored on the contract — a root custom property naming a level. This is an absolute override; the tooltip reads (set on the contract).
• Derived from the schema — the most sensitive level found across the contract's columns, the same roll-up used for data products. The tooltip reads (derived from the schema).

If a scheme's authored value matches none of its levels, that scheme shows no badge rather than falling back to the derived value. This keeps a typo from silently reading as a valid classification.

Schema columns

Each column shows one badge per scheme. The effective value for a (column, scheme) pair is resolved as:

1. The level stated on the column itself, if there is one.
2. Otherwise, the level carried by the semantic concept the column links to through its authoritativeDefinition.

An explicit column value always wins over the concept's. Concepts contribute to every scheme — they carry the default scheme in their classification field and every other scheme in their custom fields — so a column and the contract header agree across all schemes.

The tooltip names where the value came from: inherited from <concept>, set on this column, or set on this column, overriding <level> from <concept>. A column that states the same level as its concept still reads as an override, because the column asserts it independently. An inherited value that matches no level in its scheme is skipped rather than shown as raw text, so a stale concept value cannot look authoritative.

Because a column can inherit, a column with no classification of its own is not necessarily unclassified — check its linked concept.

Serialization

The value stored everywhere is the level's display name (e.g. Sensitive).

Where a scheme is serialized depends on its Custom Property:

• A scheme whose custom property is classification serializes to the standard classification field in ODCS data contracts and ODPS data products.
• Any other scheme serializes to its custom property (by default classification.<id>), written as ODCS column customProperties and ODPS customProperties.

This keeps schemes mapped to the standard classification field compatible with the open standards while allowing additional schemes alongside them.

Permissions

Managing classification schemes and levels (creating, editing, deleting) is restricted to governance group members and organization owners. Anyone who can view a data product sees its classification badges, and anyone can open a level's read-only details page.

For more details on roles and permissions, see Roles & Permissions.