Semantic programming. A contract driven approach.

In this blogpost, we argue that developing code should be replaced by developing models and writing contracts as part of those models. Our argument is that humans can understand models of reality (even complex ones), but they cannot understand programming code beyond a certain point of complexity. This non-understanding of program code leads to huge IT-failures.

The price of software you don’t understand

A recent study in The Netherlands alone, showed that large IT-projects issued by Dutch government resulted in an annual loss of 5 billion euro’s (which was about the same as the annual national deficit at that time). We can probably all come up with examples of IT-projects that have failed miserably in the past, and we will probably also be able to come up with examples that will fail miserably in the future. Let’s just face some facts: software is hard to write, it’s also hard to read, and domain experts (people who will use the software) cannot validate software correctness. Non-validated software can be hazardous, especially when reliability and safety issues are at stake. These risks can be financial, legal, health related, system critical etcetera. What can we do about this?

Tests are not sufficient

Software is a means to an end; the end being a product (an artifact) satisfying the needs of end users. Software is the stuff that makes the product work. Validating a software product means that we have to establish that the product will always work (under given circumstances). Validated software reduces risk. Current validation practice, however, boils down to testing the software. To quote the famous Dutch computer scientist Edsger W. Dijkstra: “testing can only prove the existence of bugs, but not their non-existence”. Software that is validated by testing is always a risk (and if the testing is not done rigorously, the risk will be considerable). Risk-sensitive software seriously deserves our special attention.

Models as code

Most programmers usually start writing programs (after initially having gathered requirements in some way) in languages like java, c or python, and they develop trust in those programs afterwards by testing them. We claim that there is a better way, namely by first developing models of the software, before developing code. A conceptual model is a design of a software system that is independent of any software architecture or programming language. The reason is simple: unlike software, models can be validated. Once you’ve found the goals and critical success factors (functional and nonfunctional) of end users of the software system, you can put them into a conceptual model that can be understood both by the business (domain experts, end users) and by the software developers. Once you have validated the correctness of the model, you translate the model to code. Preferably automatically (compile!). If you can trust your compiler, then you can also trust the code. This is the starting point for a new way of systematically developing software systems.

Is this a new idea? Certainly not. In the 90’s, the OMG had introduced the Model-Driven Approach (MDA) to develop software. The basic idea was that by compiling models from UML, you could generate Java code. Was the MDA is success? Yes and No: the idea was great, but the execution a failure, mainly because the UML models as a starting point were insufficient. In particular, UML class diagrams are notorious for bad semantics and ambiguities. Is there a way to remedy this situation? In other words: are we now equipped to revisit the MDA and to really start doing the job of validating software by first validating the models on which they are based? The answer is yes, and Contracts11 is one of the companies that has established that it can be done.

ACE, a semantic programming language

What constitutes a good conceptual modelling language for software products? A good modelling language should be easy to read and to write. It should also be expressive enough to capture all your (non)functional needs. The models should be understandable by both the business (domain experts, end users) and software developers. The modelling language should be sufficiently precise and unambiguous to offer a basis for compilation to code. At Contracts11, for example, we have designed a structured natural language that satisfies the above-mentioned criteria of a good modelling language for software. The language is called OLE (Objects, Logic and English) and was later augmented with the concept of Contract, establishing the ACE language (Automated Contracts in English). ACE can be read by both the business and by software developers, and be compiled to code (SQL, Datalog, Solidity). Hence, if you can trust the correctness of your ACE model, you can trust the correctness of your code. In this sense, a language like ACE is a high-level programming language, that defines the semantics of a lower-level executable program. Contracts11 coins this kind of programming as “semantical programming”. So, how do you go about to write correct models?

Contracts in business processes

