Overview

Trurlic is an architecture layer that sits between human intent and AI-generated code. Every decision about how a system should work — data model choices, error handling patterns, API design rules — is captured in a typed graph and served to coding agents as constraints before they generate a single line.

The problem

AI coding agents ship fast. Each one makes its own architectural choices — silently, differently every time. The diffs look fine in isolation. Six months later you have a codebase that works but has no coherent design, and no one can explain why anything is the way it is.

The system works. You just don’t own it.

Every agent framework today ships the same pattern: the model decides, the code is generated, the PR is merged. There is no mechanism to enforce consistency across agent sessions. No structured record of what was decided and why. No constraint system that prevents silent drift.

What Trurlic does

Trurlic replaces implicit architectural drift with explicit, human-authored decisions:

Developer defines architecture
           │
           ▼
    ┌─────────────┐
    │   Trurlic    │  ← decisions, patterns, rules, connections
    └──────┬──────┘
           │
           ▼
    AI coding agent generates code
    (constrained by the decision graph)

When an agent calls get_context("rate-limiter"), Trurlic returns an authoritative brief: project-wide rules (inviolable), component decisions (strong defaults), related constraints from connected components, and an override policy. The agent generates code; the graph constrains it.

Three guarantees

1. Decisions are human-authored. Every constraint in the graph came from a person — either through a Socratic design conversation, a quick trurlic decide command, or explicit review of agent-attributed decisions. AI assists the thinking; humans own the result.

2. One graph, every agent. Whether the developer uses Claude Code, Cursor, Windsurf, Cline, or a custom agent — they all query the same decision graph over MCP. No configuration drift between tools. No agent makes up its own architecture.

3. Fail-closed on writes. Every mutation validates the full graph before touching disk. Dangling edges, cycles, schema violations — refused with a clear error, never silently committed. The graph is always consistent, or the write doesn’t happen.

What the agent sees

When an AI coding agent calls get_context("rate-limiter"):

RULES (inviolable — every generated line must respect these):
- ALL error handling MUST use Result<T, AppError>
- ALL persistent state MUST use Redis

COMPONENT: rate-limiter
- Per API key, consistent with auth boundary
- Redis sliding window, 60s buckets
- 429 + retry-after header, RFC 6585 compliant

PATTERNS:
- state-in-redis: shared pool via app state, no per-component connections

RELATED (from connected components):
- auth: JWT with DPoP, rate limiter runs AFTER auth

OVERRIDE POLICY:
RULES are inviolable. Component decisions are strong defaults —
follow them unless the user explicitly revises them via design.
Never silently deviate. WHEN UNCERTAIN: STOP and ask.

Every decision came from a human. The agent generates code; the graph constrains it.

What Trurlic is not

• Not a linter or code analyzer. Trurlic constrains what gets generated, not what already exists. It operates upstream of code, at the decision level.
• Not a prompt template. The decision graph is structured, typed, and validated. It is not a markdown file pasted into context — it is a queryable knowledge base with integrity guarantees.
• Not a governance tool. Trurlic does not approve or deny agent actions. It provides constraints; the agent is expected to follow them. For execution-level enforcement, see LatchGate.

When to use Trurlic

• Codebases with multiple AI coding agents that need architectural consistency
• Teams where architectural decisions need to survive developer and agent turnover
• Projects where “why was this built this way?” needs a real answer
• Existing codebases that need their implicit architecture made explicit via bootstrap
• Any situation where AI-generated code should follow human-authored design

When Trurlic is overkill

• Solo prototypes where consistency doesn’t matter yet
• Pure configuration or infrastructure-as-code with no architectural decisions
• Codebases that don’t use AI coding agents

How to move forward

If you want to see it running: Getting Started — 60 seconds from install to first decision.

If you want to connect an IDE agent: MCP Server — how the decision graph becomes MCP tools.

If you want to understand how it works: Core Concepts — decision graph, advance loop, context briefs.

If you want to extract architecture from existing code: Bootstrap — autonomous graph population.

If you want to explore the graph visually: Interactive Map — browser-based visualization.