Configuration
simplicity.json reference
Configuration is optional on the first run and strict once you add it. Place simplicity.json beside the solution, override only what you need, and let unsupported values fail fast instead of silently changing the contract.
Full shape
The current schema covers TCA inputs and filter thresholds.
{
"tca": {
"teamSize": 8,
"averageEngineerMonthlySalaryUsd": 15000,
"estimatedMonthlyIncidentCount": 4,
"onCallHourlyRateUsd": 150,
"attritionCoefficientPercent": 15
},
"filters": {
"primaryPathRatioTarget": 0.6,
"prematureAbstractionRatioTarget": 0.25,
"maxMethodComplexity": 5,
"maxOnboardingHours": 40,
"passingScore": 0.7
}
} Behavior rules
The loader is permissive about missing files and strict about bad files. That is an intentional boundary.
- Missing
simplicity.jsonproduces a warning and the CLI continues with built-in defaults. - Partial files are allowed; omitted values fall back to defaults.
- Unsupported properties and out-of-range values fail fast instead of being ignored.
- The file is loaded from the solution directory only, not by walking parent folders.
Practical minimal override
Override only the thresholds you actually want the team to own.
{
"filters": {
"primaryPathRatioTarget": 0.75,
"maxMethodComplexity": 4
}
} If a threshold changes, treat it like a policy decision. Otherwise you are just moving the goalposts to make the output quieter.
Where configuration shows up
Different commands consume the same file in different ways.
Uses filter thresholds directly to render the four budget dimensions.
Uses the same thresholds in the HTML budget section and related guidance.
Reloads the file on every pass so threshold changes show up without restarting the process.
Feed cost-of-complexity calculations for CLI/report flows; library consumers can pass inputs directly instead.