# V0 Governance Classifications

## Purpose

This document defines the starter classification hierarchy and default policy mapping for v0 governance.

Classifications are governance inputs. The runtime control plane resolves them into effective access, masking, retention, audit, and agent-permission policies.

## Classification Model

Classifications are inheritable through:

```text
domain -> data product -> asset -> field
```

More specific classifications may refine or strengthen inherited classifications.

Weakening inherited governance requires an approved classification exception.

## Starter Classifications

### `public`

Data approved for broad external or public use.

Default policy:

- Access: public or broadly available
- Masking: none unless another classification applies
- Audit: basic
- Agent behavior: discover, query, and explain allowed for approved public agents

### `internal`

Data intended for company-internal use.

Default policy:

- Access: authenticated internal users and approved internal agents
- Masking: none unless another classification applies
- Audit: basic query and export audit
- Agent behavior: discover, query, and explain allowed for approved internal agents

### `confidential`

Sensitive business data with limited audience.

Default policy:

- Access: restricted to explicitly allowed roles
- Masking: required for sensitive fields when exposed outside approved roles
- Audit: query, export, and policy decision audit
- Agent behavior: query/explain only for scoped agents; action permissions require explicit grant

### `restricted`

Highly sensitive data with strict access and operational controls.

Default policy:

- Access: deny by default, explicit allow only
- Masking: required by default for non-owner roles
- Audit: full query, export, policy, and agent-action audit
- Agent behavior: observe-only by default; query/action require explicit grant and may require approval

### `pii`

Personally identifiable information.

Default policy:

- Access: restricted to roles with approved purpose
- Masking: required for non-approved roles and agent contexts
- Retention: must declare retention policy
- Audit: full query, export, and agent-action audit
- Agent behavior: no row-level export by default; query/explain require scoped grant

### `financial`

Financial, revenue, billing, or accounting data.

Default policy:

- Access: restricted to finance-approved roles and scoped agents
- Masking: required where combined with PII or customer-sensitive data
- Retention: must declare retention policy
- Audit: full query, export, and contract-change audit
- Agent behavior: authoritative reporting only from healthy curated/service products

### `customer_data`

Customer-originated or customer-identifiable data.

Default policy:

- Access: restricted by customer, tenant, role, or approved purpose
- Masking: required where customer identifiers or sensitive fields are exposed
- Retention: must declare retention policy
- Audit: full query, export, and agent-action audit
- Agent behavior: cross-customer aggregation requires policy approval; row-level access requires scoped grant

### `operational_sensitive`

Operational data that could expose infrastructure, security posture, incident details, credentials, or privileged workflow behavior.

Default policy:

- Access: restricted to platform/security/operations roles
- Masking: required for secrets, tokens, endpoints, and privileged identifiers
- Retention: must declare retention policy
- Audit: full query, export, policy, and agent-action audit
- Agent behavior: observe-only by default; operational actions require explicit grant and approval gate

## Conflict Resolution

When multiple classifications apply, the strongest applicable policy wins.

Default strength order:

```text
public < internal < confidential < restricted
```

Domain-specific classifications add requirements rather than replacing sensitivity classifications:

- `pii`
- `financial`
- `customer_data`
- `operational_sensitive`

For example, `internal + pii` means internal access is not enough; PII masking, retention, and audit requirements still apply.

## Runtime Policy Resolution

The runtime control plane resolves effective policy by:

1. Collecting inherited classifications from domain, product, asset, and field.
2. Applying explicit classifications from the authored contract.
3. Applying approved classification exceptions.
4. Computing default access, masking, retention, audit, and agent behavior.
5. Applying explicit governance refinements from the contract.
6. Rejecting unapproved attempts to weaken inherited governance.

## Open Questions

1. Which classifications must require retention in v0?
2. Which classifications must block agent row-level export by default?
3. Should `restricted` always imply approval-gated agent actions?
4. What is the exact policy mapping to TiDB Cloud Lake grants and masking features?