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-ownershipis 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 (
engineeringProfilefield) and SVG attributes (data-engineering-profile) - The renderer checks profile match at
engineering-profiles.mjsline 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:
curl -s "https://instagit.com/install.md" Maintain an open-source project? Get it listed too →