Skip to content

Data classification

Sensitivity tags ground the SecurityArchitect's concern generation in declared sensitivity rather than name-guessing.

Declaring sensitivity

"data_classification": [
  {"field_ref": "User.password_hash", "sensitivity": "credential"},
  {"field_ref": "Session.token", "sensitivity": "session_token"},
  {"field_ref": "User.email", "sensitivity": "pii"}
]

Sensitivity tags

Tag Meaning What the SecurityArchitect does
credential Authentication secrets (passwords, hashes, API keys) Cannot be exposed via getters; never logged; constant-time comparison required.
session_token Bearer tokens, CSRF tokens Stored opaquely; rotated on privilege change; never returned to the client unless freshly minted.
pii Personally identifiable information Logging redacted; access requires explicit use-case authorization; encryption at rest.
payment Card numbers, account numbers PCI-style handling; never persisted in plaintext; tokenization required.

How it couples to the architecture

The framework's validate_architecture_against_spec validator checks that every declared data_classification.field_ref actually exists in some Entity or ValueObject in the emitted Squib. Misnamed refs produce a clear error.

The SecurityArchitect (Manager tier) consumes the tags directly and emits a SecurityConcern per declared sensitive field. Each concern flows into the Tier C / DDD ICPs as constraint context (e.g., a User Entity with a credential-tagged field gets a constraint forbidding it in __repr__).

See also