PUBLIC PROJECTS

Projects

A selection of public projects where I build solutions around Data Governance, automation and data architecture. Each case summarizes the problem it addresses, the approach taken and the main design decisions, with the repository available for reviewing the implementation in detail.

In development

collibra-governance-automation

Collibra Governance Automation

v2.0.0

Open-source Python Governance-as-Code engine with a public Provider SDK (API 1), provider-neutral configuration, metadata provenance and authority, conflicts, lineage, impact and drift, deterministic planning and safe Collibra reconciliation — dry-run by default, preflight and explicit authorization. External reference provider: governance-provider-example.

Problem it solves

PostgreSQL, ODCS, dbt and OpenLineage describe different parts of the same ecosystem. The challenge is not simply collecting that metadata, but giving it a common identity, preserving where it came from, analyzing authority and conflicts, and understanding impact and drift before changes reach a governance platform.

How I approached it

The project combines Governance-as-Code, change intelligence and an extensible Provider SDK (API 1). It builds a vendor-neutral governance core, analyzes provenance, authority, conflicts, lineage, impact and drift, prepares deterministic plans and only then reconciles with Collibra — dry-run by default, preflight and explicit mutation authorization. An external example provider (governance-provider-example) proves the same public registration model.

In development

purview-governance-automation

Microsoft Purview Governance Automation

v1.2.0

Python Governance-as-Code for Microsoft Purview v1.2.0: desired state, permission-scoped remote state, deterministic comparison and planning, Scanning & Classification, Unified Catalog (Public Preview, contract v3), dry-run by default, stale-state protection, fail-closed safety and controlled apply with explicit authorization. Offline contracts ≠ live-tenant validation.

What problem it solves

When Purview configuration is maintained through manual operations or direct scripts, it becomes difficult to know what should exist, what has actually changed and what will be modified in each execution.

How I approached it

The project starts from a desired configuration, observes the live Purview state, classifies the differences and generates a deterministic plan. Before writing, it queries the environment again and blocks execution if the state no longer matches the context for which the plan was created.