Composition Patterns¶

Pacto's primitives — bundles, references, configurations, policies, metadata — compose into platform interfaces. This page documents the patterns teams use in production: when to reach for them, which primitives they rely on, and minimal worked examples.

Each pattern is independent. Stack what you need; ignore what you don't.

Across every pattern, two things are happening. Pacto composes interfaces you already have — a Helm chart's values.schema.json, a provisioning claim's schema — rather than inventing a parallel configuration language: compose, don't replace. And it adds the layer no single schema owns — ownership, dependencies, compatibility and how those interfaces change over time. A JSON Schema describes one interface; Pacto describes the relationships between them.

The patterns¶

How patterns stack¶

These patterns aren't a menu of choices — they compose. A typical platform integration uses several at once:

flowchart TD
    plat["Pattern 4<br/>Platform-published<br/>policy + schema contract"]
    infra["Pattern 2<br/>Infrastructure contracts<br/>(postgres, redis, secrets)"]
    monorepo["Pattern 1<br/>Root + component contracts<br/>(per service)"]
    composable["Pattern 3<br/>Configurations as<br/>composable claims"]
    overrides["Pattern 6<br/>Override files as<br/>deployment surface"]
    progressive["Pattern 5<br/>Progressive policy<br/>versioning"]

    monorepo -->|"refs"| plat
    composable -->|"refs"| infra
    monorepo --> composable
    composable --> overrides
    plat -.->|"governs"| progressive

A platform team publishes its policy + chart schema (4) and one contract per infrastructure type (2). Each service is a monorepo with a root + component contracts (1). Components compose deployment + infrastructure configurations into a single override file per environment (3 + 6). The policy versions tighten over time without forcing migrations (5).