Governance Rules
The policy layer on top of the schema registry — who can register what, how PII fields must be tagged, and what naming conventions apply.
High-Level Design
Governance Rules make downstream privacy controls actually enforceable.
💼 Business Context
- Prevents schema sprawl (ten slightly different ways to represent 'order total') that makes cross-team analytics painful
- Ensures every PII field is correctly classified at the source, which is what makes downstream privacy controls (consent enforcement, access control) actually reliable
- Owned jointly by Platform Engineering and Data Governance
🔌 Technical Overview
Governance Rules are policy checks the Schema Registry runs on every registration or change: naming-convention enforcement (snake_case, consistent event-name verbs), mandatory classification tags on any field that could contain PII, and required ownership metadata (which team owns this event type). Registrations that violate policy are rejected with a specific, actionable error rather than silently accepted.
Enforced Rules
💾 Governance Policy Check
{
"field": "properties.customer_email",
"issue": "missing PII classification tag",
"required_action": "add classification: 'pii.email'",
"status": "rejected"
}
🔗 Integration Points
- Schema Registry — where governance checks run alongside compatibility checks
- Governance & Security's data classification taxonomy — the source of valid PII tags
- Data Governance team — reviews and updates the rule set over time
- Audit Logs — every governance rejection is logged for compliance visibility
🧰 Services Consumed
- Owning microservice —
Cxos.Processing.SchemaGovernance.Api(see the Full Application Service Map) - Database — Azure Database for PostgreSQL (relational, ACID)
⚠️ Non-Functional Considerations
- Scale: policy checks are rule-based and fast, no different in cost from compatibility checking
- Latency: runs synchronously as part of schema registration, same CI-gate pattern as compatibility checking
- Reliability: rule updates are versioned so historical schemas aren't retroactively marked non-compliant
- Security/Privacy: this is itself a core privacy control — correct PII tagging here is what makes consent enforcement and encryption policy enforceable downstream
🎯 Enterprise Example
A team registers a new event type with a customer_ssn field but forgets to tag it as PII. Governance Rules rejects the registration until the field is properly classified — preventing an unclassified sensitive field from ever reaching the pipeline where it could bypass consent and encryption controls built around classification tags.