Conformance Rule Packs - Archyl Docs

Pre-built conformance rule sets for common architecture patterns — microservices, clean architecture, event-driven, API-first, and security baseline

Conformance Rule Packs

Rule packs are curated collections of conformance rules that encode best practices for common architecture patterns. Instead of writing rules from scratch, install a pack and get an opinionated, battle-tested ruleset in seconds.

Why Rule Packs?

Most teams follow well-known patterns — microservices, clean architecture, event-driven systems. Each pattern comes with constraints that should be enforced automatically:

  • Microservices shouldn't share databases
  • Domain layers shouldn't import infrastructure code
  • Events should follow a schema contract

Rule packs turn these principles into executable guardrails.

Available Packs

Pack Rules Focus
Microservices 10 Service boundaries, independent deployability, bounded communication
Clean Architecture 9 Layer boundaries, domain isolation, port/adapter enforcement
Event-Driven 8 Channel compliance, schema requirements, dead letter queues
API-First 8 Contract requirements, versioning, auth documentation
Security Baseline 8 Gateway enforcement, secret management, external access controls

Installing a Pack

Via the archyl-developer skill

Ask your AI coding agent:

Install the microservices conformance rules pack

The agent calls the Archyl MCP server and creates all rules in one operation.

Via the SDK

import { ArchylClient } from "@archyl/sdk";

const client = new ArchylClient({
  apiKey: process.env.ARCHYL_API_KEY,
  organizationId: "your-org-id",
});

// Install a pack by name
await client.governance.installPack("microservices");

Via the UI

Navigate to Agent Hub > Packs and click Install on any pack.

What's in Each Pack

Microservices (10 rules)

  • No shared databases — Each service must own its data. Cross-service queries via APIs only.
  • Independent deployability — No compile-time dependencies between services. Shared libraries must be versioned.
  • Bounded communication — Services communicate through defined API contracts or event channels, not direct database access or file sharing.
  • Service isolation — No cross-service imports. Each service has its own dependency tree.

Clean Architecture (9 rules)

  • Domain layer purity — Domain code has zero external imports. No framework, no ORM, no HTTP.
  • Dependency direction — Dependencies point inward. Handlers depend on services, services depend on domain, never the reverse.
  • Port/adapter enforcement — Infrastructure concerns (DB, HTTP, messaging) live in adapter packages, not in domain or service layers.
  • Interface boundaries — Services consume interfaces (ports), not concrete implementations.

Event-Driven (8 rules)

  • Channel compliance — Event producers and consumers must use declared event channels. No ad-hoc topic creation.
  • Schema requirements — Every event must have a defined schema. No untyped payloads.
  • Dead letter queue — Consumers must configure a DLQ for failed message handling.
  • Topic naming conventions — Topics follow a consistent naming pattern (e.g., domain.entity.event).

API-First (8 rules)

  • Contract required — Every public endpoint must have an OpenAPI, gRPC, or AsyncAPI contract on file.
  • Versioning — API endpoints must include a version prefix (/v1/, /v2/).
  • Auth documentation — Security schemes must be documented in the contract.
  • No undocumented endpoints — Handler files without corresponding contract documentation trigger a violation.

Security Baseline (8 rules)

  • Gateway enforcement — External traffic must route through an API gateway or load balancer. No direct service exposure.
  • Secret management — No hardcoded secrets, API keys, or passwords in source code. Use environment variables or a secret manager.
  • External access controls — Services that accept external requests must enforce authentication and rate limiting.
  • TLS required — All inter-service communication must use TLS. No plaintext HTTP between services.

Customizing Rules

After installing a pack, every rule is fully editable:

  • Change severity — Downgrade a rule from critical to medium if it doesn't match your risk tolerance
  • Disable specific rules — Toggle off individual rules you don't need without removing the entire pack
  • Modify configuration — Adjust file globs, patterns, allowed imports, or layer definitions to fit your project structure

Navigate to Agent Hub and click the edit icon on any rule to modify it.

Combining Packs

Packs are additive. Install multiple packs to cover different architectural concerns:

Combination Use case
Microservices + API-First + Security Baseline API-driven microservice platform with security guardrails
Clean Architecture + Security Baseline Monolith with strict layer boundaries and security hygiene
Event-Driven + Microservices Event-sourced microservice system
API-First + Clean Architecture Contract-driven monolith or modular monolith

If two packs contain overlapping rules, Archyl deduplicates them — no conflicts.

Contributing

Rule packs are open source. You can propose new packs, add rules to existing ones, or report issues:

Next Steps