# How to Configure the Deployment‑Ownership Engineering Profile for Architecture Reviews

> Learn to configure the deployment-ownership engineering profile in Archify for architecture reviews. Enforce strict ownership and boundary rules effortlessly.

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

---

**The `deployment-ownership` engineering profile is an optional, fail‑closed mode in Archify that enforces strict ownership and boundary rules when a reviewer explicitly requests a production‑deployment review.**

The `deployment-ownership` engineering profile provides a strict validation layer for the `tt-a1i/archify` architecture-as-code framework. When activated, it ensures every component carries defined ownership tags, region boundaries, and security group scoping before deployment. This profile is documented in the acceptance contract at [`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) and activates six specific validation rules that fail closed if any requirement is violated.

## Enabling the Profile in Your Architecture Definition

To activate the profile, add the `meta.engineering_profile` key to your architecture JSON. According to the acceptance notes 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) lines 14-16, the configuration requires setting the value explicitly to `"deployment-ownership"`.

```json
{
  "meta": {
    "engineering_profile": "deployment-ownership"
  },
  "components": [
    {
      "id": "svc-api",
      "type": "service",
      "tag": "team-api",
      "region": "us-east-1"
    }
  ]
}

```

This single configuration change switches the validator from standard mode to the ownership-aware, fail‑closed path. Inputs that omit this key continue using existing validation and rendering paths, ensuring backward compatibility for legacy diagrams.

## When to Activate Fail‑Closed Validation

The `deployment-ownership` profile must be enabled **only** when the user explicitly asks for a deployment or ownership review. As specified in [`archify/SKILL.md`](https://github.com/tt-a1i/archify/blob/main/archify/SKILL.md) lines 88-90, the profile is not inferred from security‑boundary information. You should enable it specifically when handling:

- Production deployment topology reviews
- Ownership handoff ceremonies
- Fail‑closed deployment safety checks

Do not enable this profile automatically based on component metadata; the policy requires explicit user intent to trigger the strict validation suite.

## The Six Ownership Validation Rules

Once enabled, Archify validates the authored IR (intermediate representation) against six specific constraints 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) lines 20-27. The validation fails closed unless all conditions are met.

- **Owner tag requirement**: Every non‑external component must have a non‑empty `tag` owner.
- **Region boundary**: Each non‑external component belongs to exactly one `region` boundary.
- **Boundary existence**: The architecture must define at least one `region` and one `security‑group` boundary.
- **Database scope**: Every `database` component must belong to a `security‑group`.
- **Shared region constraint**: Each security group contains members from exactly one shared region.
- **Cross‑membership labeling**: Any connection that changes region or security‑group membership must carry a non‑empty mechanism label.

These rules ensure that ownership is explicit, boundaries are strict, and cross‑boundary traffic is documented before deployment.

## Running Validation and Delivery Commands

Execute the standard Archify CLI commands to verify compliance and generate receipts. The `--json` flag emits machine‑readable output that includes the active engineering profile.

```bash
archify validate --json architecture.json

```

A successful validation returns a receipt containing `engineeringProfile: "deployment-ownership"` as 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) lines 33-35.

```json
{
  "status": "pass",
  "engineeringProfile": "deployment-ownership",
  "diagnostics": []
}

```

To finalize the review and emit the deployment receipt, run:

```bash
archify deliver --json architecture.json

```

## Handling Validation Failures

If any of the six ownership rules are violated, the validation returns a `fail` status and includes stable diagnostic families in the `diagnostics` array. The acceptance document lines 42-50 define specific error codes such as `engineering/deployment-owner-missing` and `engineering/deployment-region-scope`.

```json
{
  "status": "fail",
  "engineeringProfile": "deployment-ownership",
  "diagnostics": [
    {
      "code": "engineering/deployment-owner-missing",
      "message": "Component 'svc-worker' lacks an owner tag"
    }
  ]
}

```

These diagnostic codes remain stable across versions, allowing CI/CD pipelines to gate deployments based on specific ownership violations.

## Summary

- The `deployment-ownership` engineering profile activates via `"meta": { "engineering_profile": "deployment-ownership" }` in your architecture JSON.
- Enable the profile only upon explicit request for production deployment or ownership handoff reviews, as mandated by [`archify/SKILL.md`](https://github.com/tt-a1i/archify/blob/main/archify/SKILL.md).
- The profile enforces six strict rules covering owner tags, region boundaries, security groups, and cross‑membership labeling.
- Validation uses `archify validate --json` and reports `engineeringProfile: "deployment-ownership"` in the receipt when active.
- Failures return stable diagnostic codes like `engineering/deployment-owner-missing`, preventing deployment until resolved.

## Frequently Asked Questions

### What is the deployment‑ownership engineering profile?

The deployment‑ownership engineering profile is a strict, opt‑in validation mode in Archify that enforces ownership and boundary rules on architecture definitions. According to the schema definitions in [`archify/schemas/README.md`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/README.md), it represents the first engineering profile designed for fail‑closed deployment reviews where every component must have explicit ownership and regional scope.

### When should I enable the deployment‑ownership profile?

You should enable the profile only when explicitly requested for production deployment topology reviews, ownership handoffs, or fail‑closed safety checks. As documented in [`archify/SKILL.md`](https://github.com/tt-a1i/archify/blob/main/archify/SKILL.md) lines 88-90, the system does not infer this mode from security boundaries; it requires explicit user intent to activate the strict validation suite.

### What diagnostics appear when validation fails?

Failed validations return specific diagnostic families such as `engineering/deployment-owner-missing`, `engineering/deployment-region-scope`, and `engineering/deployment-boundary-violation`. These codes appear in the JSON receipt's `diagnostics` array and remain stable across versions, as specified 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) lines 42-50.

### Does enabling the profile change rendering or diagram output?

No. Enabling the `deployment-ownership` profile does not introduce new renderers, diagram types, or UI changes. The profile affects only the validation layer and the emitted receipt. Legacy diagrams and existing rendering paths remain fully compatible, ensuring that adding the profile meta‑key does not alter visual outputs.