Schema-to-workflow mapping

Every gate check is a query, not a policy.

The safe and account provisioning workflows aren't enforced by training or process discipline — each gate is a lookup against the schema. Here's exactly which tables and fields each check reads.

Workflow 1 — Safe provisioning

A requester submits a safe request scoped to their own affiliation.

Step	Check performed	Reads from
Catalog visibility	Which business app + instance can this requester even select	sys_user_grmember ⋈ sys_user_group
Duplicate check	Does a safe already exist for this instance	u_pam_safe.appl_instance
Job-code gate	Is this a CTB job code requesting a production instance	sys_user.job_code_type + appl_instance.environment
Approval routing	Who is the accountable owner to approve this	cmdb_ci_business_app.owned_by
Safe creation	Tag the new safe to its instance and owner	u_pam_safe.appl_instance, u_pam_safe.service_owner
Permission split	Grant use/retrieve to the group, reconcile to the owner	u_pam_safe_permission.grantee, .permission_level

Workflow 2 — Account provisioning

A requester adds a privileged account, scoped to a safe they're actually entitled to.

Step	Check performed	Reads from
Safe dropdown filter	Only show safes matching the requester's group + instance	u_pam_safe.appl_instance ⋈ sys_user_grmember
Eligibility gate	Is there a matching safe, and does job code clear production	sys_user.job_code_type + appl_instance.environment
Approval routing	Route to the safe's recorded owner, not a generic queue	u_pam_safe.service_owner
Account onboarding	Attach the account to the validated safe	u_pam_account.safe
Rotation scoping	Reconciliation stays with the platform account, not the requester	u_pam_account.reconciliation_account

The gap this closes: without the eligibility gate reading appl_instance ⋈ sys_user_grmember at request time, a requester could onboard any AD account into any safe they can reach — regardless of whether they're the recorded owner. The schema makes "safe I belong to" and "account I own" two separately checked conditions instead of one assumed one.

Detective controls, mapped

Preventive gates reduce the problem; these queries catch what slips through.

01 Owner mismatch alert. Flag any u_pam_safe_permission row with permission_level = reconcile where the grantee doesn't equal u_pam_safe.service_owner.
02 Stale membership sweep. Quarterly recertification against sys_user_grmember — a group membership that's outlived a role change shouldn't silently retain safe visibility.
03 Orphaned safe check. Any u_pam_safe row with a null appl_instance or service_owner is a governance failure by definition — the schema shouldn't allow it, but it's worth alerting on regardless.