{"key":"ledgerbridge_customer_config_schema_ideas_2026_03_21","title":"LedgerBridge Customer Config Schema Ideas","content":"LedgerBridge customer config schema ideas discussed on 2026-03-21.\n\nStrategic goal:\n- Push as much customer-specific behavior as possible into config instead of one-off code.\n- The more LedgerBridge becomes config-driven, the lower setup time and the better the margins.\n\nA customer config should likely capture:\n- customer_id\n- workflow/job name\n- expected input filenames\n- input file locations or intake rules\n- output filename and destination\n- column mappings for each input file\n- normalization rules for dates, amounts, statuses, and IDs\n- merge/reconciliation keys\n- handling of blanks/nulls/defaults\n- validation rules and required columns\n- archive/quarantine behavior\n- schedule metadata\n- delivery metadata\n\nPotential config sections:\n1. metadata\n- customer name\n- workflow identifier\n- schedule/frequency\n\n2. inputs\n- file names\n- required vs optional inputs\n- delimiters/encoding assumptions\n- per-file column mapping\n\n3. normalization\n- date format rules\n- case normalization\n- trimming/whitespace cleanup\n- amount parsing\n- canonical field naming\n\n4. reconciliation logic\n- join keys\n- refund/sales handling\n- matching precedence\n- duplicate rules\n\n5. output\n- output columns\n- ordering\n- file name\n- destination path or delivery mode\n\n6. validation\n- required columns\n- minimum row expectations\n- malformed input behavior\n- quarantine/archive rules\n\n7. logging and support\n- log paths\n- run identifiers\n- support notes\n\nWhat should probably remain in code instead of config:\n- core deterministic pipeline behavior\n- shared parsing/validation helpers\n- reusable transformation primitives\n- safety checks\n- test harness and execution model\n\nPractical implementation principle:\n- customer config should define what changes per customer\n- code should define how the pipeline executes reliably for every customer.\n\n---\n**2026-03-21 17:25:58 UTC | Created via MCP**","summary":"LedgerBridge customer config schema ideas discussed on 2026-03-21.\n\nStrategic goal:\n- Push as much customer-specific behavior as possible into config instead of one-off code.\n- The more LedgerBridge becomes config-driven, the lower setup time and the better the margins.\n\nA customer config should likely capture:\n- customer_id\n- workflow/job name\n- expected input filenames\n- input file locations or intake rules\n- output filename and destination\n- column mappings for each input file\n- normalization rules for dates, amounts, statuses, and IDs\n- merge/reconciliation keys\n- handling of blanks/nulls/defaults\n- validation rules and required columns\n- archive/quarantine behavior\n- schedule metadata\n- delivery metadata\n\nPotential config sections:\n1. metadata\n- customer name\n- workflow identifier\n- schedule/frequency\n\n2. inputs\n- file names\n- required vs optional inputs\n- delimiters/encoding assumptions\n- per-file column mapping\n\n3. normalization\n- date format rules\n- case normalization\n- trimming/whitespace cleanup\n- amount parsing\n- canonical field naming\n\n4. reconciliation logic\n- join keys\n- refund/sales handling\n- matching precedence\n- duplicate rules\n\n5. output\n- output columns\n- ordering\n- file name\n- destination path or delivery mode\n\n6. validation\n- required columns\n- minimum row expectations\n- malformed input behavior\n- quarantine/archive rules\n\n7. logging and support\n- log paths\n- run identifiers\n- support notes\n\nWhat should probably remain in code instead of config:\n- core deterministic pipeline behavior\n- shared parsing/validation helpers\n- reusable transformation primitives\n- safety checks\n- test harness and execution model\n\nPractical implementation principle:\n- customer config should define what changes per customer\n- code should define how the pipeline executes reliably for every customer.\n\n---\n**2026-03-21 17:25:58 UTC | Created via MCP**","status":"active","namespace":"general","namespace_name":"general","namespace_tier":"shared","tags":[]}