Skip to main content

Concepts

Ballast treats configuration the way the rest of Finance & Operations treats transactions: as data with a lifecycle, a history, and controls. Four ideas carry the model.

Date-effective versions​

In standard Finance & Operations, a parameter table holds one value: whatever was typed last. Ballast replaces that single mutable value with a series of date-effective versions. Each version has a period during which it is the live configuration, and the system resolves the current value from the version that is effective now.

This one change is what makes everything else possible. Because old versions are kept rather than overwritten, history exists. Because future versions can exist before they take effect, scheduling exists. Because a version boundary is a real thing, rollback is a governed operation rather than guesswork.

Drafts​

A draft is a staged snapshot of configuration that is not yet effective. It is where change happens safely: you build the draft, review it, and compare it side by side against what is currently live to see precisely which values would change. Nothing touches the running system while a draft is being worked on.

A draft becomes real configuration only when it takes effect, either on the schedule you set or when you apply it. Until then it can be revised or discarded without consequence.

Scheduled effectivity​

A draft carries an effective date and time. When that moment arrives, the draft becomes the live version automatically. This decouples the decision from the execution: the change is reviewed and approved during business hours, and it lands at the exact cutover moment without anyone standing by. Month-end, go-live, and pricing-change cutovers stop depending on someone being awake.

Rollback and history​

Rolling back means returning to a previous version, and because versions are never destroyed, that is always possible and always clean. The rollback itself is recorded, so the history reads true: change applied, problem found, change reverted, each with a timestamp and a user.

The complete history, with side-by-side comparison between any two versions, is the audit trail controls and compliance teams ask for. What changed, when it took effect, who staged it, and what the values were before: all of it is answerable directly from the system.