Not a random feature bundle. Three independent, hardcoded modules, each a targeted answer to the strongest attack a critical board, an auditor, or opposing counsel could bring against this architecture.
LOFSL stands for Legal Oriented Formal Specification Language, a domain-specific language in which legal rules are formally described. The compiler generates a machine-checkable proof object from a rule, certifying three properties: DETERMINISTIC, no random or time-dependent logic. TERMINATION_FREE, no loops, the rule always terminates. SCOPE_CONFORMANT, every check references a declared scope.
Until now, a board had to trust that engineers translated a legal text into code correctly. With LOFSL, a certificate exists that an external auditor can verify without understanding the entire source code.
A proof that a check passed against a specific value, without revealing the value itself. Instead of a full zero-knowledge proof (SNARK/PLONK), which requires native libraries and does not run on a pure serverless platform, we use an HMAC commitment plus Merkle proof, the serverless-compliant variant with the same privacy property.
A bank must prove to a counterparty bank that a company's beneficial owner is not on a sanctions list, without disclosing the name, unless a court orders disclosure. Until now there were only two poor options: reveal the name, or merely claim “check passed” with no forensic proof.
The counterparty bank sees a commitment, the predicate, the result, a valid Merkle proof. No name. Should a court order disclosure, a 3-of-5 Shamir quorum would have to grant release, only then is the salt published and the commitment resolvable. Without quorum, the PII stays sealed, even platform administrators cannot reconstruct the value.
A periodic service designed to anchor the Merkle root of all sealed receipts across multiple independent, non-US-jurisdiction witnesses. Until now, the evidence chain lived purely internally, in the platform's own database. A critic could argue: platform operators could tamper with the logs after the fact. External, independent anchoring is meant to close that argument.
Non-US jurisdictions are a deliberate choice: the US Cloud Act allows US authorities access to data held by US cloud providers. If anchoring sat with a US witness, US authority access could influence the evidence chain. Germany, Switzerland, and Luxembourg as jurisdictions make the chain Cloud-Act-resilient, conceptually.
The three modules are architecturally complementary, each closes a different argument. Together they deliver technical demonstrability, data-protection conformity, and forensic independence, in a combination that is capital- and know-how-intensive to replicate.