Skip to main content

Overview

This guide shows how to set up a dbt™ Mesh architecture in Paradime where a parent repository contains PII (Personally Identifiable Information) models, and a child dbt™ project consumes anonymized subsets of these models.

Architecture

Parent Repository Setup

1. Project Structure

2. Model Groups Configuration

3. Private PII Models

4. Public Anonymized Models (Exposed via Mesh)

Child Repository Setup

1. Paradime Mesh Dependencies Configuration

schedule_slug works on dbt™ 1.11 and 1.12. On dbt™ 1.7 to 1.10, use schedule_name with the same value: despite its name, it also takes the slug. See Configure cross-project dependencies.

2. Project Configuration

3. Consuming Parent Models

4. Business Intelligence Models

Paradime Configuration

1. Producer Project Setup

Prerequisites:
  • dbt™ 1.7 to 1.12 in both projects (dbt-loom isn’t available on dbt™ 2.0)
  • At least one successful Bolt schedule run in the producer project
  • Models with access: public configuration
Producer project requirements:
Ensure a Bolt schedule in the parent workspace runs a command that writes the manifest, such as dbt build. Paradime fetches the parent’s model metadata from that schedule. Copy its slug with the copy icon next to the schedule’s name in Bolt.

2. Consumer Project API Credentials Setup

Step 1: Generate API credentials in the producer workspace
  • Switch to the producer workspace (customer_data_platform)
  • Go to Settings > API Keys and open the Workspace tab
  • Generate an API key with only the Bolt schedules metadata viewer capability
  • Copy the API Key, API Secret, and API Endpoint
On dbt™ 1.11 and 1.12 you can use an account API key instead. See Use an account API key. Step 2: Set the variables once in the consumer workspace In the consumer workspace, go to Settings > Environment Variables, click Add variable, and add each variable with its value in the Default box:
Default values reach Bolt schedules, every developer’s Code IDE, catalog builds, and agent sessions, so developers don’t set anything themselves and don’t need access to the producer workspace.

3. Model Referencing in Consumer Project

Always use the two-argument ref function when referencing models from the producer project:

Security Considerations

Access Control

  • PII models are in private_data group with no public access
  • Only anonymized models in public_analytics group are exposed
  • Child projects can only access explicitly exposed models
  • The parent workspace’s API key is readable by everyone who uses the Code IDE in the child workspace, and it can read all of the parent’s Bolt runs, including logs and artifacts. Use a dedicated key with only the Bolt schedules metadata viewer capability.

Testing Strategy

1. Parent Project Tests

2. Child Project Tests

Best Practices

  1. Regular Security Audits: Review anonymized models quarterly
  2. Change Management: Use PR reviews for any changes to public models
  3. Documentation: Keep anonymization logic well-documented
  4. Testing: Implement comprehensive tests for PII detection
  5. Monitoring: Set up alerts for mesh model failures
  6. Version Control: Tag releases when exposing new models

Troubleshooting

Common Issues

  1. Model not found in child: Check access configuration and group assignment
  2. PII exposure: Review anonymization logic and add tests
  3. Stale data: Monitor upstream model runs in parent project
  4. Permission errors: Verify Paradime project dependency configuration

Debug Commands

Common Issues and Solutions:
  1. “Model not found” errors
    • Verify dbt_loom.config.yml configuration
    • Check that environment variables are set correctly
    • Ensure the Bolt schedule has run successfully in producer project
    • Confirm model has access: public in producer project
  2. API authentication errors
    • Verify the credentials are set in the Default box of the consumer workspace, with names that match the ${...} names in dbt_loom.config.yml
    • Check API key permissions include “Bolt schedules metadata viewer”
    • Ensure API endpoint URL is correct
  3. Stale metadata
    • Producer project must have successful Bolt schedule runs
    • Paradime fetches metadata from the schedule whose slug you set in schedule_slug
    • If producer models change, wait for next Bolt schedule run
  4. Model access denied
    • Check model access configuration in producer project
    • Only public models are available through mesh
    • Verify model is in correct group with appropriate access level
This setup ensures that sensitive PII remains secure in the parent repository while providing rich, anonymized datasets for analytics in the child projects through Paradime’s dbt™ Mesh capabilities.