What Is the Deployment‑Ownership Engineering Profile in Archify Architecture Diagrams?

TL;DR: The deployment‑ownership engineering profile is an optional, strict validation contract for Archify Architecture diagrams that enforces ownership tags, regional boundaries, and security‑group containment to ensure clear operational responsibility and trust boundaries.

Architecture diagrams in Archify support an optional engineering profile that activates additional validation rules. The deployment‑ownership profile is specifically designed for teams who need explicit ownership attribution and boundary enforcement in their infrastructure diagrams. When enabled, the validator switches to fail‑closed mode—any violation of the ownership or boundary rules causes immediate rejection.

How to Enable the Deployment‑Ownership Profile

Activate the profile by adding engineering_profile: "deployment‑ownership" to your diagram's meta block:

{
  "schema_version": 1,
  "diagram_type": "architecture",
  "meta": {
    "title": "Production Services",
    "engineering_profile": "deployment-ownership"
  }
}

The profile is defined in archify/schemas/architecture.schema.json (lines 23–24) as a single‑value enum:

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

Only Architecture diagrams (diagram_type: "architecture") may use this profile. Other diagram types ignore the field.

Six Strict Validation Rules

The deployment‑ownership profile enforces six ownership‑ and boundary‑related constraints as documented in docs/deployment-ownership-profile-acceptance-2026-07-23.md (lines 20–23):

Rule	Requirement	Purpose
Owner tags mandatory	Every non‑external component must have a non‑empty tag field	Guarantees each component has a responsible team or person
Single region membership	Each non‑external component belongs to exactly one region boundary	Prevents ambiguous placement across regions
Minimum boundaries	At least one region and one security‑group must exist	Ensures logical placement and security scoping
Database containment	Every database component must reside inside a security‑group	Protects data stores within a private perimeter
Security‑group region consistency	Each security‑group contains members from exactly one shared region	Simplifies trust boundaries by preventing cross‑region groups
Explicit crossing labels	Connections with changing region or security‑group membership require a crossing mechanism label	Documents why a link crosses boundaries (e.g., "VPC route", "cross‑region WAL")

What the Deployment‑Ownership Profile Does Not Do

Understanding the scope limitations prevents misconfiguration:

• No live infrastructure discovery — validation operates solely on the author‑provided JSON IR
• No external inference — owners, regions, and security groups must be explicitly declared
• No rendering changes — the profile adds no new diagram types, visual presets, or product surfaces

When validation passes, the receipt includes engineeringProfile: "deployment‑ownership" and the rendered SVG carries a data‑engineering‑profile="deployment‑ownership" attribute on the root element.

Valid Example: Deployment‑Ownership Diagram

Below is a minimal valid Architecture IR satisfying all deployment‑ownership rules:

{
  "schema_version": 1,
  "diagram_type": "architecture",
  "meta": {
    "title": "Sample Deployment‑Ownership Diagram",
    "engineering_profile": "deployment-ownership"
  },
  "components": [
    {
      "id": "app",
      "type": "frontend",
      "label": "Web App",
      "tag": "frontend-team",
      "region": "us-east-1"
    },
    {
      "id": "db",
      "type": "database",
      "label": "Postgres",
      "tag": "db-team",
      "region": "us-east-1",
      "security-group": "sg‑prod"
    }
  ],
  "boundaries": [
    { "kind": "region", "label": "us-east-1", "wraps": ["app", "db"] },
    { "kind": "security-group", "label": "sg‑prod", "wraps": ["db"] }
  ],
  "connections": [
    { "from": "app", "to": "db", "label": "REST API", "label_at": [200, 150] }
  ]
}

Omitting the tag from app triggers diagnostic family engineering/deployment-owner-missing. Missing the region boundary or empty security-group raises engineering/deployment-region-scope or related families.

Validation Outcomes and Diagnostics

Outcome	Behavior
Pass	Receipt contains engineeringProfile: "deployment‑ownership"; SVG rendered with profile attribute
Fail	Original artifact bytes preserved; diagnostics include specific failure families from the contract proof

Diagnostic families include:

• engineering/deployment-owner-missing
• engineering/deployment-region-scope
• engineering/deployment-security-group-violation
• engineering/deployment-crossing-unlabeled

See docs/deployment-ownership-profile-acceptance-2026-07-23.md for the complete list.

Legacy Behavior Without the Profile

When engineering_profile is omitted or null, diagrams follow legacy v1 behavior with no additional ownership checks. This allows gradual adoption—teams can upgrade diagrams to deployment‑ownership validation when ready without breaking existing artifacts.

Key Source Files

File	Relevance
archify/schemas/architecture.schema.json	Defines engineering_profile enum and Architecture schema structure
docs/deployment-ownership-profile-acceptance-2026-07-23.md	Contract documentation, success criteria, and diagnostic families
archify/SKILL.md	Guidance on when to enable the profile and meta field interactions
README.md, README_EN.md, README_ZH.md	High‑level overview with links to deployment proof in Gallery
CHANGELOG.md	Introduction record and implementation details

Summary

• The deployment‑ownership engineering profile is an optional, strict validation contract for Archify Architecture diagrams
• It enforces six rules covering owner tags, regional boundaries, security‑group containment, and explicit crossing labels
• Enable it via meta.engineering_profile: "deployment‑ownership" in your diagram JSON
• Validation operates in fail‑closed mode—violations produce specific diagnostic families and prevent diagram acceptance
• The profile adds no runtime infrastructure checks or rendering changes—validation is purely against the declared JSON IR

Frequently Asked Questions

Can I use the deployment‑ownership profile on non‑architecture diagrams?

No. The profile is restricted to diagram_type: "architecture" as enforced by archify/schemas/architecture.schema.json. Other diagram types ignore the engineering_profile field entirely.

What happens if validation fails?

The original artifact bytes are preserved unchanged. The validation response includes diagnostic families (such as engineering/deployment-owner-missing) that identify specific rule violations. You must fix the JSON IR and resubmit.

Does enabling deployment‑ownership change how my diagram looks?

No visual changes occur unless you explicitly modify the SVG output. The only rendering difference is a data‑engineering‑profile="deployment‑ownership" attribute added to the SVG root element, which you can remove if desired.

Can the profile infer owners or regions from my cloud provider?

No. The deployment‑ownership profile does not discover or verify live infrastructure, nor does it infer any values from external sources. All owners, regions, and security groups must be explicitly declared in the JSON IR.

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