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: publicconfiguration
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
3. Model Referencing in Consumer Project
Always use the two-argumentref function when referencing models from the producer project:
Security Considerations
Access Control
- PII models are in
private_datagroup with no public access - Only anonymized models in
public_analyticsgroup 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
- Regular Security Audits: Review anonymized models quarterly
- Change Management: Use PR reviews for any changes to public models
- Documentation: Keep anonymization logic well-documented
- Testing: Implement comprehensive tests for PII detection
- Monitoring: Set up alerts for mesh model failures
- Version Control: Tag releases when exposing new models
Troubleshooting
Common Issues
- Model not found in child: Check access configuration and group assignment
- PII exposure: Review anonymization logic and add tests
- Stale data: Monitor upstream model runs in parent project
- Permission errors: Verify Paradime project dependency configuration
Debug Commands
- “Model not found” errors
- Verify
dbt_loom.config.ymlconfiguration - Check that environment variables are set correctly
- Ensure the Bolt schedule has run successfully in producer project
- Confirm model has
access: publicin producer project
- Verify
- API authentication errors
- Verify the credentials are set in the Default box of the consumer workspace, with names that match the
${...}names indbt_loom.config.yml - Check API key permissions include “Bolt schedules metadata viewer”
- Ensure API endpoint URL is correct
- Verify the credentials are set in the Default box of the consumer workspace, with names that match the
- 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
- Model access denied
- Check model
accessconfiguration in producer project - Only
publicmodels are available through mesh - Verify model is in correct group with appropriate access level
- Check model