Symmetry, Conservation of Energy and Algorithms

In Physics we know the principle of a conserved quantity. A conserved quantity is something that doesn’t change while other variables in the system are modified. For example, the total energy in a closed system can neither disappear nor can it grow over time out of nothing. The amount of energy is conserved.

Some of these conserved quantities have been discovered by physicians centuries ago by observing nature and studying its laws. Energy is one of them, also widely known are the electrical charge, the momentum and the angular momentum.

Mathematics and laws of physics

The mathematical background was discovered by Emmy Noether in 1918: each symmetry in a set of equations (i.e. the laws of physics) reveals a conserved quantity.

What does this mean for us as software engineers? The theorem of Emmy Noether is universally valid, so it can be also applied to business rules/business laws.

A conserved quantity is something that neither can be produced nor can be removed from a system. It is invariant. So in business rules, what does a conserved quantity mean?

Business Rules as “Laws”

If we treat business rules as “laws of the system”:

• They define what is allowed, forbidden, or invariant in transactions, processes, or data.
• Just like natural laws, they constrain what can and cannot happen inside the business.

So a “conserved quantity” in business would be an invariant that cannot be created or destroyed inside the system, only transferred or transformed.

Examples of Conserved Quantities in Business

Here are some concrete cases:

• Money in Accounting:
  • Within double-entry bookkeeping, money isn’t created or destroyed by transactions, it only flows from one account to another.
  • The sum of debits = sum of credits is a conserved invariant.
  • Violating it means the rules are broken.
• Customer Loyalty Points:
  • Points can move between accounts or be exchanged, but the total issued vs. redeemed must balance.
  • If points just disappear (without being redeemed) or appear (without being issued), the system is inconsistent.
• Inventory Units:
  • Stock levels follow conservation.
  • Items don’t “vanish” or “appear”, they are either sold, shipped, or produced according to rules.
  • A warehouse system models this conservation explicitly.
• Information in Workflow Systems:
  • A “case ID” or “contract ID” can change state, but it never ceases to exist arbitrarily.
  • That identifier’s persistence is a conserved aspect.

Symmetries and Invariants in Business Rules

In physics, invariance under transformations reveals conserved quantities.
In business, invariance under process changes reveals what is conserved:

• Time invariance
  → rules hold regardless of when the transaction happens.
  → Example: accounting rules apply identically in January and in June.
• Organizational invariance
  → rules hold across departments.
  → Example: a product SKU is the same “thing” in sales, logistics, and finance.
• Workflow invariance
  → rules hold across process states.
  → Example: an invoice remains tied to a purchase order no matter its approval stage.

Each of these invariances suggests a conserved element (money, item, identifier, rights, obligations).

Why It Matters for Software Engineers

For us, this perspective helps in system design:

• Identifying invariants: what must never be violated (e.g., balance sheets, transaction logs, legal constraints).
• Designing checks: enforce invariants through validation, constraints, or event sourcing.
• Modeling flows: think in terms of transfers and transformations of conserved quantities, not arbitrary changes.
• Detecting bugs: if a “conserved quantity” seems to change without cause, there’s likely a data integrity issue.

---

From symmetries to invariants (a Noether-ish view)

• Time-shift symmetry (API behaves the same today and tomorrow)
  → constant secrecy/integrity despite more calls (rate limits, per-user caps, nonce spaces sized for lifetime).
• Permutation symmetry (message order shouldn’t help attacker)
  → use sequence numbers/associated data to fix ordering; reject replays.
• Context symmetry (same primitive across domains)
  → break symmetry on purpose with domain separation (different labels/“info” strings) so one domain’s queries don’t lift to another’s.

“Conservation checks” you can automate

• Entropy health: track rng failures, fork/reseed events, low-entropy platforms (early boot).
• Nonce reuse detector: per key/algorithm, scan telemetry for repeats (GCM reuse is catastrophic).
• Forging attempts: MAC/signature failure rates; spikes can indicate oracles/leaks.
• Replay counters: unexpected duplicates per peer/channel.
• Ledger drift: sum(debits) - sum(credits) == 0 per period and per asset.
• Key-age & exposure: keys exceeding TTL; keys used across domains (violate separation).