Brain

LedgerBridge customer config schema ideas discussed on 2026-03-21. Strategic goal: - Push as much customer-specific behavior as possible into config instead of one-off code. - The more LedgerBridge becomes config-driven, the lower setup time and the better the margins. A customer config should likely capture: - customer_id - workflow/job name - expected input filenames - input file locations or intake rules - output filename and destination - column mappings for each input file - normalization rules for dates, amounts, statuses, and IDs - merge/reconciliation keys - handling of blanks/nulls/defaults - validation rules and required columns - archive/quarantine behavior - schedule metadata - delivery metadata Potential config sections: 1. metadata - customer name - workflow identifier - schedule/frequency 2. inputs - file names - required vs optional inputs - delimiters/encoding assumptions - per-file column mapping 3. normalization - date format rules - case normalization - trimming/whitespace cleanup - amount parsing - canonical field naming 4. reconciliation logic - join keys - refund/sales handling - matching precedence - duplicate rules 5. output - output columns - ordering - file name - destination path or delivery mode 6. validation - required columns - minimum row expectations - malformed input behavior - quarantine/archive rules 7. logging and support - log paths - run identifiers - support notes What should probably remain in code instead of config: - core deterministic pipeline behavior - shared parsing/validation helpers - reusable transformation primitives - safety checks - test harness and execution model Practical implementation principle: - customer config should define what changes per customer - code should define how the pipeline executes reliably for every customer. --- **2026-03-21 17:25:58 UTC | Created via MCP**