Events are part of the transaction
An event is recorded inside the same transaction as the action that raised it. If the action rolls back the event is never published, so there is no notification for something that did not happen.
HomePlatform
The platform
One action. One transaction. One version of the truth.
Corva is not a set of screens over a database. Between the interface and your business records sits a core that decides what may happen, performs it as a single atomic transaction, and records it permanently. This page is how that works.
The command envelope
Every business action runs the same five steps.
A screen does not update your records. It asks the core for an outcome, and the core walks the same envelope every time, whether the action is receiving a pallet or writing off a balance.
The envelope is the reason the system cannot drift. Validation cannot be skipped by a different caller, because there is no different caller. The ledger cannot fall behind the state, because both are written inside one transaction that either commits or disappears. And the audit record cannot be forgotten, because the same transaction that changes the record writes it.
If a rule the action depends on is not satisfied (a permission, a status, available stock, an open accounting period), nothing is written at all. A half-finished business action is not a state Corva can be left in.
One named transaction
1
AuthorizeIs this person allowed to take this action, on this record, in this tenant?
2
ValidateIs the record in a state that permits it, and is the input coherent?
3
ApplyChange state, write the inventory ledger entry, write the audit record.
4
PostIf the action has financial meaning, write one balanced double-entry posting.
5
Commit & publishAll of it lands together; business events are released for reactions.
Any step that fails ends the transaction. There is no partial outcome and no compensating clean-up job, because nothing was written.
No side doors
If it changes your business records, it is a command.
The rule that makes the rest possible: transactional data has exactly one write path. Master and reference data (customers, items, locations) is the one bounded exception, and it is audited too.
No ad-hoc CRUDThere is no generic “save this row” endpoint behind the screens for orders, shipments, invoices or stock.
One transaction eachA business action is one database transaction. Two actions never share one, and one action never spans two.
Events, not triggersReactions to an action are raised as business events inside the transaction and dispatched after it commits.
Enforced, not agreedAn automated gate fails the build if a write to transactional data appears outside a command.
The audit trail
A permanent record, not a log you can lose.
The audit trail is a core layer rather than a feature switch. It is written by the same transaction as the change it describes, which is why it cannot disagree with the record.
What gets captured
- Business events, approvals and overrides
- Status, quantity and financial changes
- Inventory movements, receipts and shipments
- Configuration and master-data changes
- Security activity: sign-in, permission changes
Each entry carries the actor, the authority they acted under, the time, and the record it touched.
Ask what happened to a unit and the answer is the whole story: when it was received and at what cost, where it moved, which order reserved it, which carton it was packed in, which shipment took it out of the door, and what it was invoiced on. Ask who changed a price or released a hold, and the answer names them.
There are no hard deletes. A mistake is corrected by a recorded reversal or an explicit correction document that leaves the original visible. Nothing quietly disappears, which is exactly what makes the trail worth trusting when a customer, an auditor or a regulator asks.
The event-driven core
Reactions that cannot be lost or fired twice.
Operations do not exist in isolation: a shipment should notify, a low stock level should flag, an invoice should reach a customer. Corva raises those as business events.
Dispatched after commit, exactly once
Events are handed to their reactions only after the transaction commits, and delivery is idempotent: a retried reaction does not double-post, double-ship or double-notify.
Status changes are modeled, not typed
Every record has a defined lifecycle. A status moves because an action moved it along a permitted path, not because someone selected a different value from a list.
Coming soon
See it applied to your flow.
The seven operational modules walk the same envelope end to end, receiving through receivables.
hello@corvaerp.com