Blog
Governance: policies, access, and compliance
Governance is the set of rules and controls that determine who can see what, how data may be used, and how the product stays compliant. Here’s what it is, how it’s made with explicit examples, and why it’s a core part of every governed data product.
What it is
Governance is the “who can do what with this data?” layer of a governed data product. It includes access policies (who can read, write, or share), usage policies (e.g. “no PII in logs,” “internal only”), retention and deletion rules, and compliance mappings (e.g. “this field is PII under GDPR”). Without governance, a product might be technically consumable but legally or ethically unsafe to use. In Loxtep, every governed data product has governance metadata so the context we deliver is not only useful but compliant and auditable.
How it’s made
Governance for a governed data product is defined and enforced as follows:
- Access policies. You define who can access the asset (by role, team, or attribute) and at what level: read-only, read+export, or admin. Policies are stored as rules (e.g. “role:support can read orders for their region”) and evaluated at consumption time. Denied requests are logged; approved requests may still be subject to field-level masking (see below).
- Field-level rules and masking. Sensitive fields (PII, financials) are tagged in the lexicon. Governance specifies how they’re handled: e.g. “email is PII; mask for role:support except when ticket_id is present,” or “revenue is internal-only; hide for external partners.” Masking can be redaction, hashing, or substitution (e.g. “Confidential”).
- Retention and deletion. Governance includes retention (e.g. “order context retained 7 years for audit”) and deletion rules (e.g. “on customer deletion request, purge PII within 30 days”). These drive lifecycle jobs and support GDPR/CCPA and internal policy.
- Compliance metadata. Each asset (and optionally each field) can carry compliance tags: e.g. “GDPR personal data,” “SOX relevant,” “healthcare PHI.” That metadata is used for reporting, access decisions, and audit trails.
Example governance block for an Orders context asset:
{
"governance": {
"access": [
{ "role": "support", "scope": "region", "action": "read" },
{ "role": "finance", "action": "read,export" },
{ "role": "admin", "action": "read,write,delete" }
],
"field_rules": [
{ "field": "customer.email", "classification": "PII", "mask_for": ["support"], "except_when": "ticket_id present" },
{ "field": "order.revenue", "visibility": "internal_only" }
],
"retention": { "default": "7y", "pii_on_deletion_request": "30d" },
"compliance": ["GDPR", "SOX-relevant"]
}
}In Loxtep, governance is configured when you define or update the governed data product. Policies are enforced at the consumption layer (API and query) and in any exports or feeds, so the same rules apply whether a human, an app, or an AI is consuming the data.
Why it matters for governed data products and AI
Context that isn’t governed is a liability. By making governance a first-class part of the governed data product, you ensure that access is correct, usage is compliant, and changes are auditable. For AI, governance determines what the model is allowed to see and do with the data — so you get useful context without exposing what shouldn’t be exposed. In Loxtep, every governed data product includes governance so the context we deliver is safe, compliant, and traceable.