Context
Currently the LLM extraction config lives under [llm.extraction] as a parallel override to [llm.chat]. Both inherit from [llm].
With the addition of [extraction.ocr] in #729, all extraction-related config would read more naturally grouped under [extraction]:
[extraction]
enable = true
[extraction.llm] # currently [llm.extraction]
provider = "anthropic"
model = "claude-haiku-3-5-20241022"
[extraction.ocr]
enable = true
confidence_threshold = 70
Trade-offs
- Pro: All extraction config in one subtable, easier to find
- Con: Breaks the current symmetry where
[llm] is the base and [llm.chat]/[llm.extraction] are parallel overrides
- Con:
[llm.chat] would be the only pipeline override left under [llm], making the inheritance pattern asymmetric
Migration
Would need TOML key + env var deprecation entries for the old paths, following the same pattern as other renames in migrateRenamedKeys / envRenames.
Context
Currently the LLM extraction config lives under
[llm.extraction]as a parallel override to[llm.chat]. Both inherit from[llm].With the addition of
[extraction.ocr]in #729, all extraction-related config would read more naturally grouped under[extraction]:Trade-offs
[llm]is the base and[llm.chat]/[llm.extraction]are parallel overrides[llm.chat]would be the only pipeline override left under[llm], making the inheritance pattern asymmetricMigration
Would need TOML key + env var deprecation entries for the old paths, following the same pattern as other renames in
migrateRenamedKeys/envRenames.