# Deploying with the `deployment-ownership` Engineering Profile in Archify: 6 Strict Requirements Explained

> Understand the 6 strict requirements of Archify's deployment-ownership engineering profile for ownership, regional placement, and security. Ensure your deployments pass validation.

- Repository: [tt-a1i/archify](https://github.com/tt-a1i/archify)
- Tags: deep-dive
- Published: 2026-08-29

---

**The `deployment-ownership` engineering profile in Archify enforces six mandatory rules for ownership, regional placement, and security boundaries—any violation fails validation immediately.**

This optional, fail-closed mode is designed for architectures that require explicit deployment accountability. When you set `"engineering_profile": "deployment-ownership"` in your diagram's metadata, the validator switches from permissive to strict, ensuring every non-external component has clear ownership and topology placement. The profile is implemented in `tt-a1i/archify` and applies to the authored intermediate representation only—no live infrastructure verification occurs.

## How to Enable the Profile

Activation requires explicit metadata configuration. In your [`architecture.json`](https://github.com/tt-a1i/archify/blob/main/architecture.json) file, set the `engineering_profile` field under `meta`:

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

```

This value is defined in [[`archify/schemas/architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/architecture.schema.json)](https://github.com/tt-a1i/archify/blob/main/archify/schemas/architecture.schema.json#L23) as part of the `engineering_profile` enum. Without this explicit setting, the profile remains disabled and standard validation applies.

## The 6 Mandatory `deployment-ownership` Requirements

All six conditions must pass; the validator fails closed on any violation. Each requirement generates a specific diagnostic code for precise error identification.

### 1. Owner Tag Requirement

Every **non-external component** must declare a non-empty `tag` field naming its owner.

- **Purpose**: Guarantees explicit ownership assignment
- **Failure diagnostic**: `engineering/deployment-owner-missing`

```json
// ✅ Valid
{ "id": "api", "type": "backend", "label": "API", "tag": "backend-team", "region": "us-east-1" }

// ❌ Invalid — missing "tag" triggers engineering/deployment-owner-missing
{ "id": "cache", "type": "backend", "label": "Cache", "region": "us-east-1" }

```

### 2. Single Region Assignment

Each non-external component must belong to **exactly one** `region` boundary.

- **Purpose**: Prevents ambiguous or missing regional placement
- **Failure diagnostic**: `engineering/deployment-region-scope`

### 3. Required Boundary Existence

The diagram must contain **at least one** `region` boundary **and** **at least one** `security-group` boundary.

- **Purpose**: Ensures mandatory topology scaffolding is present
- **Failure diagnostic**: `engineering/deployment-boundary-missing`

### 4. Database Security-Group Placement

Every component of type `database` must be placed inside a `security-group` boundary.

- **Purpose**: Enforces security domain scoping for data stores
- **Failure diagnostic**: `engineering/deployment-database-security`

```json
// ✅ Valid database placement
{ "id": "db", "type": "database", "label": "Postgres", "tag": "dba-team", "region": "us-east-1", "security-group": "sg-1" }

```

### 5. Security-Group Region Consistency

A `security-group` may contain members **only from a single shared region**.

- **Purpose**: Prevents security groups from spanning multiple regions
- **Failure diagnostic**: `engineering/deployment-security-region-mismatch`

### 6. Cross-Boundary Connection Labels

Any connection that changes **region** or **security-group** membership must carry a non-empty `label` describing the crossing mechanism.

- **Purpose**: Makes every boundary crossing explicit and auditable
- **Allowed labels**: Descriptions like "VPC route", "cross-region WAL", " peering connection"
- **Failure diagnostic**: `engineering/deployment-crossing-unlabeled`

## Complete Valid Example

This [`production-deployment.architecture.json`](https://github.com/tt-a1i/archify/blob/main/production-deployment.architecture.json) satisfies all requirements and passes the nine artifact checks referenced in the acceptance documentation:

```json
{
  "schema_version": 1,
  "diagram_type": "architecture",
  "meta": {
    "title": "Production Deployment",
    "engineering_profile": "deployment-ownership"
  },
  "components": [
    { "id": "app", "type": "frontend", "label": "Web App", "tag": "frontend-team", "region": "us-east-1" },
    { "id": "api", "type": "backend", "label": "API", "tag": "backend-team", "region": "us-east-1" },
    { "id": "db", "type": "database", "label": "Postgres", "tag": "dba-team", "region": "us-east-1", "security-group": "sg-1" }
  ],
  "boundaries": [
    { "kind": "region", "label": "us-east-1", "wraps": ["app", "api", "db"] },
    { "kind": "security-group", "label": "sg-1", "wraps": ["db"] }
  ],
  "connections": [
    { "from": "app", "to": "api", "label": "HTTPS" },
    { "from": "api", "to": "db", "label": "JDBC", "label": "cross-region WAL" }
  ]
}

```

## Running Validation

Validate your architecture file using the bundled CLI:

```bash
npx archify validate --json production-deployment.architecture.json

```

Successful validation reports `engineeringProfile: "deployment-ownership"` in both `validate` and `deliver` command outputs.

## Source Implementation Details

The `deployment-ownership` requirements are codified across these key files in `tt-a1i/archify`:

| File | Purpose |
|:---|:---|
| [`archify/schemas/architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/architecture.schema.json) | Defines the `engineering_profile` enum and JSON schema constraints |
| [`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) | Documents the six requirements and acceptance criteria (lines 20-27) |
| [`archify/SKILL.md`](https://github.com/tt-a1i/archify/blob/main/archify/SKILL.md) | Explains when to omit the profile by default and activation procedures |
| `archify/test/engineering-profile.test.mjs` | Automated tests verifying each requirement and diagnostic |
| [`docs/gallery/manifest.json`](https://github.com/tt-a1i/archify/blob/main/docs/gallery/manifest.json) | Gallery entry confirming production artifact availability |

## Summary

- **Activation**: Set `"engineering_profile": "deployment-ownership"` in `meta` to enable fail-closed validation
- **Six mandatory rules**: Owner tags, single regions, required boundaries, database security-group placement, security-group region consistency, and labeled cross-boundary connections
- **Failure mode**: Any violation generates a specific diagnostic and blocks validation—no partial passes
- **Scope**: Validates authored IR only; does not verify live infrastructure
- **Testing**: Run `npx archify validate` to check compliance; tests are in `engineering-profile.test.mjs`

## Frequently Asked Questions

### What happens if I forget to add a `tag` to one component?

The validator emits `engineering/deployment-owner-missing` and the entire diagram fails validation. The `deployment-ownership` profile is fail-closed—any single violation prevents passing.

### Can a security group contain components from multiple regions?

No. Requirement 5 explicitly forbids this. If violated, you receive `engineering/deployment-security-region-mismatch`. Each security group must be scoped to components sharing a single region.

### Does passing this profile guarantee my infrastructure is correctly deployed?

No. As documented in [`archify/SKILL.md`](https://github.com/tt-a1i/archify/blob/main/archify/SKILL.md) and the acceptance criteria, the profile validates only the **authored intermediate representation** (the JSON diagram file). Live infrastructure verification requires separate operational tools.

### When should I use the `deployment-ownership` profile versus leaving it disabled?

Enable it for deployment reviews, ownership audits, or production architecture sign-offs where explicit accountability is required. Omit it during early design iteration or for non-critical diagrams to avoid strict validation overhead.