Live Provider, Thin Client
When pipelines are rows, an application needs a way to see current rows without becoming a second persistence owner. Reading the database directly from every CLI and UI duplicates validation, archival rules, and version semantics. Loading a static copy at startup avoids duplication but makes edits lie until the process restarts.
A provider boundary solves both problems. One component owns row validation and storage, then exposes current pipeline data through a narrow query interface. Clients ask for list, get, or resolve. They do not know table layout, and they do not cache longer than the contract permits.
Live does not mean unversioned. Every returned row carries its version and archival state, so a brief can stamp what it materialized. The provider may refresh on each request or use an explicit invalidation strategy; either way, clients can distinguish current catalog state from the frozen version attached to historical work.
A thin client still owns presentation and intent. The CLI chooses human-readable errors and command grammar. The UI chooses sorting, forms, and confirmation. Thin means it delegates persistence semantics, not that it becomes a pass-through with no product judgment.
Test Without Restart
Create a row, query it through the client, edit the row, and query again in the same process. The second result must show the new version while an older materialized brief retains its stamped version. That paired assertion proves liveness and history instead of testing only one side.