Key to writing good models for software are the concepts of “business process” and “contract”. Data only makes sense when you know the context in which the data is used. Logicians have known this for a long time, and in terms of software systems, the context in which the data is used, is the business process. Hence: no data, without a business process. So, we start from a business process, which can be modelled by, e.g., BPMN (Business Process Modeling and Notation), the state of the art in business process modelling. Hence, the BPMN model serves as the context in which we define the data. The BPMN model tells us how the data will be used. As Wittgenstein said: “Don’t ask for the meaning, ask for the use”. We must now try to locate the minimal set of data that is needed to support the business process. How do we find this data? The connection between process and data is a so-called contract. Contracts are written as an agreement between the initiating party of an activity of the process and the receiving party of that activity (the recipient consumes/uses the result of the activity). The input has to comply with a so-called pre-condition, and the result has to comply with a post-condition. By analyzing the constituents of a contract, one can see just what kind of data is involved in writing the pre- and post-conditions of that contract. So, from the business process, together with the contracts that tell how to handle the activities inside a process, one gets a complete overview of the data that is necessary to correctly run the process. Contract specifications can be written, for example, in the high-level ACE language, which can be validated by all stakeholders involved (domain experts, end users, and software developers).

Validating a model

How can you validate a model? In Design Science, developers use the so-called Design Cycle (also known as the Regulative Cycle) to systematically debug models and prototype versions of products. After running the cycle a number of times, the model will constantly be improved by the feedback offered (both by domain experts, end users, and software developers) to eventually converge to a stable model, i.e. a model that has been accepted by all stakeholders involved. This end model has been accepted by all stakeholders as the conceptual blueprint of the desired software system. By definition, we have thus obtained a validated model. By employing the Design Cycle in this way, we have actually constituted a process of Agile Modelling.

Towards better software systems

We think that the only way in which we will ever be able to write software systems that we can trust, is by first placing our trust in models of a software system that we can understand and that we can systematically validate. By modelling a system as a process governed by contracts defined by pre- and post-conditions, and by employing agile techniques, we can arrive at a complete and validated conceptual blueprint of a software system. This blueprint can then be compiled to actual software. This is what we mean by Semantic Programming.

Want to know more? Contact us at

Herman Balsters, PhD  & Henk Doornbos, PhD -

1 Smart Contracts will never work if we treat them as normal programs

Smart Contracts will never work if we treat them as normal programs

For some reason, we have a strange tendency to call things “smart” as soon as we take the human out and replace it with code. We do it with the Internet of Things, calling things “smart” as soon as they have a processor and a connection, and we’re doing it again with smart contracts. If we normally call someone or something “smart”, what we normally understand is that it is capable of intelligence and reasoning, to make its own choices and interpretations. Code however is exactly not that.

If the recent issues around The DAO show anything, it’s that replacing the human with code doesn’t add any “smartness”. It rather removes it, leaving only the deterministic instructions created by a programmer behind. Including its flaws. Code is a deterministic calculation, unable to deviate from its programming and as such incredibly dumb. Capable, but dumb.

Smart contracts will not work with the approach currently chosen by the Ethereum team. Using a JavaScript-like language to create programs that interface directly with money is inherently flawed. And this is not only because of the underlying issues in Ethereum. Rather it is because such a language is too low level to express the concepts involved.

Contracts have to be expressed in a very precise language. That’s why we have lawyers and they have their own legal language in which they write contracts (which also serves to obfuscate contracts in some cases, but it is precise). Programming languages are very precise, so they might seem like a natural fit for writing contracts in. That is until you consider the huge gap of abstraction between legal language and a programming language. It’s like forcing a programmer who has only ever programmed in Java to build its own CPU. It’s not even in the same ballpark.

The fact that Solidity (the language based on JavaScript) was created as language for Smart Contracts on Ethereum shows how incredibly disconnected from the real world the Ethereum developers are. On the one hand, it is very much to be expected; if the only thing you have is a hammer, everything looks like a nail. If the only thing we have is languages like JavaScript, every problem might look like something you can solve using it.

At the same time however it is a mind boggling choice. Everyone who has ever programmed anything serious before should know that every program is riddled with bugs. Normally we don’t have to worry about that too much, because it’s easy and fast to quickly fix any issues that pop up. But in Ethereum and in the current concept of Smart Contracts, as soon as the code is running, it can’t be modified anymore. So your software has to be bug free.

