What Is the Deployment-Ownership Engineering Profile in Archify?

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:

// 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 (lines 23-24) restricts the engineering_profile field to a specific enum, formally allowing the value "deployment-ownership":

{
  "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 at line 10:

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

{
  "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 (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.
• 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, 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}