Blueprint System

The blueprint system is the heart of Radish.

Blueprints provide a structured way to describe an application before implementation details are chosen. They are designed to be both human-readable and machine-compilable.

What a Blueprint Describes

A blueprint describes application intent in a form that can be compiled into architecture.

Common concepts include:

• entities
• fields
• relationships
• ownership
• roles and permissions
• indexes
• versioning behavior
• metadata and exposure rules

Example:

{
  "version": 1,
  "entities": {
    "Concept": {
      "fields": {
        "title": {
          "type": "string",
          "required": true
        },
        "authorId": {
          "type": "objectId",
          "ref": "User"
        }
      }
    }
  }
}

Blueprint Principles

Blueprints should be:

• explicit
• structured
• versionable
• portable
• independent of unnecessary framework-specific details

Blueprint Files

A Radish project uses four blueprint files:

Blueprint	Purpose
app.json	App metadata, audience, workflows, features, style
types.json	Entity definitions — fields, types, indexes, relationships
roles.json	Roles and permission assignments
ui.json	Routes, pages, content blocks, layouts, components, access control

The ui.json blueprint drives the UI layer generator (src/generators/ui-layer/), producing pages, layouts, and components as defined in the blueprint.

Blueprint Versioning

Blueprints should include a spec version:

{
  "version": 1
}

This is separate from package versions or generator versions.

For a comprehensive reference on blueprint authoring — field types, entity options, relationships, and examples — see the Blueprint Reference.