Hi, I am the author of the blog post. The theory would be that your service is well tested enough for the produced simulation to give the majority of scenarios that you would need for tests in the consumers. I agree that perhaps there is a missing link in the consumers not knowing in advance what to call to produce certain outcomes - perhaps Hoverfly could interpret the JSON and display a contract with possible requests responses in the UI. This would be something easily understandable for a developer so they can quickly write their tests against it. Another choice would be to use something like swagger as a source for JSON rather than the service itself. This would be good for contract driven development.