Thank you for the useful remarks. It depends on the nature of your task, doesn't it? In most cases, a solution relating (real-life) actors, processes and objec

Thank you for the useful remarks. It depends on the nature of your task, doesn't it? In most cases, a solution relating (real-life) actors, processes and objects they handle can (and will) be described in plain text. In an Enterprise environment, this may be part of the project specification. However, the actual implementation will be specified as source code. To an extent this may even apply to purely technical projects. In a larger team, creating this specification of a project is typically part of a project manager's job. However, in a smaller team or start-up, these roles may merge and are not as clearly defined. This is especially true, if the team is focussed on both building a product and working with (potential) customers. And of course, it's up to you to decide whether Kozo will be useful for you once it is released. ;)