When I started building Stellar ERP, I kept running into the same problem: the same piece of information could exist in more than one place.
A product could have a stock value in MARG, another value in my ERP, and then some value sitting in a frontend state somewhere. That is how systems slowly become unreliable. Nothing is obviously broken, but nobody knows which number they should trust.
So I made a fairly simple rule for myself: one source of truth should persist for each kind of data.
MARG is the source of truth
For the accounting data, MARG ERP is the source of truth.
I didn't want to build a second accounting system and then spend my time figuring out why the two systems disagreed. Stellar ERP connects to MARG and uses it as the authoritative source for things like products, rates, and accounting-related information.
That means Stellar doesn't quietly invent its own version of the same data. It can use that information in its workflows, cache what it needs, and build useful features around it, but there is still one place I can point to and say: this is the authoritative record.
That distinction became especially important when I started building stock and order workflows. The ERP needs to make decisions using current information, but it shouldn't create competing truths just because it's convenient for the UI.
One system can still have multiple responsibilities
This doesn't mean Stellar ERP does nothing with data.
MARG handles the data that belongs to the accounting system. Stellar handles the business workflows I built around it: order placement, approvals, stock visibility, manufacturing workflows, targets, dispatch, and the interfaces the staff actually use.
The important part is knowing where ownership ends.
If Stellar needs a product's accounting information, it gets that information from MARG. If Stellar needs to know whether a user is allowed to move an order to the next stage, that's a rule owned by Stellar's database.
That separation makes the system much easier to reason about.
The database gets the last word
The same idea applies inside Stellar itself.
I don't want the frontend to be the authority for permissions. A button can disappear from the screen, but that isn't security. The database needs to enforce the rule as well.
So the interface hides actions a user can't perform, while PostgreSQL enforces the actual state transitions and permissions. Row Level Security controls what data a user can access. Triggers handle important transitions and record things such as who performed an action and when.
The frontend tells the user what can happen.
The database decides what is actually allowed to happen.
Why I care about this
The more I built Stellar ERP, the more I realized that a good business system isn't just a collection of screens and APIs. It's a set of clearly defined sources of truth and boundaries.
If two systems both believe they own the same piece of information, eventually they will disagree.
I'd rather decide that ownership up front.
MARG is the source of truth for the accounting data it owns. Stellar ERP is the source of truth for the workflows and rules it owns. Within Stellar, PostgreSQL is the final authority over what the application is allowed to do.
One source of truth. Clear ownership. Fewer places for reality to disagree with itself.
That's the idea I keep coming back to whenever I add another feature.