module.toml Manifest Reference

The module.toml file is the manifest at the root of every rescile module. It defines the module’s identity, declares the parameters it accepts, specifies the asset and input schemas it expects from the consuming project, and configures data generators that fetch or scaffold data automatically before the graph is built.

When a module is loaded via --module, rescile reads this file first to validate parameters, assets, and inputs before any graph processing begins. It also drives the bootstrap command and dependency resolution via rescile-ce mod.

[module]
name = "my-module"
version = "1.0.0"
description = "A custom module"
rescile_version = ">=0.1.85"

[dependencies.other_module]
url = "https://github.com/rescile/other.git"
resource_aliases = { "old_type" = "new_type" }

[params.env]
description = "Environment variable"
default = "dev"
required = false

[assets."app.csv"]
resource_type = "application"
name_template = "app-{{ name }}"
bootstrap = "name,owner\napp1,teamA"
[assets."app.csv".columns.name]
type = "string"
required = true

[requirements.application]
properties = ["technology", "license", "platform", "function"]
description = "Applications to assess for vendor lock-in and open standards."

[input."config.json"]
format = "object_of_objects"

[generators.fetch_data]
target_input = "config.json"
command = ["script.sh"]
env = ["TOKEN={{ env.TOKEN }}"]
ttl = "1h"
condition = "on_missing"

[generators.fetch_data.secrets.my_token]
collection = "my-app-secrets"
secret = "API_TOKEN"

[module] — Module Identity

Declares the module’s name, version, human-readable description, and the minimum rescile version it requires. These fields are displayed in the rescile dashboard and used during dependency resolution.

For detailed usage see Using Modules.

[dependencies] — Module Dependencies

Declares other modules this module depends on. Three declaration formats are supported: a simple Git URL string, a detailed { git = "...", tag = "..." } table, or a release archive { url = "...", version = "..." } table. An optional resource_aliases map transparently remaps resource type names from the imported module to avoid naming conflicts in the global graph.

Dependencies are resolved recursively. Use rescile-ce mod lock to pin them to exact commits for reproducible builds.

For the full reference including lockfile commands see Module Dependencies & Lockfiles.

[params] — Module Parameters

Declares the named parameters a module accepts at runtime via --module-params. Each parameter entry can specify a description, a default value, whether it is required, and an allowed_values list for validation. Declared parameters are made available as global Tera variables in all models/, compliance/, and output/ files of the module.

For usage examples see The Data Directory — Parameters Make Modules Reusable.

[assets] — Asset Schema & Bootstrap

Declares the CSV asset files the module expects in the consuming project’s data/assets/ directory. Each entry can define column-level validation (type, required, allow_empty), an optional name_template to dynamically rewrite the primary key, an explicit resource_type override, and a bootstrap string that rescile-ce bootstrap writes as the initial file content.

For the full asset schema reference and automatic asset generation via generators see Asset Management — Module Asset Configurations.

Shared asset types across modules: if two modules declare column specifications for the same asset file, startup fails with Asset '<file>' has conflicting column specifications ... Please use resource_alias to resolve the conflict. When your module merely references a type owned by another module (e.g. system, team), ship its reference CSV rows without an [assets."<file>"] block — the files still load and auto-bootstrap — and declare expectations via [requirements] instead. See Composing Multiple Modules.

[requirements] — Requirements

Checks that specific resources and properties exist in the overall graph, validating that the module’s assumptions about the environment hold true — regardless of which module (or the local data dir) created those resources.

[requirements.application]
properties = ["technology", "license", "platform", "function"]
description = "Applications to assess for vendor lock-in and open standards."

[input] — Input Schema & Bootstrap

Declares the JSON input files the module expects in the consuming project’s data/input/ directory. Each entry defines the expected format (currently object_of_objects), optional fields validation, and a bootstrap string for rescile-ce bootstrap. rescile validates user-supplied input files against this schema before processing begins.

For the full input schema reference see Input Management.

[generators] — Data Generators

Configures commands that rescile executes automatically to fetch or scaffold asset and input data before the graph is built. Each generator entry specifies a target_input or target_asset, the runner to execute, optional securely mapped secrets from the Vault, env variable mappings, from_stdout capture, a ttl cache duration, and a condition trigger (always, on_missing).

Scripts placed in the module’s generators/ directory are automatically added to PATH during execution. Generators in untrusted modules require explicit approval via --trust-modules in CI environments.

For the complete generator reference including security and validation behaviour see Data Generators.