However, it takes an herculean effort to create software that is relatively free of bugs. Such an effort and investment is only made by organizations such as the NASA, and even then gives no guarantees. No real world process where the stakes are high can afford such an investment and risk.

The DAO is a great example of how this went wrong. The developers of The DAO, as well as of Ethereum, are all incredibly intelligent people, and are very good at what they do. However, they are programmers, and they write programs, and they introduced a bug. Probably more than one. There’s no way back, no way to patch the bug, write a database migration and move on. So now we’re stuck, and $50 million dollar is up for grabs.

The way forward

What we need is a language that is precise enough to write contracts in, while also being of a sufficiently high level of abstraction that it can be written, read and verified by the domain experts. The contracts written in this language should be executable, but also automatically verifiable.

Programming languages are obviously not a good match for this, so this is why we’ve developed ACE (Automated Contracts in English). ACE allows you to write contracts on a much higher level of abstraction. An example to give a general idea:

-- total number of tickets: a Number
-- number of scanned tickets: a Number
-- Account A is organizer: True or False

-- Creator is organizer
-- Creator is scanner
Conditions that must be true at all times:
-- for all accounts A: NOT (A has a scanned ticket AND A has an unscanned ticket)
-- total number of tickets >= 0
Query: what is the total number of tickets?
Provided that:
     -- Initiator is organizer
The answer is: total number of tickets
Operation: add Number N tickets
Provided that:
    -- Initiator is organizer
    -- N > 0
The result is:
    -- total number of tickets = OLD total number of tickets + N
    -- number of unsold tickets = OLD number of unsold tickets + N
    -- number of scanned tickets = OLD number of scanned tickets

Oh and we haven’t just designed a language. We’ve also developed a compiler that compiles this ACE contract to code that can run on the Ethereum blockchain. On top of that, it also generates a test suite that can be used to verify the implementation. And it can also be compiled to other environments of course, as smart contracts are also a very useful concept outside the blockchain world.

This approach keeps the domain expert in control of the contract and bridges the gap in abstraction. We’ve actually tested it in practice with the development of real legal contracts and it actually works very well. It turns out that lawyers are, not surprisingly, extremely good at writing smart contracts when given the right tools. They are incredible at finding exceptions and patching them, as long as they understand what is happening.

We think Ethereum is a great experiment, but should be seen as a step in developing the infrastructure. However, if we want to solve real world problems with Smart Contracts, we have to develop tools that involve the real world. We develop these tools such as ACE, and we are always looking for more use cases to apply our approach. So if you’re interested, make sure to contact us at

Binding the EU: Peer-to-peer trading using smart contracts

What largely binds the EU together is the trading of physical goods. One could argue that the easier the trade, the stronger the bond. So Europe would really benefit from taking away the current boundaries in international trade. The boundaries are not just physical though. A large part of every transaction takes place at the information level. For every crate of Chianti shipped from Italy to The Netherlands a large number of documents are written, contracts signed and mails sent. This means that making trade less cumbersome means taking the hassle out of the informational side of transactions.

Continue reading

Smart Factories 4.0

Met behulp van smart factory technieken kunnen producten veel minder standaard worden en veel beter aangepast worden aan een specifieke vraag.

Centrale productie is daarom lang niet altijd meer nodig. Verder kunnen netwerken van smart factories door middel van ICT heel goed samenwerken om hun maatwerk producten samen te voegen tot samengestelde producten. De toekomst ziet er daarom zo uit:

Situatie 1. Vraag gestuurd
Een partij meldt zich bij het netwerk een vraag die opgelost moet worden.

Situatie 2: Aanbod gestuurd
Aanbieders in het netwerk zoeken actief de vraag die bij hun aanbodrichting past.

In beide situaties vindt het netwerk daarna een aantal mogelijke oplossingen die uitvoerbaar zijn door een combinatie van smart factories. Daarna wordt er onderhandeld over de voorwaarden en, als er overeenstemming is bereikt, wordt het product gemaakt en geleverd.

Web11 conference

Until this point, we have been continuing our research and development based on ideas worked on for years. We developed a method to design a process for a software system of any size, as well as the data model, with accompanying tooling.

Continue reading