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:
- The Roster (Assets only): Maintain simple CSV lists and use rescile as a relational viewer.
- The Blueprint (+ Models): Add
models/*.tomlto derive infrastructure components and link assets. - The Auditor (+ Compliance): Introduce
compliance/*.tomlto enforce policies automatically. - The Operator (+ Output): Add
output/*.tomlto generate Terraform variables, manifests, and API payloads. - The User (+ App):: Add
app/*.htmlto 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:
- Using Modules — consuming modules as a project user
- Module Packaging Guide — authoring and distributing modules
- Module Dependencies & Lockfiles — reproducible builds