The Gap Between Knowledge and Enforcement
Every organization has architecture knowledge. It lives in wiki pages, PDF standards, Confluence spaces, email threads, and the heads of senior architects. The problem is not a lack of knowledge — it is that knowledge is fragmented, unstructured, and impossible to enforce consistently.
When a project team asks "are we following our architecture standards?", someone has to manually dig through all of that material, interpret it, and apply it to the specific project. Different reviewers interpret the same standards differently. Reviews are inconsistent. Compliance is a matter of luck.
This is the gap that directives fill.
What Is a Directive
A directive is a single, structured, approved rule that your organization enforces. It is the atomic unit of architecture governance.
There are three types:
Principles are high-level beliefs that guide decision-making. Example: "All customer-facing services must be stateless and horizontally scalable." Principles rarely change and apply broadly.
Decisions are specific choices that have been made and ratified. Example: "We will use PostgreSQL as our primary relational database for all new services." Decisions have context — why the choice was made, what alternatives were considered, and when it should be revisited.
Guardrails are hard constraints that must not be violated. Example: "No service may store personally identifiable information outside of the EU data region." Guardrails are non-negotiable and typically tied to regulatory or security requirements.
The Directive Lifecycle
Directives are not static. They follow a lifecycle:
- Draft — someone proposes a directive, either manually or with AI assistance from your knowledge base
- In Review — the directive is reviewed by designated approvers who can comment, suggest changes, or request revisions
- Approved — the directive is active and will be enforced during architecture reviews
- Deprecated — the directive is no longer enforced but remains visible for historical context
This lifecycle matters because it creates accountability. You can see who proposed a directive, who approved it, when it was last reviewed, and why it was deprecated. When an auditor asks "why did you make this architecture decision?", the answer is traceable.
How AI Fits In
Directives work in two directions with AI:
Extraction: AI reads your knowledge base — your standards documents, policies, whitepapers — and proposes candidate directives. Instead of spending weeks manually distilling hundreds of pages into actionable rules, you review and approve AI-generated drafts. This is how most organizations bootstrap their directive set.
Enforcement: During architecture sessions, AI reviews projects against all approved directives. It generates findings with severity levels and specific guidance on what to fix. This is how directives stop being shelf-ware and start being enforced consistently across every project.
Why This Matters for Your Organization
Without directives, architecture governance is tribal knowledge. It depends on who is in the room, who remembers the last decision, and who has time to review this week.
With directives, governance becomes a system. Rules are explicit. Reviews are consistent. Compliance is measurable. And when someone new joins the architecture team, they do not need six months of institutional knowledge to start reviewing projects effectively — the directives tell them what to check.
If your organization has architecture standards but struggles to enforce them consistently, directives are the missing layer.