Learn

Multi-Pattern Validation

⏱ 3 min read🟡 Intermediate · 30-45 minutesEdit on GitHub ↗

Overview

Learn how to validate a single architecture against multiple Patterns simultaneously — combining structural patterns with standards-enforcing patterns for complete, layered governance. This is the culmination of the Intermediate tutorials, bringing together all concepts from earlier lessons.

Learning objectives

By the end of this tutorial, you will:

Update your generated web application to comply with organizational Standards
Validate against structural and standards-enforcing patterns
Understand why multi-pattern validation scales better than combined patterns
Integrate multi-pattern validation into a CI/CD pipeline

Prerequisites

Complete Enforcing Standards with Patterns first. You will need your patterns/company-base-pattern.json, patterns/web-app-pattern.json, architectures/generated-webapp.json, and url-mapping.json.

Step-by-Step Guide

1. Review Your Current State

Your generated-webapp.json from the Introduction to CALM Patterns lesson validates against the web app structural pattern:

calm validate -p patterns/web-app-pattern.json -a architectures/generated-webapp.json

Should pass ✅ — structure is correct.

Now try the Standards pattern:

calm validate -p patterns/company-base-pattern.json -a architectures/generated-webapp.json -u url-mapping.json

Should fail ❌ — missing costCenter, owner, environment on nodes and dataClassification, encrypted on relationships.

2. Add Standards Properties to Nodes

Open architectures/generated-webapp.json and update each node to include Standard properties:

Prompt:

Update architectures/generated-webapp.json to add Standard-compliant properties to ALL nodes.

For each node, add these properties (alongside existing properties like unique-id, name, etc.):
- costCenter: use the values below
- owner: use the team names below  
- environment: "production" for all

Here are the mappings:
- web-frontend: CC-1001, frontend-team
- api-service: CC-2001, backend-team
- app-database: CC-3001, data-team

Keep all existing node properties intact.

3. Add Standards Properties to Relationships

Update each relationship in generated-webapp.json:

Prompt:

Update architectures/generated-webapp.json to add Standard-compliant properties to ALL relationships.

For each relationship, add:
- dataClassification: appropriate level based on data sensitivity
- encrypted: true (all communications should be encrypted)

Use these classifications:
- frontend-to-api: "internal" (browser to API)
- api-to-database: "confidential" (API to database contains sensitive data)

Keep all existing relationship properties intact.

Apply to all relationships in the architecture.

4. Validate Against the Standards Pattern

calm validate -p patterns/company-base-pattern.json -a architectures/generated-webapp.json -u url-mapping.json

Should now pass! ✅

5. Validate Against Both Patterns

# Structural validation
calm validate -p patterns/web-app-pattern.json -a architectures/generated-webapp.json

# Standards validation
calm validate -p patterns/company-base-pattern.json -a architectures/generated-webapp.json -u url-mapping.json

Both should pass! ✅ ✅

6. Understand the Power of Multi-Pattern Validation

Why not just combine everything into one pattern?

Approach	Patterns Needed	Maintenance
Combined patterns	1 per architecture type × standards	N patterns to update when standards change
Multi-pattern validation	1 structural + 1 standards	Update standards once, applies everywhere

Example: If you have 10 different architecture types and your company updates its Standards:

Combined patterns: Update 10 patterns
Multi-pattern validation: Update 1 standards pattern

The real power: your company-base-pattern.json works with every architecture type, not just 3-tier web apps. You write the Standards once, and they apply everywhere.

Multi-Pattern Validation
─────────────────────────────────────────────────────────────────
generated-webapp.json ──► web-app-pattern.json      ✅ (structure)
                     └──► company-base-pattern.json  ✅ (standards)

future-microservice.json ──► microservice-pattern.json  ✅ (structure)
                         └──► company-base-pattern.json  ✅ (standards)

future-data-pipeline.json ──► pipeline-pattern.json     ✅ (structure)
                          └──► company-base-pattern.json ✅ (standards)

                                    ▲
                         One standards pattern
                         for all architectures

7. Integrate into CI/CD

Add multi-pattern validation to your GitHub Actions workflow:

# .github/workflows/calm-validate.yml
name: CALM Multi-Pattern Validation

on: [push, pull_request]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
      - run: npm install -g @finos/calm-cli

      - name: Validate Structure
        run: |
          calm validate \
            -p patterns/web-app-pattern.json \
            -a architectures/generated-webapp.json

      - name: Validate Standards Compliance
        run: |
          calm validate \
            -p patterns/company-base-pattern.json \
            -a architectures/generated-webapp.json \
            -u url-mapping.json

8. Update the Patterns README

Prompt:

Update patterns/README.md to document the multi-pattern validation approach:

1. Explain how structural patterns and standards patterns work together
2. Explain why this is better than combined patterns
3. Describe how this enables CI/CD governance
4. List the current patterns:
   - web-app-pattern.json (structural)
   - company-base-pattern.json (standards)

Validation Strategy

Architectures should be validated against multiple patterns:

Structural pattern (e.g., web-app-pattern.json) — validates the correct node types and relationships for the architecture style.
Standards pattern (company-base-pattern.json) — validates organizational standards (costCenter, owner, environment, dataClassification, encrypted).

Run both validations before committing any architecture change.

Use git to version-control your work so far. Small, frequent commits make it easier to track the evolution of your architecture over the course of this series.

Key concepts