---
title: "Framework configuration (_mighty.yml)"
vignette: >
  %\VignetteIndexEntry{Framework configuration (_mighty.yml)}
  %\VignetteEngine{quarto::html}
  %\VignetteEncoding{UTF-8}
knitr:
  opts_chunk:
    collapse: true
    comment: '#>'
---
# Overview

The `_mighty.yml` file provides framework configuration that spans across all ADaM domains. This file should be placed in the study directory alongside individual ADaM domain specification files.

# External data

The `external_data` section specifies primary keys for all external datasets that will be available at runtime. This includes:

- **SDTM domains** (e.g., DM, EX, LB)
- **Metadata datasets** (e.g., MDPARAM, MDVISIT)
- **Pre-existing ADaM datasets** (e.g., any ADaM dataset not being generated by mighty)

**IMPORTANT:** ADaM domains being generated by mighty should have their keys defined in their individual domain specification files (see `vignette("adam_specification")`), NOT in `_mighty.yml`.

**IMPORTANT:** Domain names must be specified in uppercase following CDISC standards (e.g., `DM`, `EX`, `LB`), regardless of the file name casing. The system automatically handles case conversion when reading data files.

### Example:

```yml
external_data:
  - id: DM
    keys: [USUBJID, STUDYID]
  - id: EX
    keys: [USUBJID]
  - id: MDPARAM
    keys: [STUDYID, TOPICCD]
```

# Component repositories

The `repos` field tells mighty where to look for code components. Repositories are searched in the order listed, and the first match wins.

A component with the same name in a later repository is ignored. This also applies to mighty's internal templates (for example `mighty_init_domain`). To use your own version of an internal template, put its repository before the one with the internal templates. Otherwise, list the internal templates first.

Each entry can be:

- `github::owner/repo` — a GitHub repository
- `github::owner/repo/subdir` — a subdirectory inside a GitHub repository
- `github::owner/repo/subdir@ref` — a specific branch, tag, or commit
- A local filesystem path (absolute or relative to the working directory), optionally prefixed with `local::`

mighty resolves each GitHub ref to a commit once per R session, and downloads each commit once per session. Later calls to `generate_adam_code()` reuse the cached copy. Restart R to pick up new commits on a branch.

### Example:

```yml
repos:
  - github::NovoNordisk-OpenSource/mighty.standards/components
  - github::my-org/study-components@v1.0.0
  - "./local-components"
```

**IMPORTANT:** `repos` must include a source for mighty's internal templates (typically `github::NovoNordisk-OpenSource/mighty.standards/components`). Without it, mighty cannot resolve the special components used during code generation.

## Component IDs

The `id` of a component in an ADaM specification is looked up in `repos`. It is not a file path. Inside each repository, `id: relative_day` matches:

- `relative_day.R` or `relative_day.mustache`
- the same file names inside a `relative_day/` subdirectory

If one repository has more than one match (for example both `relative_day.R` and `relative_day.mustache`), mighty stops with an error. Use the file name with its extension to select one.