How Component Types Are Defined in Archify's Schema

Archify defines component types as a centralized JSON Schema enumeration in common.schema.json, which is referenced across all diagram schemas via $ref pointers.

All component classifications in Archify originate from a single source of truth. The componentType definition lives in archify/schemas/common.schema.json and acts as the canonical taxonomy for every diagram type in the system. This design ensures consistency whether you're modeling workflows, sequence diagrams, or data flows.

The Central Definition in common.schema.json

The componentType enum is declared at lines 39–41 in archify/schemas/common.schema.json. Rather than duplicating type definitions in each diagram schema, Archify uses JSON Schema's $ref mechanism to import this enumeration wherever needed.

The seven valid componentType values are:

• frontend — UI or client-side code
• backend — Server-side application logic
• database — Persistent data stores
• cloud — Cloud services or infrastructure
• security — Security and authentication components
• messagebus — Messaging or event-bus systems
• external — Third-party or external services

How Diagram Schemas Reference componentType

Archify's diagram schemas import the central definition using standard JSON Schema references. This eliminates drift between diagram types and guarantees that validation rules remain synchronized.

The reference pattern used across all schemas is:

"$ref": "common.schema.json#/$defs/componentType"

Workflow Schema Usage

In archify/schemas/workflow.schema.json, the type field on workflow nodes points to the shared enumeration:

// Example of a workflow node using a component type
{
  "id": "login-service",
  "lane": "backend-lane",
  "col": 2,
  "type": "backend",
  "label": "Login Service"
}

Dataflow Schema Usage

The same reference appears in archify/schemas/dataflow.schema.json for node typing:

// Example of a dataflow node using a component type
{
  "id": "user-db",
  "type": "database",
  "label": "User Database"
}

Sequence Schema Usage

In archify/schemas/sequence.schema.json, component definitions also leverage the central type system:

// Example of a component definition in a sequence diagram
{
  "id": "api-gateway",
  "type": "frontend",
  "label": "API Gateway"
}

Key Schema Files

File	Purpose
archify/schemas/common.schema.json	Central shared definitions, including componentType
archify/schemas/workflow.schema.json	Workflow diagram schema with node type field
archify/schemas/sequence.schema.json	Sequence diagram schema with component definitions
archify/schemas/dataflow.schema.json	Dataflow diagram schema with node type field

Summary

• Component types in Archify are defined once in common.schema.json as a JSON Schema enumeration
• Seven standard types cover the full spectrum of system architecture components
• All diagram schemas reference the same definition via common.schema.json#/$defs/componentType
• This pattern enforces type consistency and simplifies schema maintenance across the codebase

Frequently Asked Questions

What happens if I use a component type not in the enumeration?

Archify's schema validation will reject the document. Since all diagram schemas reference the same componentType definition from common.schema.json, any value outside the seven enumerated strings fails validation with a schema error pointing to the invalid type field.

Can I extend Archify with custom component types?

The current schema structure in tt-a1i/archify uses a closed enumeration. To add types, you would need to modify archify/schemas/common.schema.json at lines 39–41 and update all dependent schemas to use the new version. There is no runtime extension mechanism in the base implementation.

Why use $ref instead of defining types in each schema?

The $ref approach eliminates duplication and prevents type drift. If the Archify maintainers need to add a new component category—say, ai-model for ML inference components—they edit one file and all diagram schemas automatically inherit the change. This aligns with JSON Schema best practices for reusable definitions.

Which diagram types support component types?

According to the source code, workflow.schema.json, sequence.schema.json, and dataflow.schema.json all import componentType. The reference pattern "$ref": "common.schema.json#/$defs/componentType" appears in node type fields for workflows and dataflows, and in component definitions for sequence diagrams.

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