# Archify Deployment‑Ownership Engineering Profile Validation: A Complete Guide

> Master Archify deployment-ownership engineering profile validation. Ensure only fully specified production deployment diagrams reach your gallery with this comprehensive guide. Secure your boundaries now.

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

---

**Archify's `deployment‑ownership` engineering profile enforces strict, fail‑closed validation on ownership, region, and security boundaries—guaranteeing that only fully‑specified production deployment diagrams reach your gallery.**

Archify extends its Architecture diagram type with an optional **`deployment‑ownership`** engineering profile. When enabled, the system performs deterministic validation directly on the authored JSON IR, producing a reproducible proof of production deployment topology without live‑environment discovery. This guide explains how the profile works, how to enable it, and how to interpret validation results.

## How the Deployment‑Ownership Profile Works

The `deployment‑ownership` profile follows a seven‑step validation pipeline. Each step is enforced by specific source files in the `tt‑a1i/archify` repository.

### Step 1: Enable the Profile Explicitly

The user must opt‑in by adding `meta.engineering_profile: "deployment‑ownership"` to the Architecture JSON. Archify only applies this profile when explicitly requested for deployment reviews.

Referencing the [README.md – "deployment‑ownership" profile](https://github.com/tt-a1i/archify/blob/main/README.md#149):

```json
{
  "meta": {
    "engineering_profile": "deployment-ownership"
  },
  "nodes": [
    { "id": "api", "label": "API Server", "owner": "Team-A", "region": "us-east-1" },
    { "id": "db", "label": "PostgreSQL", "owner": "Team-B", "region": "us-east-1", "private": true }
  ],
  "edges": [
    { "source": "api", "target": "db", "label": "SQL" }
  ]
}

```

### Step 2: Schema Validation in [`architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/architecture.schema.json)

The JSON schema at [`archify/schemas/architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/architecture.schema.json) defines the strict enum `["deployment‑ownership"]`. Any other value fails validation immediately.

As implemented in [architecture.schema.json – `engineering_profile` enum](https://github.com/tt-a1i/archify/blob/main/archify/schemas/architecture.schema.json#L22):

- **Line 22**: Schema rejects unknown profile values before engine processing begins
- **Fail‑early behavior**: Invalid profiles never reach the rule engine

### Step 3: Engine‑Level Rule Enforcement in `engineering‑profiles.mjs`

`archify/renderers/shared/engineering‑profiles.mjs` contains the complete rule set for the `deployment‑ownership` profile, stored in the constant `DEPLOYMENT_PROFILE`.

Per [engineering‑profiles.mjs – `DEPLOYMENT_PROFILE`](https://github.com/tt-a1i/archify/blob/main/archify/renderers/shared/engineering-profiles.mjs#L3), the loader validates:

- **Ownership**: Every component has a non‑empty `owner` field
- **Region**: Each component belongs to exactly one `region`
- **Database privacy**: Database nodes must have `private: true`
- **External boundaries**: Non‑external components follow all constraints

### Step 4: Validation Receipt Generation

`archify/test/engineering‑profile.test.mjs` confirms that successful `validate --json` runs include the receipt field `engineeringProfile: "deployment‑ownership"`.

Verified in [engineering‑profile.test.mjs – receipt checks](https://github.com/tt-a1i/archify/blob/main/archify/test/engineering-profile.test.mjs#L179):

```bash
node archify/bin/archify.mjs validate architecture deployment.json --json

```

Expected output:

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

```

### Step 5: Proof Publication with Attributed Artifacts

Validated diagrams publish to the Gallery with the `deployment‑ownership` tag. The SVG root embeds `data‑engineering‑profile="deployment‑ownership"` for programmatic discovery.

Example from [Gallery artifact – SVG attribute](https://github.com/tt-a1i/archify/blob/main/docs/gallery/artifacts/production-deployment.architecture.html#L4912):

```bash
grep -i 'data-engineering-profile' deployment.html

# → <svg … data-engineering-profile="deployment-ownership">

```

### Step 6: Contract Documentation in [`SKILL.md`](https://github.com/tt-a1i/archify/blob/main/SKILL.md)

The formal skill contract at [`archify/SKILL.md`](https://github.com/tt-a1i/archify/blob/main/archify/SKILL.md) states that the profile is **opt‑in and irreversible**: once enabled, it must not be removed, and all failures require structured diagnostics.

Per [SKILL.md – profile opt‑in guidance](https://github.com/tt-a1i/archify/blob/main/archify/SKILL.md#74):

- Profile activation is a one‑way gate
- Validation failures emit machine‑readable `engineerProfile` diagnostics
- No silent degradation: failures abort delivery

### Step 7: Acceptance Criteria Gating

The acceptance document `docs/deployment‑ownership‑profile‑acceptance‑2026‑07‑23.md` lists exact gating rules enforced by the loader.

Detailed in [acceptance doc – gating rules](https://github.com/tt-a1i/archify/blob/main/docs/deployment-ownership-profile-acceptance-2026-07-23.md):

- Rule violations block publication
- Previously‑verified diagrams remain unchanged on failure

## Running Deployment‑Ownership Validation

### Validation Command

```bash
node archify/bin/archify.mjs validate architecture deployment.json --json

```

### Delivery with Profile Enforcement

```bash
node archify/bin/archify.mjs deliver architecture deployment.json ./deployment.html --open --json

```

### Handling Validation Failures

When rules are violated, the command exits with structured diagnostics:

```json
{
  "diagnostics": [
    {
      "code": "E001",
      "subject": "node:db",
      "message": "Database must be private in deployment-ownership profile."
    }
  ]
}

```

**Fail‑closed behavior**: The delivery aborts, leaving the gallery unchanged. No partially‑validated diagrams propagate.

## Key Source Files for Deployment‑Ownership Profile Validation

| File | Purpose |
|------|---------|
| [`archify/schemas/architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/architecture.schema.json) | Defines `engineering_profile` enum; enforces schema constraints |
| `archify/renderers/shared/engineering‑profiles.mjs` | Implements `DEPLOYMENT_PROFILE` rule set (ownership, region, privacy) |
| `archify/test/engineering‑profile.test.mjs` | Automated validation of receipts and SVG attributes |
| [`archify/SKILL.md`](https://github.com/tt-a1i/archify/blob/main/archify/SKILL.md) | Formal contract: opt‑in rules, diagnostic requirements |
| `docs/deployment‑ownership‑profile‑acceptance‑2026‑07‑23.md` | Detailed acceptance criteria and gating rules |
| `docs/gallery/artifacts/production‑deployment.architecture.html` | Example validated artifact with `data‑engineering‑profile` attribute |

## Summary

- **Opt‑in activation**: Add `meta.engineering_profile: "deployment‑ownership"` to enable strict validation
- **Schema enforcement**: [`architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/architecture.schema.json) rejects invalid profile values before engine processing
- **Rule engine**: `engineering‑profiles.mjs` validates ownership, single region, and database privacy
- **Validation receipt**: Successful runs return `engineeringProfile: "deployment‑ownership"` in JSON output
- **Attributed artifacts**: Published SVGs include `data‑engineering-profile="deployment‑ownership"` for discovery
- **Fail‑closed delivery**: Violations abort with structured diagnostics; no partial publications occur

## Frequently Asked Questions

### What happens if a component lacks an `owner` field?

The validator emits a machine‑readable diagnostic with code `engineerProfile` failure and the delivery step aborts. The gallery retains the previously‑verified diagram unchanged. This fail‑closed behavior ensures incomplete specifications never reach production artifacts.

### Can the `deployment‑ownership` profile be disabled after enabling?

No. Per [`archify/SKILL.md`](https://github.com/tt-a1i/archify/blob/main/archify/SKILL.md), the profile is opt‑in and irreversible. Once `meta.engineering_profile: "deployment‑ownership"` is set, removing it violates the skill contract. This design prevents accidental degradation of validated deployment diagrams.

### How do downstream systems discover validated deployment diagrams?

The published HTML/SVG root includes `data-engineering-profile="deployment‑ownership"` as a data attribute. Downstream consumers can query this attribute programmatically, as demonstrated in [`docs/gallery/artifacts/production-deployment.architecture.html`](https://github.com/tt-a1i/archify/blob/main/docs/gallery/artifacts/production-deployment.architecture.html) line 4912.

### Does Archify perform live environment discovery during validation?

No. The `deployment‑ownership` profile validates entirely against the authored JSON IR. No cloud API calls, no runtime discovery—just deterministic proof of the explicitly specified topology. This produces trustworthy, reproducible validation results.