> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stratalint.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Philosophy

> Why Strata is strict by default and how deliberate deviation works.

Strata is opinionated on purpose. A few decisions explain most of how it behaves.

## Strict by default

Strata ships a coherent default architecture, not a blank rule framework. Defaults
are strict wherever the tool can make an honest, deterministic claim.

The point is that you should not have to stop and decide where code goes on every
change: follow the rules and they carry you. The moment you want to deviate is the
signal that something actually needs a decision, and Strata makes that decision
visible rather than silent.

It is the stance a type system or a borrow checker takes: correct from the ground
state, with escapes that are explicit rather than ambient.

## How to deviate

When a rule does not fit, you have three escapes:

1. **Disable it** with `ignore` in config.
2. **Scope it off** by adjusting `roots`, `tests`, or `tooling`.
3. **Replace it** with a [custom rule](/concepts/custom-rules).

All three live in `strata.toml`, never in your business-logic files.

### No inline suppression

Strata has **no `# strata: allow` comment**, on purpose.

An inline suppression hides in a large diff, passes CI, and reads like any other
comment. That is the `# type: ignore` failure mode: the guard drops quietly and
drift compounds one line at a time. Editing `strata.toml` is different: a config
change is something a reviewer stops to look at, so no deviation slips by unseen.

<Note>
  Strata does not use load-bearing comments anywhere (see the hygiene family), so a
  suppression comment would break a rule it enforces on everyone else.
</Note>

## Compensating for LLM blind spots

Some defaults are stricter than a careful human team would choose. That is
deliberate: the target is code written at scale, often with an LLM in the loop.
Each strict default answers a specific way generated code drifts:

| An LLM tends to...            | So Strata...                                              |
| ----------------------------- | --------------------------------------------------------- |
| not see inferred types        | requires explicit annotations, including locals           |
| smear state across boundaries | requires explicit dataflow and flags outer-state mutation |
| sprawl                        | caps orchestrator function and file size                  |

"Stricter than most teams do" is usually the reason a rule exists, not an argument
against it.

## Rules claim only what they check

A rule is defined by what it **completely and honestly checks**. Strata will not
ship a rule that verifies a fraction of its stated intent and names itself after
the whole idea.

* A contract that cannot be checked properly is dropped, not described-but-unenforced.
* Detection does the real analysis, not a cheap proxy dressed up as the full rule.
* Any narrowing is an explicit, stated limit, never a silent hole.

So when a rule flags your code, it is a claim it can stand behind, which also makes
it a concrete thing to argue with if it is wrong.

## Not a style tool

Strata checks how a codebase is *organized*, not how it is *formatted*. Line length,
import ordering, unused imports, and syntax modernization belong to a formatter or a
general-purpose linter.

If Strata overlaps with another tool you already run (for example a global
argument-count limit), there is no need to run both: disable Strata's version and
keep the other tool's.