# How to Define and Understand Engineering Profiles (Deployment-Ownership) in Archify > Learn how to define and understand Archify engineering profiles like deployment-ownership. Enforce constraints and ensure explicit owner assignment and security controls for your architecture diagrams. - Repository: [tt-a1i/archify](https://github.com/tt-a1i/archify) - Tags: how-to-guide - Published: 2026-08-15 --- **Archify engineering profiles** are optional, schema-validated extensions that enforce strict engineering-truth constraints on Architecture diagrams, with `deployment-ownership` being the only available profile that mandates explicit owner assignment, region boundaries, and security controls. The `deployment-ownership` engineering profile transforms Archify from a free-form diagramming tool into a **deployment review gate**. When enabled, it validates that your architecture documentation matches operational reality—who owns what, where workloads run, and how security boundaries are crossed. This profile is implemented in `archify/renderers/shared/engineering-profiles.mjs` and defined in the Architecture schema at [`archify/schemas/architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/architecture.schema.json). ## What Are Engineering Profiles in Archify? An **engineering profile** is a metadata-driven validation mode activated through the `meta.engineering_profile` field in Architecture diagram files. Profiles are **opt-in only**—when absent, Archify skips additional constraints and allows flexible diagrams without ownership or regional requirements. The profile system serves two purposes: - **Contract enforcement**: Guarantees that diagrams contain sufficient information for deployment review - **Machine-readable certification**: Embeds validation results in both JSON receipts and generated SVG artifacts Currently, the Architecture schema restricts `engineering_profile` to a single enum value: `"deployment-ownership"` ([architecture.schema.json#L22](https://github.com/tt-a1i/archify/blob/main/archify/schemas/architecture.schema.json#L22)). ## Enabling the Deployment-Ownership Profile Add the profile to your diagram's `meta` object: ```json { "meta": { "title": "Production Deployment", "engineering_profile": "deployment-ownership" }, "components": [ { "id": "api-gateway", "type": "service", "owner": "platform-team" } ] } ``` The constant `DEPLOYMENT_PROFILE = 'deployment-ownership'` at [engineering-profiles.mjs#L3](https://github.com/tt-a1i/archify/blob/main/archify/renderers/shared/engineering-profiles.mjs#L3) validates this value before applying profile-specific checks. ## Validation Rules Enforced by Deployment-Ownership When the renderer detects `engineering_profile: "deployment-ownership"` ([engineering-profiles.mjs#L150](https://github.com/tt-a1i/archify/blob/main/archify/renderers/shared/engineering-profiles.mjs#L150)), it activates five strict constraints: | Rule | Requirement | Failure Mode | |------|-------------|--------------| | **Owner assignment** | Every non-external component must have an explicit `owner` | Validation error with component location | | **Single region** | Each workload belongs to exactly one region | Diagnostic flagging multi-region workloads | | **Boundary declaration** | Region and security-group boundaries must be explicitly declared | Missing boundary error | | **Database privacy** | All databases must be `private` and inside a shared region | Privacy violation diagnostic | | **Crossing mechanisms** | Any region or security-group crossing must specify a **real crossing mechanism** | Unlabeled crossing error | These rules ensure that a `deployment-ownership` diagram can serve as a **source of truth** for incident response, cost allocation, and compliance auditing. ## Validation Output and Receipts Run validation with JSON output to capture profile certification: ```bash archify validate --json production-deployment.architecture.json ``` A passing profile validation produces this receipt structure: ```json { "engineeringProfile": "deployment-ownership", "diagnostics": [], "valid": true } ``` The `engineeringProfile` field appears in both `validate --json` and `deliver --json` outputs, creating an auditable trail that the diagram met deployment-ownership standards at validation time. ## SVG Artifact Embedding The generated SVG carries machine-readable proof of profile compliance. The `data-engineering-profile` attribute appears in the root `` element: ```html ``` This appears in published artifacts like [production-deployment.architecture.html#L4547](https://github.com/tt-a1i/archify/blob/main/docs/gallery/artifacts/production-deployment.architecture.html#L4547), allowing automated systems to verify diagram integrity without re-running Archify. ## File-by-File Implementation Reference | File Path | Purpose | |-----------|---------| | [`archify/schemas/architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/architecture.schema.json) | Defines `engineering_profile` enum; single allowed value `"deployment-ownership"` | | `archify/renderers/shared/engineering-profiles.mjs` | Core renderer implementing profile validation logic; constant definition at line 3, activation check at line 150 | | [`archify/examples/production-deployment.architecture.json`](https://github.com/tt-a1i/archify/blob/main/archify/examples/production-deployment.architecture.json) | Working example with profile enabled in `meta.engineering_profile` | | `archify/test/engineering-profile.test.mjs` | Test suite covering validation, receipt generation, and error diagnostics | | [`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) | Acceptance criteria documenting profile behavior | | [`docs/gallery/artifacts/production-deployment.architecture.html`](https://github.com/tt-a1i/archify/blob/main/docs/gallery/artifacts/production-deployment.architecture.html) | Published proof-of-concept showing embedded SVG attribute | ## When to Use Deployment-Ownership vs. Default Mode **Use `deployment-ownership`** when: - Diagrams feed into production deployment reviews - You need audit trails for compliance (SOC 2, ISO 27001) - Teams require explicit ownership for incident response - Cost allocation by owner and region is mandatory **Use default mode** (no profile) when: - Exploring architectures in early design phases - Drafting diagrams where ownership is not yet assigned - Creating educational or illustrative diagrams - Rapid prototyping without operational constraints ## Summary - **Engineering profiles** are schema-validated extensions that tighten Archify's Architecture diagram semantics - **`deployment-ownership`** is the sole available profile, enforcing owner assignment, regional boundaries, and security controls - Enable via `meta.engineering_profile: "deployment-ownership"` in your diagram JSON - Validation outputs include machine-readable receipts (`engineeringProfile` field) and SVG attributes (`data-engineering-profile`) - The renderer checks profile match at `engineering-profiles.mjs` line 150 before applying constraints - Profile compliance creates auditable proof for deployment reviews and compliance workflows ## Frequently Asked Questions ### What happens if I omit the engineering_profile field? Archify operates in default mode with no additional constraints. Diagrams validate successfully without owners, regions, or crossing mechanisms specified. This is suitable for exploration and drafting phases. ### Can I define custom engineering profiles beyond deployment-ownership? No. The Architecture schema at [`architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/architecture.schema.json) restricts `engineering_profile` to a single enum value. Extending profiles requires schema modification and renderer updates in `engineering-profiles.mjs`. ### How do I verify that my diagram passed deployment-ownership validation? Run `archify validate --json` and check for `engineeringProfile: "deployment-ownership"` in the output. The generated SVG also contains `data-engineering-profile="deployment-ownership"` in its root element. Test assertions in `engineering-profile.test.mjs` demonstrate both verification methods. ### Does deployment-ownership affect diagram rendering visually? The profile does not alter visual styling directly. However, validation errors may prevent SVG generation entirely. The profile attribute appears in the SVG markup for machine verification, not for human display.