Architecture Directives in Practice — A Guide for Every Architect Role

Good architecture governance has never been the exclusive responsibility of enterprise architects. Every architect — product, solution, domain, and enterprise — makes decisions that shape the systems an organisation depends on. The challenge is that most governance tools and processes have been designed as if only one or two senior roles carry that responsibility.

cajeX is built on a different belief: that governance works best when every architect role can contribute to it, and when the rules that govern decisions are clear enough that no one has to guess. Architecture Directives are the mechanism that makes this possible — structured, approved rules that any architect can propose, and that domain and enterprise architects approve and maintain as the guardians of the governance standard.

This post builds on the foundational definition of directives to show how they work in practice across roles, what each of the five elements contributes, and how the cajeX AI co-worker helps every architect engage with governance — not just the most senior ones.

Governance That Works for Every Architect Role

Architecture governance fails when it concentrates too much in too few people. A single enterprise architect cannot review every project, maintain every standard, and respond to every question from every delivery team. The knowledge bottleneck this creates is one of the most common causes of governance drift.

cajeX is designed to distribute governance without diluting it. Every architect role has a place in the Directive workflow:

• Product & Solution
  Work closest to delivery. Best positioned to propose new Directives — flagging gaps in the current standard, surfacing recurring decisions that need a governed answer, or identifying guardrails that delivery teams keep bumping into. Any architect can propose a Directive.
• Domain
  Own the governance standard within their domain. Review proposed Directives, assess conflicts with existing rules, and approve or reject them. An approved Directive is active — it will be applied in every review.
• Enterprise
  Set the cross-domain standard and hold final authority over Directives that span the organisation. The ultimate guardians of governance quality and consistency.

In cajeX, this maps directly to platform access roles. Members can propose and contribute. Admins manage Directives within their domain — reviewing, approving, and maintaining the active set. Owners hold workspace-level authority and set the cross-domain standard. Additional roles can be configured as governance structures evolve.

Current roles: Member, Admin, Owner. Additional roles can be created as your governance structure grows.

What a Directive Contains

The existing blog on directives explains the concept in full. For this post, the key point is that a Directive is not a document — it is a governed object. The cajeX AI co-worker can validate it against a real project.

Each Directive is built from five elements. At a glance:

How the Five Elements Work Together

The five elements are a system. Each one does a different job, and they are strongest when all five are present.

When a review produces a finding, it links back to the specific element that was not met — not just the Directive. That granularity is what makes architecture compliance tracking actionable rather than administrative.

How the AI Co-Worker Supports Every Role

Most teams are not starting from scratch. Years of standards, policies, and architectural decisions already exist — in the Knowledge Base, in PDFs, in Confluence pages that nobody reads cover to cover.

The cajeX AI co-worker works with what is already there:

1. Reads the material in the Knowledge Base and extracts candidate principles, standards, patterns, guardrails, and decisions
2. Groups related content and suggests testable wording for each element
3. Surfaces draft Directives for architect review, refinement, and approval
4. Cross-references against existing Directives to flag duplications and conflicts

Any architect can trigger this process — a product architect who spots a recurring decision, a solution architect who needs a pattern documented, a domain architect who wants to formalise a guardrail. The AI co-worker drafts it. The domain or enterprise architect approves it. Once approved, it is active and applied in every subsequent review.

Getting Started: A Practical Playbook

You do not need to overhaul everything at once. Here is a straightforward approach to building your first Directive library.

Step 1: Collect and prioritise. Start with the Knowledge Base. Load your existing standards, policies, and key documents. Focus on the areas generating the most review friction or regulatory risk.

Step 2: Propose your first Directives. Any architect can propose. Use the cajeX AI co-worker to draft from existing Knowledge Base material. Give each Directive a clear name and assign a proposer.

Step 3: Refine for enforceability. Make standards and guardrails testable. Define what is being checked — configuration files, solution designs, deployment manifests, architecture decision records. The more specific, the more useful.

Step 4: Approve and activate. Domain or enterprise architects review, challenge, and approve. An approved Directive is active — it will be applied in every review from this point forward.

Step 5: Apply and expand. Run the active Directive set against one team or project category. Measure finding quality and review consistency. Then expand the Directive library and the scope of reviews together.

What Changes When Governance Is Directive-Based

The practical difference is consistency at scale.

Architecture reviews stop depending on who is available. When the cajeX AI co-worker applies the full Directive set at review time, every project is evaluated against the same rules — regardless of which architect runs the session. A solution architect two weeks into their role produces the same finding quality as a principal architect with ten years of institutional knowledge, because the knowledge is in the Directives, not in the person.

Architecture compliance tracking becomes continuous rather than periodic. The audit trail builds with every session. Every finding traces to a Directive. Every approved risk is recorded. When a regulator asks what was reviewed and what was found, the answer is already there.

Findings also become feedback. When the same Directive generates findings consistently across multiple projects, that pattern is a signal worth acting on. It may mean the standard is too broad, the guardrail too ambiguous, or the compliance path unclear to delivery teams. Architecture teams can review which Directives are generating the most findings, read the associated comments and rationale, and decide whether to refine the wording, add a pattern to make compliance more practical, or update the standard to reflect how delivery has genuinely evolved. Governance that learns from its own data is governance that improves over time.

And governance becomes a contribution model rather than a bottleneck. Domain and enterprise architects stop being the only people who can advance the governance standard. Every architect role can propose. The right roles decide. The platform enforces.

That is what democratic governance looks like in practice.

The Architecture Toolbox

A well-curated Directive library is the foundation everything else in cajeX builds on. The Knowledge Base feeds it. The AI co-worker drafts from it. Domain and enterprise architects govern it. The review engine applies it. Findings, reports, dashboards, and audit trails all flow from it.

Every architect role has a part to play. The product architect who flags a new pattern. The solution architect who documents a recurring decision. The domain architect who approves the guardrail. The enterprise architect who sets the cross-domain standard. cajeX is the platform that connects those contributions into a governance system that actually works.