Deployment-Ownership Engineering Profile in Archify: Requirements and Validation Guide

The deployment-ownership engineering profile enforces six strict validation rules requiring explicit owner tags, single-region membership, security-group boundaries for databases, and labeled connection mechanisms; if any requirement is violated, the diagram fails validation immediately.

Archify is an open-source architecture diagramming tool that validates infrastructure designs against engineering standards through JSON-based schema definitions. Enabling the optional deployment-ownership engineering profile activates a fail-closed validation gate that ensures every component has explicit ownership, unambiguous geographic placement, and properly secured boundaries before deployment.

What Is the Deployment-Ownership Profile?

The deployment-ownership profile is defined in archify/schemas/architecture.schema.json at line 23, where the engineering_profile field is restricted to the single enum value "deployment-ownership". This profile is implemented in archify/renderers/shared/engineering-profiles.mjs via the DEPLOYMENT_PROFILE constant and applies strict acceptance criteria documented in docs/deployment-ownership-profile-acceptance-2026-07-23.md.

When enabled by setting meta.engineering_profile: "deployment-ownership", the validator checks your diagram against six concrete requirements. If any check fails, validation halts immediately—the profile is fail-closed.

The Six Core Validation Requirements

The acceptance criteria listed in the deployment ownership profile acceptance document (lines 20‑27) mandate the following constraints:

1. Mandatory Owner Tags for All Components

Every non-external component must include a non-empty tag attribute specifying its owner. This guarantees explicit assignment to an owner team and prevents orphaned infrastructure resources.

2. Single Region Membership

Each non-external component must belong to exactly one region boundary. This rule enforces clear geographic placement and eliminates ambiguous multi-region assignments that could complicate data residency and latency requirements.

3. Minimum Boundary Context

The diagram must define at least one region boundary and one security-group boundary. These boundaries provide the minimal context required for ownership-related isolation checks and security auditing.

4. Database Security-Group Containment

Every database component must belong to a security-group. This requirement ensures that stateful storage resources are protected within defined security groupings and not exposed directly to broader network segments.

5. Security-Group Region Isolation

Each security-group must contain members from exactly one shared region. This prevents cross-region mixing inside security groups, maintaining consistent network isolation and preventing accidental hybrid cloud configurations that bypass regional controls.

6. Explicit Mechanism Labels for Boundary Crossings

Any connection that crosses region or security-group boundaries must include a non-empty mechanism label (e.g., "VPC route", "cross-region WAL", "peering connection"). This makes crossing points explicit and auditable.

How to Enable the Profile

To activate the validation rules, set the engineering_profile field in your diagram's meta object:

{
  "schema_version": 1,
  "diagram_type": "architecture",
  "meta": {
    "title": "Production Deployment",
    "engineering_profile": "deployment-ownership"
  }
}

According to the schema definition in architecture.schema.json, only the value "deployment-ownership" is permitted for this field, ensuring standardized validation behavior across all diagrams.

Valid Deployment Diagram Example

The following JSON satisfies all six requirements:

{
  "schema_version": 1,
  "diagram_type": "architecture",
  "meta": {
    "title": "Production Deployment",
    "engineering_profile": "deployment-ownership"
  },
  "components": [
    { 
      "id": "web", 
      "type": "frontend", 
      "label": "Web", 
      "tag": "frontend-team" 
    },
    { 
      "id": "api", 
      "type": "backend", 
      "label": "API", 
      "tag": "backend-team" 
    },
    { 
      "id": "db", 
      "type": "database", 
      "label": "DB", 
      "tag": "db-team" 
    }
  ],
  "boundaries": [
    { 
      "kind": "region", 
      "label": "us-east-1", 
      "wraps": ["web","api","db"] 
    },
    { 
      "kind": "security-group",
      "label": "private", 
      "wraps": ["db"] 
    }
  ],
  "connections": [
    { 
      "from": "web", 
      "to": "api", 
      "label": "HTTPS" 
    },
    { 
      "from": "api", 
      "to": "db", 
      "label": "VPC route" 
    }
  ]
}

This example demonstrates:

• Owner tags: Each component has a non-empty tag attribute.
• Region membership: All components belong to a single region named us-east-1.
• Security grouping: The db component resides within the private security-group.
• Crossing mechanisms: The connection crossing into the security-group (api → db) includes the explicit label "VPC route".

Validating Your Architecture

Use the Archify CLI to validate your diagram against the profile requirements:

# Validate the JSON and check the resolved engineeringProfile

node archify/bin/archify.mjs validate deployment.json --json

A successful validation returns the resolved profile:

{"engineeringProfile":"deployment-ownership", ...}

As documented in the acceptance criteria (lines 71‑73), CI pipelines run these same validation steps as release gates, preventing deployment diagrams that violate ownership requirements from reaching production documentation.

Key Implementation Files

The deployment-ownership profile spans multiple files in the tt-a1i/archify repository:

archify/schemas/architecture.schema.json

Defines the engineering_profile enum and overall diagram schema that restricts the field to "deployment-ownership".

docs/deployment-ownership-profile-acceptance-2026-07-23.md

Contains the concrete validation requirements and acceptance criteria, including the six rules enumerated above and CI gate definitions.

archify/renderers/shared/engineering-profiles.mjs

Holds the DEPLOYMENT_PROFILE constant used by the renderer to apply profile-specific validation logic.

archify/recipes/scenarios.mjs

Provides the built-in scenario that prompts users to enable the profile when requesting a deployment review.

Summary

• The deployment-ownership profile requires six strict validation rules: mandatory owner tags, single region assignment, minimum boundary context, database security-group containment, region-isolated security groups, and explicit mechanism labels for crossings.
• Validation is fail-closed: any missing requirement causes immediate validation failure.
• Enable the profile by setting meta.engineering_profile: "deployment-ownership" in your diagram JSON.
• External components are exempt from owner tag and region membership requirements.
• CI pipelines enforce these checks automatically using the schema and acceptance criteria defined in the Archify repository.

Frequently Asked Questions

What happens if my diagram fails the deployment-ownership validation?

Validation fails immediately with an error indicating which requirement was violated. Because the profile is fail-closed, the diagram cannot be rendered or deployed until you fix the issue—such as adding missing owner tags or correcting security-group memberships.

Can I use multiple engineering profiles simultaneously?

According to the schema in architecture.schema.json, the engineering_profile field accepts a single enum value. Currently, only "deployment-ownership" is supported, so you cannot combine multiple profiles in one diagram.

Do databases need exclusive security-groups or can they share with other components?

Databases can share security-groups with other components, provided all members belong to exactly one shared region. However, each database must belong to at least one security-group, and the group cannot span multiple regions.

Are external components exempt from owner tag requirements?

Yes. The validation requirements specifically apply to non-external components. External components—those representing third-party services or systems outside your organization—do not require owner tags or region boundary membership.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}