DSL Reference

Auto-generated by docs_gen.py. Run dazzle docs generate to regenerate.

Section	Description
Entities	Entities are the core data models in DAZZLE.
Access Control	DAZZLE uses Cedar-style access rules with three layers: entity-level permit/forbid blocks, surface-level access restrictions, and workspace-level persona allow/deny lists.
Surfaces	Surfaces define the UI and API interfaces for interacting with entities.
Workspaces	Workspaces compose multiple data views into cohesive dashboards or information hubs.
UX Semantic Layer	The UX semantic layer expresses WHY interfaces exist and WHAT matters to users, without prescribing HOW to implement it.
Experiences	Experiences define multi-step user flows such as onboarding wizards, checkout processes, and approval workflows.
Services	Services declare custom business logic in DSL with implementation in Python or TypeScript stubs.
Integrations	Integrations connect DAZZLE apps to external systems via declarative API bindings with triggers, field mappings, and error handling.
Processes	Processes orchestrate durable, multi-step workflows across entities and services.
Stories	Stories capture expected user-visible outcomes in a structured format tied to personas and entities.
Rhythms	Rhythms capture longitudinal persona journeys through the app, organized into temporal phases containing scenes — evaluable actions on specific surfaces.
Ledgers & Transactions	> Status: ALPHA — the ledger/transaction constructs parse, validate, and link, but TigerBeetle-backed execution is not yet CI-verified and no example exercises it end-to-end.
LLM Models & Intents	DAZZLE supports declarative LLM job definitions for AI-powered tasks such as classification, extraction, and generation.
Testing	DAZZLE provides a comprehensive testing toolkit including E2E testing with Playwright, FlowSpec test generation, semantic DOM conventions, capability discovery, CRUD completeness analysis, workflow coherence checks, and RBAC validation.
MCP Tool Inventory	Live inventory of the MCP tools exposed by dazzle mcp run.
Frontend & Templates	The Dazzle frontend uses the typed Fragment substrate (frozen-dataclass HTML primitives) with HTMX for declarative server interactions.
Messaging & Events	Messaging and events enable asynchronous communication between components and users.
Graph Features	Dazzle has first-class support for property graphs — data models where entities form nodes and their relationships form edges.
Compliance Framework	Dazzle can automatically assess how well your DSL specification maps to recognised compliance frameworks.
Governance	Governance constructs enforce organisational policies, approval workflows, and service-level agreements.
Patterns	Patterns are reusable DSL recipes that combine multiple constructs into proven solutions.

Guides & Operations

Page	Description
UX Catalogue	A live gallery of Dazzle display modes — each component rendered from real DSL through the real render pipeline, with its DSL snippet.
HM Design Context	The unified standard for HM design quality — the three rubrics (hygiene / vision / taste) on one surface × method matrix plus a concept map, the entry-point when customising HM for a new property.
Project Layout	The recommended directory layout for a Dazzle project — where DSL, app code, and one-shot scripts live.
DSL Grammar Specification	The formal EBNF grammar for the DAZZLE DSL, regenerated from parser source by dazzle grammar.
Personas and Scenarios	Personas define user types; scenarios define test-data states for development and demonstration.
UI Islands	Self-contained interactive JavaScript components that mount into server-rendered pages.
Reports & Charts	How chart and report regions (bar_chart, pivot_table, heatmap, funnel, metrics) compile to scope-aware aggregate queries.
Runtime UI Capabilities	What the Dazzle runtime actually renders for each DSL construct — the map from DSL to live UI.
HTMX Template Specification	The HTMX interaction patterns the runtime emits; SSR + HTMX with no SPA framework.
Card-Safety Invariants	The canonical spec for what a card means in Dazzle templates and the eight invariants its scanners enforce.
RBAC Scope Rules	Operation-by-operation reference for scope: row-level authorization rules and their predicate algebra.
RBAC Verification Framework	The three-layer access-control verification system that proves DSL-declared security policies hold.
Security Profiles	The security profile every app declares in its app block, and what each profile enforces.
Enterprise SSO & Provisioning	Native per-org enterprise connections (OIDC, SAML, SCIM) behind the opt-in capability registry.
PII & Privacy Primitives	Analytics, consent, and privacy primitives for marking and handling personally identifiable data.
Document Signing	Native PAdES B-T document signing as a first-class DSL primitive via signable: true.
Multi-Tenant Hosts	The tenant_host: sub-block that auto-mounts Host-header-based tenant routing (#1289).
Database Configuration	PostgreSQL configuration for development and production — Dazzle is Postgres-only (ADR-0008).
Schema Migrations	How Dazzle uses Alembic for all schema changes, including framework entities (ADR-0017).
AWS Deployment	Generating and managing AWS CDK infrastructure from your DSL specifications.
CLI Reference	Complete reference for the dazzle command-line interface and its command groups.
E2E Environment (Mode A)	The Mode A developer one-shot harness that launches a live example app for end-to-end testing.
QA Trial Patterns	Patterns surfaced by dazzle qa trial — qualitative business-user evaluation of a Dazzle app.
Fitness Methodology	The optional Agent-Led Fitness Methodology V&V loop that checks app fitness against declared intent.
Fitness Investigator	Agent-led investigation of ranked fitness clusters that produces actionable improvement proposals.
Fitness Triage	Turning a flat fitness backlog into ranked, actionable clusters for investigation.
Performance Envelope	Where the Dazzle runtime is fast, where it degrades, and by how much — measured.
Performance Observability	Local on-demand OpenTelemetry tracing for any Dazzle project via dazzle perf.
Perf Findings Schema	The JSON schema emitted by dazzle perf report --format json (FindingsReport).
Implicitness Audit	A working doc on identifying implicit behaviour in Dazzle, written after a runtime post-mortem.
Onboarding Guides	The guide construct: terse, in-fiction, per-persona onboarding overlays — authored by the agent, validated by a fast quality-bar gate plus an e2e guide-walk oracle.
LLM Drivers	Subscription-billed (claude-cli) vs metered (anthropic-api) cognition: resolution order, the dev → deploy path, and the production guard.
Framework UX-Maturity Rubric	Scores the framework, not a screen: does Dazzle make the data-right UI the DEFAULT? The 0-4 capability ladder, 13 criteria, evidence/attribution, and the dazzle ux maturity scan + /ux-maturity command.
DB Artifacts	Every database artifact the framework manages, in one registry: class, creator, boot-entry, owner, RLS posture, baseline membership, and boot-DDL gating.
RBAC Proof Model & Trust Boundary	The normative proof-obligation model for "provable RBAC": the effective-decision composition, the safety/availability/over-approximation theorem, assumption set A (the trust boundary), the proof→test→assumed trust chain, the per-property evidence-class table (Proof/Enumeration/Test), and the ReBAC declared-classes stance.
HaTchi-MaXchi — the Dazzle House Aesthetic	The canonical, agent-readable definition of Dazzle's visual taste: nine principles (including the HTMX4-structural signature), evidence-cited TASTE-n rules, the judged rubric, and the blind parity gate (dazzle qa taste-panel) with baseline-locked margins.
Verified-Domain Self-Service Join	The verified-domain join (#1424): a non-SSO user with a verified work email self-joins the tenant that owns their email domain — DNS-TXT domain proof, per-tenant join policy, and the password-side complement to invitations and SSO JIT provisioning.