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

> Learn the requirements for Archify's deployment-ownership engineering profile. Discover six validation rules for owner tags, region, security groups, and connection mechanisms. Ensure diagram compliance.

- Repository: [tt-a1i/archify](https://github.com/tt-a1i/archify)
- Tags: how-to-guide
- Published: 2026-09-04

---

**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`](https://github.com/tt-a1i/archify/blob/main/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`](https://github.com/tt-a1i/archify/blob/main/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:

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

```

According to the schema definition in [`architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/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:

```json
{
  "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:

```bash

# Validate the JSON and check the resolved engineeringProfile

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

```

A successful validation returns the resolved profile:

```json
{"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`](https://github.com/tt-a1i/archify/blob/main/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`](https://github.com/tt-a1i/archify/blob/main/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`](https://github.com/tt-a1i/archify/blob/main/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.