Schema Compatibility = FULL for Regulated Subjects

Subjects labeled regulated=true must declare compatibility FULL or FULL_TRANSITIVE. No breaking changes allowed.

“Schema enforcement is the second pillar — we can't have applications silently breaking each other when one team changes a field.”

Rationale

On audit-grade event streams, schema breakage is a control failure: a consumer the regulator depends on (audit, fraud, claims) can drop events silently. BACKWARD is not enough. A producer field-removal that's BACKWARD-safe still breaks consumers reading old data. FULL_TRANSITIVE prevents both reader and writer regressions across the whole subject history, which is what auditors need to sign off on.

Pattern

label.regulated == true -> compatibility in [FULL, FULL_TRANSITIVE]

Examples

Parameters

Governs

This policy relates to the following Kafka configuration keys:

• compatibility

Implementation

Drop this YAML into Conduktor Console as a ResourcePolicy, then link it from an ApplicationInstance, Application, or KafkaCluster.

# Conduktor self-service ResourcePolicy
# Schema: https://docs.conduktor.io/platform/reference/resource-reference/self-service/#resourcepolicy
# Subject compatibility values: BACKWARD | BACKWARD_TRANSITIVE | FORWARD | FORWARD_TRANSITIVE | FULL | FULL_TRANSITIVE | NONE
---
apiVersion: self-serve/v1
kind: ResourcePolicy
metadata:
  name: subject-full-compatibility-regulated
spec:
  targetKind: Subject
  description: Subjects flagged regulated=true must use FULL or FULL_TRANSITIVE compatibility
  rules:
    - condition: '!(has(metadata.labels) && "regulated" in metadata.labels && metadata.labels["regulated"] == "true") || spec.compatibility in ["FULL","FULL_TRANSITIVE"]'
      errorMessage: "Subjects tagged regulated=true must declare compatibility FULL or FULL_TRANSITIVE — no breaking changes for audit/fraud/claims consumers"

Related policies

• Schema Required for Non-Internal Topics
• Subject Name Must Follow -key / -value Convention
• Subject Compatibility Cannot Be NONE