A governed HR data warehouse, live in five weeks

The problem

Every People question routed through a person. Headcount, recruiting funnel, internal mobility, attrition. Each answer meant a spreadsheet pull, a Workday report, and a reconciliation argument about which number was right. Ad-hoc internal tools had grown up to fill the gap, each with its own numbers. Prior attempts at a unified People data layer had been scoped but never shipped.

Six weeks into the role, after discovery interviews across the People org and hands-on fixes in half a dozen systems, I wrote a position statement proposing something deliberately modest: a rudimentary data warehouse, following the patterns the company's data platform already used. Not a new platform. A governed layer inside the existing one.

The shape was obvious: a governed warehouse on Databricks, fed by Fivetran, with one canonical definition per metric. The hard part was that this is the most sensitive data in the company. HR data platforms usually die one of two deaths. They stall for quarters in security review, or they ship fast and leak. I wanted neither.

What I built

A certified data layer on Databricks with conformed workforce and recruiting dimensions: a position spine, worker-movement and internal-mobility metric views, interview and scorecard event signals, and stage-level funnel metrics, fed by four integrated source systems (Workday, Greenhouse, Gem, and native Airtable ingestion).

On top of that, a canonical measure registry: 100+ measures organized into six metric doors, so any consumer asking about headcount, hiring, mobility, or attrition arrives at one definition rather than negotiating a new one.

• Certified dimensional models for workforce and recruiting, roughly 50 core models
• Canonical measure registry with owned, documented definitions
• Discovery layer: data dictionary and object catalog with machine-readable access and consumability signals
• Automated acceptance harness scoring findability and traversal on every build
• Nightly rebuild of the modeled layers from raw, so drift cannot accumulate silently
• Reconciliation against the system of record on every quantitative surface

The build order: security before the first model

The governance layer existed before any data model did. That inverts the usual order, and it set the pace for everything after. Day one was the schema skeleton, the security tables, and the admin grant structure. Day two was an audit mart reading the platform's system tables, so access was observable before there was anything interesting to access. Access rules live in tables rather than code, with audit columns on every row: who requested it, who approved it, and a link to the decision.

The first governed consumption layer went live on day ten, exposing core workforce models through views with a row filter deriving each HR business partner's visibility from their actual org assignments in the system of record, instead of hand-maintained lists. Three days later the first governed metric views shipped: headcount and attrition, sliceable, with one definition each.

Speed came from aggressive descoping backed by written decisions. The original consumption-layer design carried column masking and suppression logic; I cut it to a minimal row-level V1 and shipped that week. Later I retired column masking as a mechanism entirely and rebuilt the access model on row filters and grain partitioning: row-grained data in one schema for narrow audiences, aggregate metric views in another for broad ones. Sixty-four architecture decision records document that trail, including the reversals.

This ordering looks slow. It saved weeks, because it deleted the security-retrofit phase, which is the phase where these projects go to die. No model ever shipped temporarily open.

Designed for agents, not just analysts

The rollout model is agent-first. Instead of waiting on dashboard adoption, the People team queries certified data through AI agents and gets granular answers, like a full hiring history for a role, reconciled, in seconds. A People-org executive explores the warehouse directly.

That only works if the warehouse is legible to a non-human consumer. So the discovery layer is a first-class product surface: a catalog of objects, machine-readable tiers marking what is certified and directly consumable, explicit temporal semantics, and a daily harness that fails the build when an agent can no longer find or traverse what it needs.

Privacy and access, built in from day one

HR data is the most sensitive data in a company. Governance was not a hardening phase bolted on at the end. It shipped with the first models and gated every merge after: everything is code except data, and no HR data value has ever entered the repository.

• Row-level access governance, with an audit of existing access that surfaced widespread overscope and corrected it
• Access state queried live from the catalog, never trusted from documentation, with a daily job that flags drift between what is merged and what is deployed
• Automated masking of protected-category and PII columns
• Column-level sensitivity classification across the estate, over a thousand columns tagged
• Small-cell suppression on demographic surfaces
• Privacy checklist on every pull request, plus a second adversarial review pass on security-relevant diffs
• Automated deploys, but manual human gates on grants and security changes
• Credential-free deployment pipelines, with no static secrets in the repository
• Secret scanning, static analysis, and SQL governance enforced in CI
• Egress scoped to named recipients through a dedicated share catalog, never org-wide
• Defined recovery objectives and a tested runbook

How one person shipped it

I built this solo, and I did not type most of it. The build ran as an orchestration loop: AI agents drafted SQL, models, and docs in parallel worktrees while I made every architecture decision, reviewed every diff, and held every merge and every production grant behind an explicit human gate. The commit history reads like a small team's because functionally it was one, with one accountable human at the center.

The agents were fast because the governance was strict. Machine-checkable rules, a privacy checklist on every PR, and decisions written down as ADRs are exactly the substrate that lets you delegate aggressively without losing control, whether you are delegating to a teammate or to an agent fleet.

• 11 weeks from empty repository to the full platform, 5 weeks to the first production release
• 632 commits and 384 pull requests, every one through review
• 64 architecture decision records, including the reversals
• 4 source systems integrated
• 0 HR data values ever committed to version control

Where it stands

Live in production. A workforce overview surface is in use, governed shares deliver a scoped roster to Finance, and a second data domain is onboarding. I remain the production gatekeeper: every deploy runs behind an explicit approval.

The takeaway I would hand to anyone building this: build the audit and access layer first, write decisions down and let them be reversed on the merits, and put automation everywhere except the blast radius. I never had to choose between shipping fast and locking the data down. The controls were the reason I could ship fast.