Yesterday I met with my supervisor, Georgios Gkoutos, and intermediary law contact, Alexandros Giagkos, in my first Major Project meeting. In that meeting I was able to clarify what my project involves.

If you’ve been following my blog, you may remember that I could interpret my project, Online Dispute Resolution for Maritime Collisions, in one of two ways:

1. A “court approximator“, taking the details of your maritime collision and comparing with historical cases to predict the outcome of your case.
2. An online platform allowing communication between two parties in a formalised way, with some specific maritime collision features such as retrieving similar cases and the ability to search other historic cases.

It turns out that what was intended was actually a hybrid of the two systems, in that I’d need to develop an online dispute resolution platform (of which there are many), but tailored specifically to maritime collisions in the types of questions that both parties are required to answer. At the end of a number of stages of questions, results for both parties are displayed, and this step involves the “court simulation” step I’d hoped would be a requirement!

Artist’s impression of the “court simulation”.

This simulation will not deliver a binary yes/no answer as to whether or not one’s case would “win”, but would render a graphical line chart showing the influencing factors (the parties’ responses to questions, similarity to historical cases, etc). Parties could see an approximation of how the court case would play out, the points at which the judge might be in favour or against them, and so on, eventually converging on a final outcome: “Taken to court, it is likely that Party A would win the case.”

Project clarified somewhat, let’s go back a step and examine the requirements in detail…

ODS – An Introduction

When it comes to resolving disputes, many people are increasingly turning to online dispute resolution (ODS) platforms as an alternative to taking the case to court. The latter puts both parties through the expense and inconvenience of having to travel to a physical court, often multiple times. ODS can settle disputes more quickly and cheaply, and arguably provides a clearer and more appropriate means of examining digital evidence.

ODS platforms already exist. They allow lawyers to open disputes on behalf of their clients, upload documents and type content in a structured manner, and hopefully reach an amicable resolution. However, they do not typically perform any processing on the inputted data; there is no business logic that helps influence the outcome. Lawyers are left to examine the viability of both sides of the dispute manually and reach a mutual conclusion, or take the dispute to court.

Online Dispute Resolution for Maritime Collisions

Online Dispute Resolution for Maritime Collisions will attempt to codify that business logic in a very abstract way. Depending on the answers to the first set of questions, the system may deliver a different subset of questions to either party. Upon answering all of the questions, a virtual “court simulation” is played out on the answers and used to approximate a decision of which party is in the right, according to maritime law.

In addition to the court simulation, I’m hoping the system will be able to analyse the details of the case, from the perspectives of both parties, and find and retrieve the most similar historic cases. Done properly, this could even influence the outcome of the decision in the court simulation.

Finally, a brief overview of the dispute may be made available to both parties, with individual comparison details such as “Party A was heading out to sea. Party B contests this.” Some details, such as the level of confidentiality of either party’s answers, need to be clarified in a later meeting. It may be that each party should only be allowed to see the overview of their own answers, not those of the other party.

Iterative Project Plan

From yesterday’s meeting, I’ve identified some incremental requirements:

1. To build an Online Dispute Resolution platform. This is the minimum viable product, and as has been pointed out, is potentially substantial enough to be a Major Project on its own, encompassing front-end development, back-end business logic and database integration. Having said that, I have been given permission to investigate open source platforms as a starting point, such as Emcod, in which case this stage may not require very much work.
2. For this Online Dispute Resolution to be tailored to Maritime Collisions, providing some sort of conclusion (I’m using the term “court simulation”) given the details of the dispute. As a worst-case scenario, this may mean hard-coding business logic, rules, database schemas, and so on, to fit with maritime collision properties.
3. For this Online Dispute Resolution to be an abstraction, able to take a module of business logic (perhaps Maritime Collisions, perhaps something else – hence the abstraction). Georgios stressed the importance of keeping this system abstract, so I will aim to develop straight to this stage, skipping stage 2. An advantage of an abstract system is that we can feed very simple business logic modules to the system, making it easy to test.
4. As an additional feature, the system should be able to retrieve the most similar historical cases, which should be of use to the lawyers involved. This will likely involve a large degree of setup work, including sourcing the cases and representing them in a consistent data structure.
5. Following on from the ability to retrieve similar cases is the ability to feed the details of the similar cases into the current dispute, thereby influencing the “court simulation” and making this feature even more accurate and valuable.

I’ll aim to start with requirement 1, following the “You Aren’t Going to Need It” principle and keeping the design simple, but also keeping requirement 3’s abstraction principle at the forefront of my mind. I hope to skip requirement 2 altogether, arriving at it via requirement 3.

Those first few requirements will be substantial enough, but if I have time I’d like to attempt requirements 4 and 5.

Other Requirements

Yesterday’s meeting suggested other, lower-level requirements:

• Confidentiality – Alexandros stressed that Party A need not know the company size of Party B, and vice-versa. Both parties have the right to be considered equal. Exactly what is and isn’t allowed to be known to both parties needs to be clarified.
• Security – this being a utility for lawyers, they need to be assured that the confidential details of their clients and clients’ disputes remains secure, and that the system is protected against XSS/CSRF/SQL injection attacks.
• Parallelisation – both parties should have an equal amount of time to formulate and submit the answers to the questions. There needs to be a fair way for both parties to agree the start and end to the window of time they’re allowed to answer each stage of questions. The system should be fair regardless of lawyer culture. For example, some lawyers follow a linear, question-by-question approach, whereas others might gather together as groups in formal meetings to tackle individual questions over a period of several days.
• Testable – the behaviour of the system should be verifiable through a suite of automated tests. At the low level, I hope to write (in whatever language I end up using) in a test-driven way, improving the low-level design of the system while producing a test suite as a by-product. At the higher level, I hope to write Cucumber features that are executable as integration tests, testing features such as logging in, uploading documents, etc. In addition to these tests, the business logic in the court simulation must also be predictable, consistent and testable.

Finally, I have my own considerations that need further discussion:

• Copyright – could this project, or a derivative of it, be a commercially viable system? If so, do the rights to the project lie with me, my supervisors, the law contact, or some combination? How will the system be used?
• License – regardless of who owns the copyright, is there a restriction on the type of license I should apply to the project? Choosing a GPL license, for example, requires making the source code publicly available, which could be a security risk*, and certainly puts the project at a commercial disadvantage. Following on from this point, I’ll be using GitHub as my version control system: am I allowed to make this a public repository, or will I need to pay for a private repository slot?
• Ethics – is there any likelihood that the system could be used by lawyers to examine a client’s case and, seeing that the court simulation is not favourable, deny vulnerable people the legal protection of their choice? I’d be interested to know the plans for the system upon its completion.

Next steps

Now that I’ve clarified the requirements of my project, I can begin to write the Outline Project Specification, which is due on Friday. I look forward to uploading it here as soon as it is ready.

* This is something hotly contested by Eric S. Raymond, author of The Cathedral and the Bazaar, who says that closed source code is “secure by obscurity, rather than secure by design” and suggests that making your project open source can actually make it more secure.