# What Is the Deployment-Ownership Engineering Profile in Archify?

> Learn about the deployment-ownership engineering profile in Archify. This fail-closed validation mode enforces strict ownership, region placement, and security rules for diagram rendering.

- Repository: [tt-a1i/archify](https://github.com/tt-a1i/archify)
- Tags: architecture
- Published: 2026-08-30

---

**The `deployment-ownership` engineering profile in Archify is an opt-in, fail-closed validation mode that enforces strict ownership, region placement, and security-boundary rules before a diagram can be rendered.**

The `deployment-ownership` engineering profile is an optional feature in the `tt-a1i/archify` repository designed for teams conducting production-deployment reviews. When enabled via the `meta.engineering_profile` field, it activates a validation layer that checks structural constraints against authored facts rather than live cloud infrastructure.

## Core Validation Constraints

When the profile is active, Archify enters a fail-closed state that validates the following ownership and topology rules. If any constraint is violated, the diagram fails validation and the receipt reports the `deployment-ownership` profile as failed.

### Component Ownership Requirements

Every non-external component must declare an explicit `owner` field. The loader inspects each component object to ensure accountability is assigned before the diagram can proceed to rendering.

### Region and Security Group Boundaries

Each workload must belong to **exactly one** region. Additionally, regions and security-group boundaries must be explicitly defined and strictly respected throughout the architecture. This prevents ambiguous deployment topologies that could lead to misconfigured production environments.

### Database Privacy Constraints

All database components must be marked as `private: true` and must reside within a single shared region. This ensures sensitive data stores are not inadvertently exposed or distributed across insecure boundaries.

### Cross-Boundary Connection Labeling

Any connection that changes region or security-group membership must include a `crossing` field labeling the real mechanism used (e.g., `"VPN"`, `"gateway"`, `"VPC-peering"`). Unlabeled traversals across boundaries trigger validation failures.

## Implementation in the Archify Renderer

The validation logic resides in `archify/renderers/architecture/render-architecture.mjs`. At line 342, the renderer checks the diagram’s metadata to determine if ownership constraints should be applied:

```javascript
// Conceptual check at line 342 of render-architecture.mjs
if (diagram.meta.engineering_profile === 'deployment-ownership') {
  // Execute ownership and topology validation
  validateOwnershipConstraints(diagram);
}

```

The schema definition in [`archify/schemas/architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/architecture.schema.json) (lines 23-24) restricts the `engineering_profile` field to a specific enum, formally allowing the value `"deployment-ownership"`:

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

```

## Enabling the Profile in Your Diagram

To activate the profile, set the `engineering_profile` field within the diagram’s `meta` object. The repository provides a concrete example in [`archify/examples/production-deployment.architecture.json`](https://github.com/tt-a1i/archify/blob/main/archify/examples/production-deployment.architecture.json) at line 10:

```json
{
  "meta": {
    "engineering_profile": "deployment-ownership"
  },
  "components": [
    {
      "id": "api",
      "owner": "TeamA",
      "region": "us-east-1",
      "type": "service"
    },
    {
      "id": "db",
      "owner": "TeamA",
      "region": "us-east-1",
      "private": true,
      "type": "database"
    }
  ],
  "connections": [
    {
      "from": "api",
      "to": "db",
      "crossing": "private-link"
    }
  ]
}

```

## Validation Output and Receipts

When all constraints are satisfied, the validation receipt includes the profile identifier:

```json
{
  "engineeringProfile": "deployment-ownership",
  "status": "passed"
}

```

If validation fails due to missing owners, unlabeled cross-boundary connections, or region violations, the receipt marks the profile as failed and lists the specific constraint violations. This behavior is documented in the repository’s [`README.md`](https://github.com/tt-a1i/archify/blob/main/README.md) (lines 148-150), which explains the profile’s purpose and its strict, fail-closed nature.

## Summary

- The **deployment-ownership engineering profile** is an optional, opt-in validation mode in Archify that is **never enabled by default**.
- It enforces **five strict constraints**: component ownership, single-region placement, security-group boundaries, private database marking, and labeled cross-boundary connections.
- Validation is implemented in `render-architecture.mjs` and defined in the JSON schema at [`architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/architecture.schema.json).
- The profile validates **only authored diagram facts**, not live cloud infrastructure.
- Activation requires explicitly setting `meta.engineering_profile` to `"deployment-ownership"` in your architecture JSON.

## Frequently Asked Questions

### How do I enable the deployment-ownership profile in Archify?

You must explicitly set the `engineering_profile` field to `"deployment-ownership"` in your diagram’s `meta` object. As shown in [`archify/examples/production-deployment.architecture.json`](https://github.com/tt-a1i/archify/blob/main/archify/examples/production-deployment.architecture.json), this is an opt-in configuration that Archify does not infer automatically from security boundaries.

### Does the profile check actual cloud resources during validation?

No. According to the source documentation, the profile validates only the facts authored directly in the diagram JSON. It does not inspect live cloud infrastructure or query existing deployments, functioning purely as a structural linter for your architecture documentation.

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

The diagram will not render, and the validation receipt will report the `deployment-ownership` profile status as failed. The receipt includes specific details about which constraints were violated, such as missing owner fields or unlabeled cross-region connections, allowing you to correct the issues before retrying.