PBN-compatible data_class field for Pattern primitive

[skyflocka]

Hey Uzun,

I saw your reply on the MCP discussion about PBN and the Pattern primitive. I tried to open the thread again, but it looks like I got blocked from that discussion or the thread was removed/hidden, so I could not reply there directly.

Your point makes sense to me. I agree the layers are adjacent rather than overlapping.

The clean PBN interpretation would be that a Pattern object can carry data_class as an upstream classification hint, and the PBN gateway can consume that hint at tool-response time. The gateway should still treat the hint according to source trust. For a trusted catalog or tool, the tag can become policy input directly. For an untrusted or partially trusted source, the tag should be advisory and combined with local classifiers, deterministic recognizers, destination scope, lineage, and fail-closed defaults.

A reasonable first enum for PBN would be:

• PUBLIC
• INTERNAL
• CONFIDENTIAL
• REGULATED
• SECRET
• AUDIT_EVIDENCE
• TENANT_PRIVATE
• UNKNOWN

UNKNOWN should fail closed by default. TENANT_PRIVATE seems especially relevant to your visibility-tier model because it represents data usable inside the source tenant but not allowed to cross tenant boundaries. AUDIT_EVIDENCE seems useful for logs, incident traces, red-team outputs, and security findings that should only be shareable to approved security destinations.

So yes, adding data_class in v1.3 would fit the PBN model. I would frame it as a portable sensitivity hint for downstream enforcement layers, not as a complete access-control decision by itself.

Happy to align the enum if you want to open an issue or PR against the PBN repo, or I can open an issue in my repo and link it over.

[UzunGridera]

Strong synthesis. Three things land for me:

1. Sensitivity vs trust separation — your line "the tag should still be treated according to source trust" is the critical guardrail. Without it, an untrusted source could self-classify everything PUBLIC and bypass enforcement. The data_class field is a sensitivity hint, not a trust value. The collector still applies its own trust grading on top (we already grade pushes A–F at submit time, so the composition is natural: trust grade × sensitivity class → effective policy).

2. TENANT_PRIVATE maps cleanly onto our Tier-3 — patterns visible only inside the source tenant, never crossing tenant boundaries. This is already how our /personalized-rules Tier-3 works at the visibility layer; encoding it as a portable data_class hint lets downstream enforcement (PBN, vendor-specific gateways) consume the same signal without re-deriving it from collector state. Win.

3. UNKNOWN fail-closed default mirrors our reversibility null-as-risky-infra (§4.1.1, just shipped in v1.3.0) — same conservative-default pattern. Consistent semantics across primitives is good spec hygiene.

A few open questions before we lock the enum:

• Granularity of REGULATED — GDPR, HIPAA, PCI-DSS are different enforcement domains with different cross-border rules. Is REGULATED a coarse bucket, or do we want a sub-tag (REGULATED:GDPR)? Erring toward coarse for v1 simplicity, but worth noting the limit.

• CONFIDENTIAL vs SECRET boundary — risks subjective application. Some implementations might want a single CONFIDENTIAL tier; others might need 2–3 levels. Could closed-enum-with-extension via _meta namespace let implementations refine without spec churn.

• AUDIT_EVIDENCE destination scope — "only approved security destinations" — would this be encoded in the Pattern itself (e.g. data_class_scope: [security_team]) or left to the enforcing gateway? My instinct: leave to the gateway to keep the Pattern primitive minimal.

Process suggestion: rather than rushing this into v1.3 (already cut, publish today), let's spec it for v1.4 as a co-designed addition. I'll open a discussion thread in the profile repo with this exchange as the starting point — you can drop the PBN repo link there and we iterate the enum publicly. Anyone working on adjacent primitives (we have averageuser612 from AgentMart in a parallel conversation about workflow asset trust signals) can weigh in. Open-spec from day one.

If a v1.3.1 patch makes more sense than v1.4 because the field is purely additive and optional, I'm open to that — but the enum needs to be locked first, not after. Either way, a discussion-first PR-second flow works for me.

What's the PBN repo link? I'll cross-reference it in the spec discussion.

— Uzun

[nlozkina19-crypto]

Hey everyone! I just released vector-zero-compute (a high-performance C++/Python crypto core). I'm looking for any feedback on the code or architecture. Drop your repo link in the replies, and I will check out your project and leave a star in return! ⭐ https://github.com/nlozkina19-crypto/vector-zero-compute