Getting Started

The Data Directory

Understand the data/ directory layout, how each subdirectory maps to a processing phase, and how modules let you share and reuse subsets of it.

The Data Directory

Structure, Phases, and a Path Towards Modularisation

Every rescile project revolves around a single directory — conventionally named data/ — that contains all the information needed to build, govern, and query your infrastructure graph. Understanding this directory and the role each of its subdirectories plays is the foundation for writing effective configurations.

The Standard Layout

my-project/
└── data/
    ├── assets/      # CSV ground-truth files
    ├── models/      # TOML architectural models
    ├── compliance/  # TOML governance rules
    ├── output/      # TOML output definitions
    ├── input/       # JSON configuration data
    └── app/         # HTML for browser rendering

You point rescile-ce at this directory with the --data-dir flag:

rescile-ce --data-dir ./data serve

How Each Directory Maps to a Processing Phase

rescile processes your configuration in a strict, four-phase sequence. Each subdirectory feeds exactly one phase:

flowchart LR
    A["data/assets/\n*.csv"] --> P1["1. Asset Loading"]
    B["data/models/\n*.toml"] --> P2["2. Model Application"]
    C["data/compliance/\n*.toml"] --> P3["3. Compliance Application"]
    D["data/output/\n*.toml"] --> P4["4. Output Generation"]
    P1 --> P2 --> P3 --> P4 --> G["Queryable Graph &\nArtifacts"]

data/assets/ — The Ground Truth

CSV files define the raw components of your environment. The filename determines the resource type; the first column is the primary key.

data/assets/
├── application.csv   → resources of type "application"
├── database.csv      → resources of type "database"
└── network.csv       → resources of type "network"

Every row always creates a resource. Columns whose names match another asset filename automatically create relationships between resources. For a complete reference, see Asset Management.

data/models/ — The Architecture

TOML model files transform raw assets into a rich, contextual dependency graph. They create derived resources, establish relationships, and propagate data.

data/models/
├── server.toml       # creates a "server" for every "application"
└── platform.toml     # links applications to cloud or on-prem platforms

For a complete reference, see Architectural Models.

data/compliance/ — The Governance Rules

TOML compliance files are processed after the full architectural graph is built. They mutate the graph to enforce your organisation’s security and governance policies — inserting controls, enriching relationships, and mapping ownership.

data/compliance/
└── security.toml     # enriches application→database edges with TLS requirements

For a complete reference, see Compliance as Code.

data/output/ — The Artifacts

TOML output files query the final governed graph and generate structured data artifacts — JSON reports, Terraform variable files, Kubernetes manifests, and more.

data/output/
└── terraform.toml    # generates tfvars JSON for each application

For a complete reference, see Output Engine.

data/input/ — Configuration Data

JSON files in data/input/ provide structural or environment-specific configuration. Unlike assets, inputs never create resources — they are strictly used as lookup data in your templates. Modules can declare schemas for these files to validate the data they receive.

For a complete reference, see Input Management.

data/app/ — Application Data

The data/app/ directory is served as a static application by rescile-ce. Any HTML, CSS, or JavaScript placed here can query /graphql to build richer dashboards or self-service tools. For more complex applications with a build step, API proxying, or CORS configuration see the

For a complete reference, see Application Module Developer Guide.

Growing the Data Directory

A common pattern is to start small — a handful of asset CSVs — and grow the directory incrementally as your needs evolve:

  1. The Roster (Assets only): Maintain simple CSV lists and use rescile as a relational viewer.
  2. The Blueprint (+ Models): Add models/*.toml to derive infrastructure components and link assets.
  3. The Auditor (+ Compliance): Introduce compliance/*.toml to enforce policies automatically.
  4. The Operator (+ Output): Add output/*.toml to generate Terraform variables, manifests, and API payloads.
  5. The User (+ App):: Add app/*.html to provider UI Interfaces for uses, like graphical reports or self-service portal.

Modularising with Modules

As your project grows, you may find that certain combinations of models, compliance rules, and output definitions are useful across multiple projects — a standard Kubernetes application blueprint, a shared TLS enforcement policy, or a common Terraform variable generator.

This is exactly what modules are designed for. A module is a self-contained directory that provides a subset of the data/ structure — its own models/, compliance/, and output/ directories — packaged with a module.toml manifest that defines its interface.

my-module/
├── module.toml       # manifest: name, version, params, asset/input schemas
├── models/           # reusable architectural models
├── compliance/       # reusable governance rules
├── output/           # reusable output definitions
├── input/            # local JSON input definitions or starter files
└── app/              # custom web UI served by rescile-ce

When you load a module, rescile merges its models/, compliance/, and output/ directories with (or instead of) your local data/ counterparts. Your local data/assets/ and data/input/ directories are always used, allowing you to inject project-specific ground truth into the shared module logic.

# Use a remote module; supply only local assets
rescile-ce --module https://github.com/my-org/rescile-modules/standard-webapp \
           --data-dir ./my-project/data \
           serve

What a Module Can Provide

Module directory What it replaces / augments
models/ Architectural transformation rules
compliance/ Governance and security controls
output/ Artifact generation templates
app/ A custom web UI served by rescile-ce
module.toml schemas Validation rules for data/assets/ and data/input/

A module does not have to provide all of these. A module can exist solely to deliver a compliance framework, a custom dashboard, or a bootstrapping utility.

Parameters Make Modules Reusable

Modules accept parameters at runtime via --module-params, making the same module usable across different environments or projects without modification:

rescile-ce --module ./standard-webapp \
           --module-params "environment=prod;region=eu-central-1" \
           serve

Inside the module’s TOML files, {{ environment }} and {{ region }} render to the provided values.

Composing Multiple Modules

You can load several modules simultaneously. rescile merges their rules in order, and your local data/ acts as the final overlay:

rescile-ce \
  --module https://github.com/my-org/core-networking.git \
  --module https://github.com/rescile/rescile-ccm-lite.git \
  --data-dir ./my-project/data \
  serve

For a deeper dive into authoring, parameterising, and publishing modules, see: