Governing AI System Behavior Through Architectural Constraints in Files

The Challenge of Governing AI Systems

When building systems that leverage large language models (LLMs), a primary challenge is ensuring the AI's output remains consistent, adheres to defined boundaries, and aligns with architectural principles. Traditional prompt engineering, where constraints are embedded directly in conversational prompts, is often insufficient. Prompts are ephemeral, easily ignored, and difficult to verify, leading to "system drift" where the AI's behavior diverges from design expectations over time.

Files as Architecture, Prompts as Memory

The Constraint Pyramid

The article introduces a "constraint pyramid" framework, an organizational structure for defining AI governance. This pyramid consists of five layers, each translating the layer above it and narrowing the scope for the layer below. Constraint flows down, dictating what the model can do, while accountability flows up, providing an audit trail.

Strategy —— README / constitution : what this is, its boundaries 
↕ Architecture —— ADR set : where the limits are, what won't be revisited 
↕ Contracts —— spec + runbook : what exactly must be delivered 
↕ Gates —— pre-submit checks : what is not allowed to become code 
↕ Implementation— constrained output : the model's work, fenced in from above 

This layered approach ensures that every piece of generated code can be traced back through gates, contracts, architectural decisions, and ultimately to strategic intent. The key is to arrange these constraints in files, from fewer, heavier, more abstract rules at the top to more numerous, specific rules closer to the actual model output.

Constraint Strength Tiers

Beyond the pyramid's layers, constraints are categorized by their strength, ensuring the model understands the criticality of each rule:

• L1 — Hard Constraints: Enforced programmatically by code and gates (e.g., pre-submit scripts, schema validations, shared DTOs). These are "walls" the model cannot cross.
• L2 — Architecture Constraints: Carried by accepted Architecture Decision Records (ADRs) and file layout conventions. They define the system's design principles; changes require new ADRs.
• L3 — Execution Suggestions: Loose guidance (e.g., runbook steps, skill definitions, checklists). The model can iterate on these but must record any changes.

Properly assigning rules to these tiers prevents the AI from treating all directives as mere suggestions, thus maintaining system integrity. A healthy system also incorporates a feedback loop where model deviations inform updates to the constraint layers, making the system adaptive and "alive."