Tag Schema

The tag schema is the vocabulary your policies reason about. Everything downstream — access decisions, encryption profiles, connector egress rules — references values defined here. Getting the schema right before volume grows is considerably easier than restructuring after.

Schema components

A tag schema has three kinds of entries:

• Classification tags with bounded values. For example, sensitivity with values public, internal, confidential, restricted. A policy can require a specific value or a minimum level.
• Domain tags with bounded values or free-form. For example, business-domain with values finance, engineering, legal, customer, hr.
• Metadata tags that are structured but not bounded. For example, source-system with values drawn from the set of registered connector sources.

Each entry in the schema specifies:

• The tag name (used by policies).
• The permitted values, or a validation rule for free-form values.
• Whether the tag is required, optional, or conditionally required.
• Whether changes to the tag trigger a review requirement.
• A human-readable description for authors who will apply it.

Recommended starting schema

A pragmatic starting schema that works for most organizations:

Start small. A schema with five tags that are enforced consistently is worth far more than a schema with fifteen tags that nobody applies uniformly.

Required-before-share gating

A powerful but simple control: require that an object have specific tags before it can be shared externally. A tenant might require that every object leaving the organization have at minimum a sensitivity tag and either a regulatory-scope tag or a regulatory-scope: none explicit declaration.

This is configured per tag combination in the schema. An unclassified object cannot leave the classification zone until it has been classified. The dashboard surfaces unclassified objects so they can be reviewed and tagged.

Review gating

Specific tag combinations can require a second reviewer before the classification is considered final:

• Downgrading a sensitivity tag (from restricted to confidential) is often reviewer-gated.
• Adding a regulatory-scope value like phi or itar typically requires reviewer confirmation, since it imports a regulatory regime.
• Changing origin is reviewer-gated — misattributing origin can obscure compliance obligations.

The reviewer pool for each gated change is configured in the dashboard.

Schema evolution

The schema will change over time. Two patterns are important:

Additive changes (adding a new tag, adding a new permitted value to an existing tag) are backward-compatible. Existing objects without the new tag simply don't carry it; existing policies continue to evaluate.

Restrictive changes (removing a permitted value, tightening required fields) are not backward-compatible. They need a migration plan — objects carrying retired values need to be re-tagged or their policies need to be updated to tolerate them. The dashboard surfaces the exposure before the change goes live.

Schema versions are retained in the ledger the same way policy versions are. An old ledger entry can always be interpreted against the schema version in force at the time.

Automated classification

The schema is also the input contract for automated classification. If you connect an automated classifier (Lattix-provided, partner, or your own), it produces tag values that are validated against the schema. A classifier that tries to apply a value not in the schema is rejected, logged, and flagged for review.

This is deliberate — it prevents an upstream misconfiguration from polluting the tag space with values policies have never heard of.

Relationship to concepts and products

• The schema underpins everything in Classification and Tagging.
• Every policy evaluates tag values in the schema.
• Connectors apply tags according to the schema when ingesting external data.
• Schema changes are recorded on the Immutable Ledger.