How to Define and Understand Engineering Profiles (Deployment-Ownership) in Archify

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.

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).

Enabling the Deployment-Ownership Profile

Add the profile to your diagram's meta object:

{
  "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 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), 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:

archify validate --json production-deployment.architecture.json

A passing profile validation produces this receipt structure:

{
  "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 <svg> element:

<svg
  xmlns="http://www.w3.org/2000/svg"
  data-diagram-type="architecture"
  data-engineering-profile="deployment-ownership"
  data-validated-at="2026-07-23T14:32:01Z"
>
  <!-- diagram content -->
</svg>

This appears in published artifacts like 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 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 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 Acceptance criteria documenting profile behavior
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 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.

Have a question about this repo?

These articles cover the highlights, but your codebase questions are specific. Give your agent direct access to the source. Share this with your agent to get started:

Share the following with your agent to get started:
curl -s "https://instagit.com/install.md"

Works with
Claude Codex Cursor VS Code OpenClaw Any MCP Client

Maintain an open-source project? Get it listed too →