Environment Topology and Deployment Pipeline

Meridian uses a three-tier environment model. All changes flow one direction: CONFIG to STAGING to PRODUCTION. No exceptions, no shortcuts.

Topology Overview

Environment	Purpose	Who Has Access
CONFIG	Authoring. Admins build and modify care programs, rules, roles, and integration mappings.	Platform admins, implementation consultants
STAGING	Validation. Production-equivalent environment for testing against real data volumes.	QA, release managers, limited admin access
PRODUCTION	Live. End users work here. Direct config edits are blocked at the application layer.	All licensed users per role; admin config changes blocked

Each tier has its own database cluster, cache layer, and job scheduler. No shared runtime state. Promotion between tiers is handled by the Deployment Pipeline service, not by DB replication or file sync.

Deployment Flow

CONFIG to STAGING

When an admin saves a change in CONFIG, the system captures it as a versioned changeset. Changesets are atomic: full before-and-after state of every object modified in the transaction.

Two ways to promote:

• Timer-based auto-deploy: Scheduled job runs every 4 hours (configurable per tenant). Collects all unpromoted changesets, packages them, applies to STAGING in dependency order.
• Ad-hoc trigger: Release manager selects specific changesets in the Deployment Console and clicks Promote to Staging.

Both paths produce identical deployment artifacts. The only difference is timing.

STAGING to PRODUCTION

No auto-deploy between these tiers. Always requires explicit action:

1. Go to Deployment Console > Staging Bundles.
2. Select the validated bundle.
3. Click Promote to Production.
4. Confirm in the approval dialog.

If the bundle contains destructive changes, the dialog escalates to a two-person gate. Promotion is blocked until a second authorized user confirms.

Deployment Job Types

Job Type	Triggers When	What It Does
SCHEMA_APPLY	Bundle has new/modified data objects	Applies DDL changes. Runs pre-flight validation for column conflicts.
CONFIG_SYNC	Bundle has rule, workflow, or role changes	Writes config records to target. Invalidates affected cache keys.
INTEGRATION_REBIND	Bundle has endpoint or credential changes	Updates connection strings, re-authenticates, runs connectivity health check.
CONTENT_DEPLOY	Bundle has templates, forms, or UI text	Publishes to CDN layer. Purges stale cache.
DESTRUCTIVE_APPLY	Bundle has deletions, field removals, or state reductions	Runs only after gate approval. 72-hour rollback window.

A single bundle can trigger multiple job types. Execution order: SCHEMA_APPLY first, then CONFIG_SYNC, then CONTENT_DEPLOY. INTEGRATION_REBIND runs parallel to CONFIG_SYNC unless the bundle includes credential rotation, in which case it runs last.

Destructive Change Gate

A change is destructive if it removes data, reduces access, or eliminates a workflow state that records currently occupy:

• Deleting a care program with active enrollments
• Removing a custom field that contains data
• Eliminating a workflow status while records hold that status
• Revoking a role assigned to active users

The pipeline flags these at changeset creation time. They carry a DESTRUCTIVE tag and display a warning icon in the bundle summary.

Gate Approval Process

1. Release manager initiates promotion.
2. System detects the DESTRUCTIVE tag. Blocks single-user approval.
3. Second user with Deployment Approver role receives a notification.
4. Second approver reviews impact summary (affected record counts, downstream dependencies). Approves or rejects.
5. On approval: DESTRUCTIVE_APPLY job executes with 72-hour rollback window.

Rejected changes return to CONFIG with a rejection reason. Original admin must modify or withdraw before resubmitting.

Common Errors

Error	Cause	Resolution
DEPENDENCY_UNRESOLVED	Changeset references an object not in the bundle and not in the target environment.	Add the missing dependency or promote it first.
SCHEMA_CONFLICT	Column/table exists in target with a different data type.	Align schema definition in CONFIG with target state, re-promote.
GATE_TIMEOUT	Destructive bundle waited 48+ hours for second approver.	Re-initiate promotion. Original approval is invalidated.
INTEGRATION_UNREACHABLE	Health check failed: external endpoint did not respond.	Verify endpoint accessibility from target network. Check firewall rules and credentials.
CACHE_INVALIDATION_PARTIAL	CDN purge completed for some regions but not all. Transient network issue.	Re-run CONTENT_DEPLOY. If persistent, escalate for manual cache flush.

All errors logged in Deployment Console > Bundle History > [Bundle ID] > Job Log. Failed jobs do not leave partial state. The pipeline applies changes transactionally and rolls back on failure.