Validation, serialization, value choices, CLI flags, all follow from writing the field itself. For example, this statement creates a colors field that only accepts certain values and can be set both with comma-separated values (--color "blue,red"") or explicit lists:

# Color type with restricted values
ColorType = Choice(["red", "green", "blue"]) 
# List that can parse/serialize comma-delimited color names
ColorList = CommaSeparated[ColorType]

# List of colors with CLI flags
colors: Annotated[
    ColorList,
    CliFlags(["color", "c"]), # creates --color/-c CLI flags
] = Field(
    default="green",          # default value
    description="...",        # info string for --help and CLI errors
)

# Usage
#   YAML: `colors: green,blue`
#   CLI:  `--colors "blue,red"`

A common example is mapping CLI flags to their config value, which usually involves maintaining a parallel dict that references fields by string name and needs to be manually kept in sync with the config itself:

class BadSettings:
    foo: str
    bar: str | None = None
    baz: int  # We added baz, but forgot to add its CLI flag below

# If any field gets renamed or deleted, someone has to remember to change it here.
CLI_FLAGS = {
    "foo": "foo",
    "f": "foo",
    "bar": "bar"
}

# Requires merging the CLI data into config fields 
for flag, value in cli_data.items():
    if (field := CLI_FLAGS[flag]):
        setattr(config, field, value)

With Notifig, the CLI flags live on their respective field declarations. Deleting or altering a field and all its flags only touches one statement, in a single place.

class Settings(Config):
    foo: Annotated[str, CliFlags("foo", "f")] = Field(description="Value of Foo")
    bar: Annotated[str|None, CliFlags("bar")] = Field(
        description="Name of Bar, if any",
        default=None,
    )
    baz: int = Field(description="Amount of Baz")

An application's structure hierarchy should map to its config structure. Each component declares its own config section with the fields it needs, and does not need to be

Adding, changing or deleting an entry should able to trigger behavior instead of relying on periodic checks. An observer is a callable or coroutine registered to a path, and it's called whenever it is altered. A simple example where changing a UI's theme causes it to redraw:

class UIConfig(ConfigSection):
    theme: Annotated[Choices(["dark", "light"])] = Field(default="light")

class Settings(Config):
    ui: UIConfig

config = Settings()

# sync observer that logs every change
@config.on_change()
def print_changes(section: ConfigSection, changes: tuple[Change]):
    for change in changes:
        print(f"Change of type {change.__class__.__name__} on {change.path}")

# async observer
@config.on_change("ui.theme")
async def redraw_theme(section: ConfigSection, changes: tuple[Change]):
    await interface.update_theme(section.ui.theme)