In the ACE specification or the ACE program? In case of the specification, the language is designed to be easily verifiable, also through the generated test suite. This allows a domain expert to check it, as well as a programmer if required.

In case of the ACE program, it's a program so can indeed have bugs. But at least then we only have to verify the implementation of a single program, instead of all of them.

Ace and Gherkin are related in the sense that both are ment to express program behaviour in a language that domain experts can understand. Ace is more geared towards expressing contracts. The language is designed in cooperation with lawyers to resemble traditional contracts as much as possible. Ace must have the property that one very important aspect of contracts, the handling of disagreements (or exceptions as programmers call them) can be clearly expressed.

There are other differences in approach. In Gherkin, a programmer needs to implement the test for each step manually. This has a risk of introducing bugs. To reduce that risk, Ace translates to an ethereum contract as well as a test suite.

It is not always possible to generate a complete contract. In that case a programmer has to fill in the operational details.

However, it is always possible to generate an executable test suite. This guarantees that an implementation can always be checked to conform to the contract as specified in ACE.

So any "error" (i.e. disagreement between the contract parties) when executing the contract can be traced back to: - an "error" in the ace contract (the parties agreeing to the contract should decide what to do) - an error in the ace implementation (ace has to be open source to minimise the risks here, just like the bitcoin an ethereum software)