# What Is the Deployment‑Ownership Engineering Profile in Archify Architecture Diagrams?

> Understand the deployment-ownership engineering profile in Archify architecture diagrams. Enforce ownership, regional boundaries, and security for clear operational responsibility and trust.

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

---

**TL;DR:** The `deployment‑ownership` engineering profile is an optional, strict validation contract for Archify Architecture diagrams that enforces ownership tags, regional boundaries, and security‑group containment to ensure clear operational responsibility and trust boundaries.

Architecture diagrams in Archify support an optional **engineering profile** that activates additional validation rules. The `deployment‑ownership` profile is specifically designed for teams who need explicit ownership attribution and boundary enforcement in their infrastructure diagrams. When enabled, the validator switches to **fail‑closed mode**—any violation of the ownership or boundary rules causes immediate rejection.

## How to Enable the Deployment‑Ownership Profile

Activate the profile by adding `engineering_profile: "deployment‑ownership"` to your diagram's `meta` block:

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

```

The profile is defined in [`archify/schemas/architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/architecture.schema.json) (lines 23–24) as a single‑value enum:

```json
"engineering_profile": { "enum": ["deployment-ownership"] }

```

Only Architecture diagrams (`diagram_type: "architecture"`) may use this profile. Other diagram types ignore the field.

## Six Strict Validation Rules

The `deployment‑ownership` profile enforces six ownership‑ and boundary‑related constraints 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 20–23):

| **Rule** | **Requirement** | **Purpose** |
|----------|-----------------|-------------|
| **Owner tags mandatory** | Every non‑external component must have a non‑empty `tag` field | Guarantees each component has a responsible team or person |
| **Single region membership** | Each non‑external component belongs to exactly one `region` boundary | Prevents ambiguous placement across regions |
| **Minimum boundaries** | At least one `region` and one `security‑group` must exist | Ensures logical placement and security scoping |
| **Database containment** | Every `database` component must reside inside a `security‑group` | Protects data stores within a private perimeter |
| **Security‑group region consistency** | Each `security‑group` contains members from exactly one shared region | Simplifies trust boundaries by preventing cross‑region groups |
| **Explicit crossing labels** | Connections with changing region or security‑group membership require a crossing mechanism label | Documents why a link crosses boundaries (e.g., "VPC route", "cross‑region WAL") |

## What the Deployment‑Ownership Profile Does Not Do

Understanding the scope limitations prevents misconfiguration:

- **No live infrastructure discovery** — validation operates solely on the author‑provided JSON IR
- **No external inference** — owners, regions, and security groups must be explicitly declared
- **No rendering changes** — the profile adds no new diagram types, visual presets, or product surfaces

When validation passes, the receipt includes `engineeringProfile: "deployment‑ownership"` and the rendered SVG carries a `data‑engineering‑profile="deployment‑ownership"` attribute on the root element.

## Valid Example: Deployment‑Ownership Diagram

Below is a minimal valid Architecture IR satisfying all `deployment‑ownership` rules:

```json
{
  "schema_version": 1,
  "diagram_type": "architecture",
  "meta": {
    "title": "Sample Deployment‑Ownership Diagram",
    "engineering_profile": "deployment-ownership"
  },
  "components": [
    {
      "id": "app",
      "type": "frontend",
      "label": "Web App",
      "tag": "frontend-team",
      "region": "us-east-1"
    },
    {
      "id": "db",
      "type": "database",
      "label": "Postgres",
      "tag": "db-team",
      "region": "us-east-1",
      "security-group": "sg‑prod"
    }
  ],
  "boundaries": [
    { "kind": "region", "label": "us-east-1", "wraps": ["app", "db"] },
    { "kind": "security-group", "label": "sg‑prod", "wraps": ["db"] }
  ],
  "connections": [
    { "from": "app", "to": "db", "label": "REST API", "label_at": [200, 150] }
  ]
}

```

Omitting the `tag` from `app` triggers diagnostic family `engineering/deployment-owner-missing`. Missing the `region` boundary or empty `security-group` raises `engineering/deployment-region-scope` or related families.

## Validation Outcomes and Diagnostics

| **Outcome** | **Behavior** |
|-------------|--------------|
| **Pass** | Receipt contains `engineeringProfile: "deployment‑ownership"`; SVG rendered with profile attribute |
| **Fail** | Original artifact bytes preserved; diagnostics include specific failure families from the contract proof |

Diagnostic families include:

- `engineering/deployment-owner-missing`
- `engineering/deployment-region-scope`
- `engineering/deployment-security-group-violation`
- `engineering/deployment-crossing-unlabeled`

See [`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) for the complete list.

## Legacy Behavior Without the Profile

When `engineering_profile` is omitted or null, diagrams follow **legacy v1 behavior** with no additional ownership checks. This allows gradual adoption—teams can upgrade diagrams to `deployment‑ownership` validation when ready without breaking existing artifacts.

## Key Source Files

| **File** | **Relevance** |
|----------|---------------|
| [`archify/schemas/architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/architecture.schema.json) | Defines `engineering_profile` enum and Architecture schema structure |
| [`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) | Contract documentation, success criteria, and diagnostic families |
| [`archify/SKILL.md`](https://github.com/tt-a1i/archify/blob/main/archify/SKILL.md) | Guidance on when to enable the profile and meta field interactions |
| [`README.md`](https://github.com/tt-a1i/archify/blob/main/README.md), [`README_EN.md`](https://github.com/tt-a1i/archify/blob/main/README_EN.md), [`README_ZH.md`](https://github.com/tt-a1i/archify/blob/main/README_ZH.md) | High‑level overview with links to deployment proof in Gallery |
| [`CHANGELOG.md`](https://github.com/tt-a1i/archify/blob/main/CHANGELOG.md) | Introduction record and implementation details |

## Summary

- The `deployment‑ownership` engineering profile is an **optional, strict validation contract** for Archify Architecture diagrams
- It enforces **six rules** covering owner tags, regional boundaries, security‑group containment, and explicit crossing labels
- Enable it via `meta.engineering_profile: "deployment‑ownership"` in your diagram JSON
- Validation operates in **fail‑closed mode**—violations produce specific diagnostic families and prevent diagram acceptance
- The profile adds **no runtime infrastructure checks** or rendering changes—validation is purely against the declared JSON IR

## Frequently Asked Questions

### Can I use the deployment‑ownership profile on non‑architecture diagrams?

No. The profile is restricted to `diagram_type: "architecture"` as enforced by [`archify/schemas/architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/architecture.schema.json). Other diagram types ignore the `engineering_profile` field entirely.

### What happens if validation fails?

The original artifact bytes are preserved unchanged. The validation response includes diagnostic families (such as `engineering/deployment-owner-missing`) that identify specific rule violations. You must fix the JSON IR and resubmit.

### Does enabling deployment‑ownership change how my diagram looks?

No visual changes occur unless you explicitly modify the SVG output. The only rendering difference is a `data‑engineering‑profile="deployment‑ownership"` attribute added to the SVG root element, which you can remove if desired.

### Can the profile infer owners or regions from my cloud provider?

No. The `deployment‑ownership` profile does not discover or verify live infrastructure, nor does it infer any values from external sources. All owners, regions, and security groups must be explicitly declared in the JSON IR.