Data Classification Matrix (4-Level)

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Incident data contains public status, internal diagnostics, customer payloads and credentials for an external support summary. Define a four-level teaching matrix first; internal-tool origin grants no transfer permission.

Mechanism

Classify fields under supplied policy: public to authorized support, internal to approved internal destinations, restricted to designated processing environments, secret to credential facilities. Declare transformations such as approved public status/nonidentifying counts. Hold unknown fields, inspect proposed payload/recipient and verify task sending authority with policy revision recorded.

Bad example

Send the whole internal-tool result externally and assume redaction makes every class public.

Good example

Apply the teaching four-level matrix, emitting only approved public status/aggregate counts. Exclude customer payloads/internal diagnostics/secrets and hold unknowns; transformation does not automatically downgrade. Check destination and existing send authority before execution.

Why the change matters

Policy follows meaning/destination rather than tool reputation. Field-level and transformation rules prevent redaction/aggregation becoming unconditional disclosure.

Observable expectation

A teaching payload containing customer content/secrets violates the matrix; approved status/count may remain. Unknown account labels need classification, not default public. Record target/policy without exposing originals as evidence.

Limits

No frozen source is confirmed; this is local teaching policy, not law/provider permission. Small aggregates can identify people. Classification and sending authority are separate; matrix compliance does not itself authorize external transmission.