A business engine must remain useful beyond its first release: rules evolve, history must stay interpretable, and surrounding systems need room to grow.
Plugin upgrades across a shared history
The goal is to activate versions at explicit cluster boundaries while preserving service continuity and the interpretation of historical commands.
- Identify the exact engine, data format and plugin versions.
- Prepare a new version and agree on its activation point in the transaction history.
- Use the correct version for ongoing requests, history replay and recovery.
- Preinstall plugins locally so startup and operation work without a remote storage service.
The upgrade path covers version preparation, compatibility, state migration, rollback and historical-version retention.
Auditability: trace every transaction and every core record
The goal is to replay committed history into linked, blockchain-explorer-style views: from a transaction to the data changes it made, and from a record back to the transactions that changed it.
- By transaction: inspect original input, data-format and plugin versions, results and the records created, updated or deleted.
- By record: inspect each change, its transaction and the before/after versions.
- Verify execution: replay from a trusted historical state using the matching versions, then compare results and hashes transaction by transaction.
Audit views link record revisions and transaction hashes with archived inputs, historical plugins, and trusted reference states and hashes. Discarded history cannot be reconstructed from a snapshot or hash alone.
Business-invariant checks at execution and snapshot loading
Business code declares conditions that must always hold, such as balanced ledger sides, non-negative available balances or exclusive seat allocation. The checks are being implemented for both transaction execution and snapshot loading. Rule versions must be consistent between execution and replay, and recovered state that fails a check must not be activated.
Checks distinguish business rejection from execution fault: an execution fault while applying a committed command in Performance mode stops the node, and a failed snapshot check prevents the recovered state from being activated. Existing schema validation and divergence checks cover separate boundaries.