When a domain operation can't be made fully side-effect-free -- for example, Account.debit(amount) must mutate the balance -- how can assertions be used to keep that side effect's contract explicit, and what's the practical failure mode if a team relies on Java's assert keyword for this in production?

## What an assertion states Assertions, in the Supple Design sense, are explicit statements of: - what must be true before an operation runs (**preconditions**), - what must be true after it completes (**postconditions**), - what must remain true throughout an object's life (**invariants**). For a mutating method like `Account.debit(amount)`, that means writing down -- as executable checks, structured comments, or both -- that the precondition is `amount > 0` and `balance >= amount`, and the postcondition is `balance_after == balance_before - amount`, with the invariant that `balance >= 0` always holds after any operation completes. The mechanism is deliberately lightweight: it doesn't require a formal proof system, just making the contract explicit enough that a reader, or a test, can verify it without tracing every call site that might invoke the method. ## Why the technique exists This exists because not every operation can be made side-effect-free; something in the system has to change state eventually. When a method must mutate, the interface's name alone, however intention-revealing, can't fully convey the exact contract of that mutation -- 'debit reduces the balance' doesn't tell a reader whether a debit that would overdraw the account throws, clamps to zero, or silently goes negative. Assertions close that gap: they narrow the black-box nature of a necessary side effect down to a precise, checkable statement, which keeps the interface trustworthy even for the minority of operations that Supple Design's other tools, like side-effect-free functions and closure of operations, can't eliminate. This is what keeps a large, evolving model safe to refactor -- you can change debit's internals freely as long as its asserted contract still holds. ## The assert-keyword trap The most important practical trade-off is the gap between assertions as a design or documentation technique and Java's, and Kotlin's when compiled to the JVM, built-in `assert` keyword, which is **disabled by default** -- the JVM ignores assert statements entirely unless started with the `-ea` flag. Teams that write `assert(amount > 0)` and consider the contract 'enforced' are frequently wrong: in most production deployments, that line executes as a no-op, and the precondition it was meant to guard silently stops being checked. The correct trade-off: - reserve the language `assert` keyword, if used at all, for cheap internal sanity checks that are acceptable to lose in production; - express anything that must actually be enforced as explicit validation: `require()`/`check()` in Kotlin, or an if-then-throw in Java, both of which always execute regardless of JVM flags. ## How it fails in practice The failure mode plays out concretely: 1. A service passes automated tests in CI, often run with assertions enabled via a test runner flag, but ships to production where `-ea` was never set, so a negative debit amount that should have been rejected instead silently corrupts the balance, and the bug isn't caught until reconciliation weeks later. 2. A related failure is checking an invariant only in the constructor, so a freshly created `Account` can't start negative, but not after every mutating method, letting a bug in a later-added `applyPenaltyFee()` push the balance negative without anything catching it. 3. A third failure is documenting a precondition in a comment that drifts out of date as the method evolves, because a comment, unlike an executable check, isn't caught by a test failure when it becomes wrong. ## A contract that always executes A robust version of `Account.debit(amount: Int)` in Kotlin would open with `require(amount > 0)` and `check(balance >= amount)`, both of which always execute, perform the mutation, and could optionally close with a postcondition check like `check(balance == balanceBefore - amount)` to catch a bug in the arithmetic itself, useful especially while the method is still evolving or under test. Framing the contract this way means a code reviewer, a new team member, or a future refactor of the internal storage, say moving from an `Int` field to an event-sourced ledger, all have one place to check what 'correct' means for this operation, without depending on a JVM launch flag that most teams forget is off by default.