v1.4 proposal: data_class sensitivity hint on Pattern primitive

[UzunGridera]

Context

This thread is opened to spec the addition of a data_class field to the Pattern primitive (§4.1) for v1.4. Origin: technical exchange with @skyflocka in Discussion #3 — proposal arose from MCP working group cross-pollination (PBN: data-flow enforcement at agent-tool boundary).

This discussion is the public design seed. Discussion-first, PR-second.

What data_class is (and isn't)

Is: A portable sensitivity hint on a Pattern, consumable by downstream enforcement layers (gateways, tokenizers, audit pipelines).

Isn't: A trust signal. Trust grading remains separate (status, source attribution, observed-vs-documented). The data_class field describes what kind of data this pattern relates to, not whether to trust the source.

The composition is intentional: trust_grade × data_class → effective policy.

Proposed enum (skyflocka v0)

PUBLIC          # no restrictions
INTERNAL        # within-tenant only, low sensitivity  
CONFIDENTIAL    # within-tenant only, restricted
REGULATED       # subject to compliance frameworks (GDPR, HIPAA, etc.)
SECRET          # high-sensitivity, narrow access
AUDIT_EVIDENCE  # logs, incident traces, security findings — limited destination
TENANT_PRIVATE  # never crosses tenant boundaries (maps to existing Tier-3)
UNKNOWN         # default, fail-closed equivalent

UNKNOWN would be the implicit default for any pattern without an explicit data_class. Consumers MUST treat UNKNOWN as fail-closed (refuse cross-boundary use). This mirrors the §4.1.1 reversibility null-as-risky-infra contract shipped in v1.3.0.

Open questions for delta

The skyflocka exchange surfaced 3 design points that deserve broader input:

Q1 — Granularity of REGULATED

GDPR, HIPAA, PCI-DSS, SOX are all "regulated" but with different cross-border semantics. Options:

• (a) Single coarse REGULATED value. Implementations compose with _meta extensions when needed.
• (b) Sub-tags: REGULATED:GDPR, REGULATED:HIPAA. Explicit but verbose.
• (c) Separate top-level values: REGULATED_GDPR, REGULATED_HIPAA. Explosion risk.

Leaning (a) for v1 simplicity. The _meta namespace allows refinement without spec churn — consumers needing finer-grained handling can extend via reverse-DNS namespace (e.g. _meta["com.agentminds.data_class_subtype"] = "GDPR").

Q2 — CONFIDENTIAL vs SECRET boundary

Both are "restricted within tenant" but with different stakes. The boundary risks subjective application — one team's CONFIDENTIAL is another's SECRET.

• (a) Keep both, document boundary explicitly: SECRET = "exposure causes material harm to the originating party"; CONFIDENTIAL = "exposure violates internal policy but does not cause direct harm."
• (b) Collapse into single CONFIDENTIAL tier; let implementations sub-tag via _meta if they need SECRET semantics.
• (c) Three tiers: CONFIDENTIAL → RESTRICTED → SECRET (Microsoft Information Protection style).

Leaning (a) with explicit boundary documentation.

Q3 — AUDIT_EVIDENCE destination scope

@skyflocka noted: "only approved security destinations." Where does the destination policy live?

• (a) Encoded in the Pattern itself: data_class_destinations: ["security_team", "incident_response"].
• (b) Left to the enforcing gateway (PBN, custom). The Pattern carries data_class: AUDIT_EVIDENCE, downstream knows what to do.

Leaning (b) — keeps the Pattern primitive minimal. Pattern says what kind of data, gateway says who can see it.

What I need from contributors

1. @skyflocka — PBN repo link for cross-reference; engagement on Q1–Q3.
2. Anyone with adjacent trust/sensitivity primitives — workflow assets (e.g. AgentMart), eval set rows, runtime gating systems. How does data_class interact with your model?
3. Implementers — would you actually use this if shipped in v1.4? What blocks adoption?

Process

• This thread is the design seed. Iterate here.
• When the enum + open questions are resolved, PR opens against agentmindsdev/profile with §4.1.X draft text + schema changes.
• PR is the formal vote. This thread is the discussion that gets us there.
• v1.4 release timing depends on convergence speed. No deadline pressure.

Background reading

• Discussion PBN-compatible data_class field for Pattern primitive #3 (origin): PBN-compatible data_class field for Pattern primitive #3
• §4.1.1 reversibility (similar primitive shipped v1.3.0): https://github.com/agentmindsdev/profile/blob/main/AGENT_REPORTING_PROFILE.md
• Eval set v0 strawman (parallel open-spec artifact): https://github.com/agentmindsdev/profile/blob/main/eval-set/v0-strawman.md
• MCP discussion that triggered this (now removed upstream — original PBN proposal by @skyflocka)

— Uzun