A policy describes what kind of system you want, not how it is implemented. Emitters never read policy directly. Lowering interprets policy and produces a fully decided TargetIR.
1policies: {
2 backend: { core: { generateId: "uuid_v4" } },
3 frontend: {
4 basePath: "/admin",
5 framework: { rendering: { mode: "ssg", prerender: { routes: "auto" } } }
6 },
7 staticSite: { enabled: true, baseUrl: "/docs/" }
8}Multi-Application Support
With the basePath policy, irgen can generate different frontend targets that coexist on the same domain. For example, a marketing site at / (mode: ssg) and an admin dashboard at /admin (mode: csr).
What a Policy Is
Policy is a declarative statement of intent. It does not emit code and is never interpreted by emitters.
Why Policy Exists
Without policy separation, generators mix configuration into templates and emitters. irgen enforces DSL for intent, policy for constraints, lowering for decisions, and emitters for execution.
Policy Scope
Policies are grouped by target domain, for example backend, frontend, staticSite, and electron. Each block is optional and composable.
Lowering Responsibilities
Lowering resolves routing, capabilities, dependencies, and fallback behavior, then produces TargetIR that is final and deterministic.
Lowering Must Not Do
Lowering must not emit files, generate code, perform IO, or depend on runtime behavior. It should be pure and deterministic.
Capability-Based Design
Capabilities represent feature requirements such as search, copyCode, or themeToggle. Lowering detects capabilities and passes them to emitters.
Fallback Rules
Unsupported constructs must degrade or be skipped with warnings. Silent failure is not allowed.