I’m now a Grad Certificate student in New Technologies Law at the Australian National University (ANU for locals). I have enrolled in a unit called The Law of Weaponry and Targeting. The unit is a fascinating unit convened by Dr William Boothby or rather, Air Commodore Bill Boothby (Retd). Take your pick.
‘Bill’, as we know him in class, served for 30 years in the Royal Air Force Legal Branch, retiring as Deputy Director of Legal Services in July 2011. In 2009 he took a Doctorate at the Europa Universität Viadrina, Frankfurt (Oder) in Germany and published ‘Weapons and the Law of Armed Conflict’ through OUP (now in its 2nd Edition) in the same year. His second book, ‘The Law of Targeting’, appeared with the same publisher in 2012. He has been a member of Groups of Experts that addressed Direct Participation in Hostilities and that produced the HPCR Manual of the Law of Air and Missile Warfare, the 2013 Tallinn Manual on the Law of Cyber Warfare and the Leuven Manual on Peace Operations Law. His third book, addressing Conflict Law, was published in 2014. In March 2018, with Prof Wolff Heintschel von Heinegg, he published with CUP a Detailed Commentary on the US Department of Defense Law of War Manual and his edited volume on New Technologies and the Law in War and Peace was published by CUP in December 2018. He teaches at the Australian National University, at the University of Southern Denmark and at the Geneva Centre for Security Policy.
It’s such a rich unit facilitated with plenty of discussion and hypotheticals. The class is a cross section of people like me, who are interested in autonomous weaponry from a technical perspective or other aspects of technology and war, including serving military personal (but note they don’t ask too many questions), ex-military (who ask way too many questions) and the curious (who offer a fresh perspective). Bill keeps us marching in an orderly fashion away from the fog.
The video above is not part of the unit but if you are interested in an introduction to the general themes, it is a good starting point. On the other hand, if you want to learn about military targeting; whether to toss loft a bomb or use a laser guided LGB; shoot down a civilian aircraft behaving in a hostile manner, booby-trap a water installation; then Bill is your man.
Back to the video (Source https://www.icrc.org/en/document/rules-war-nutshell ICRC). the video illustrates that people have always used violence to settle disputes. And all cultures have always had the idea that there have to be limits on that violence, if we are to prevent wars from descending into barbarity. For instance, there are rules protecting non-participants, prisoners and the wounded. These rules are set out in international humanitarian law. Yes, even wars have limits. And attacking civilians constitutes a war crime. The video explains these issues in a simple way.
When the invention in substance lies in the application of computer technology (for example a technical solution to a technical problem) or in an improvement in computer technology, it will generally be considered patent eligible, subject to other requirements.
For example, a claim directed to computer processing apparatus for assembling text in Chinese language characters using a non-Chinese keyboard (CCOM v Jiejing 28 IPR 481; (1994) AIPC 91-079) and the production of an improved curve image by computer (International Business Machines Corporation v Commissioner of Patents (1991) 33 FCR 218) have been held to be patentable.
The described apparatus in a broad sense consisted of conventional computer equipment including a database, a visual display and a keyboard. Generally, CCOM claimed an interface with a database that contained a data structure of Chinese language characters which encoded strokes by stroke type and in an order in which the strokes are written (if writing by hand). The claim also defined software that presented the strokes on the display for the user. The interface also provided a retrieval program and graphic representation of each character that enabled the user to select the character using the keyboard. The overall outcome was an efficient way of retrieving Chinese characters. Cooper J found that:
“The NRDC Case (102 CLR at 275-277) requires a mode or manner of achieving an end result which is an artificially created state of affairs of utility in the field of economic endeavour. In the present case, a relevant field of economic endeavour is the use of word processing to assemble text in Chinese language characters. The end result achieved is the retrieval of graphic representations of desired characters, for assembly of text. The mode or manner of obtaining this, which provides particular utility in achieving the end result, is the storage of data as to Chinese characters analysed by stroke-type categories, for search including ‘flagging’ (and ‘unflagging’) and selection by reference thereto.”
While the decision did not say it, an improved data structure that facilities the easier or improved finding of items in a computer implemented searching device has a material advantage. It is not business administration, nor merely information.
This decision makes it apparent that software related inventions can be patentable in Australia.
The use of a mathematical formula in a computer to produce an improved curve image was held to be patentable, since the production of the improved curve image is a commercially useful effect in computer graphics. Specifically Burchett J found:
“Although there was nothing new about the mathematics of the invention what was new was the application of the selected mathematical methods to computer, and, in particular, to the production of the desired curve by the computer. This involved steps which were foreign to the normal use of computers and, for that reason, were inventive. A method of producing that by computer, which is novel and inventive, is entitled to the protection of the patent laws.”
The use of floating point arithmetic was common for processing such algorithms for generating curves (having problems of lack of speed and inaccuracy). This invention however, claimed that calculations were performed without the use of floating point arithmetic. At the time of the invention it was new and non-obvious to perform such mathematical algorithms in a computer, using something other than floating point arithmetic (more specifically, integer arithmetic). This integer arithmetic, as described in the specification, comprised a particular way of performing calculations using components of a computer that changed the way a computer normally worked. It followed that the claim was directed to a process containing steps that was foreign to the normal use of computers.
A mathematical algorithm is a procedure for solving a given mathematical problem, commonly applied in the field of computer software related inventions.
In Grant v Commissioner of Patents [2006] FCAFC 120, the Full Court stated:
“It has long been accepted that ‘intellectual information’, a mathematical algorithm, mere working directions and a scheme without effect are not patentable.”
However, while a mathematical algorithm per se may not be a manner of manufacture, the presence of such an algorithm within the steps in an otherwise patentable method does not exclude a claim from patentability. For example, in Re International Business Machines Corporation v Commissioner of Patents [1991] FCA 625 the Court, in considering a method for producing an improved (i.e. smoother) visual representation of a curve, found (at [16]) that:
“In the present case, it seems to me that the use of the algorithm is not different conceptually from the use of the compounds involved in National Research and Development Council. Just as those compounds were previously known, so here, it is not suggested there is anything new about the mathematics of the invention. What is new is the application of the selected mathematical methods to computers, and in particular, to the production of the desired curve by computer. This is said to involve steps which are foreign to the normal use of computers ….”
The distinction to be drawn is between a claim to an algorithm (or scientific principle or natural phenomenon) in the abstract sense and the application of the formula to a process such that it produces
some advantage which is material, in the sense that the process belongs to a useful art as distinct from a fine art.
Examples of inventions involving mathematical algorithms that would be patentable are:
any otherwise-patentable process which uses a specific algorithm or mathematical formula, e.g. a claim to a method of annealing a tungsten alloy where: the heating time (seconds) = 6.78 mass of ingot/temperature (C).
a method that generates a more accurate measurement/calculation of an amount of oil in an underground deposit using a mathematical algorithm to process measured input data. Here the invention can be classified as technical or practical.
Examples of inventions involving a mathematical algorithm that would not be patentable are:
a method that uses an algorithm to calculate data indicative of success of aspects of commerce such as investments. Here the invention is akin to business innovation as opposed to technical innovation, being in an abstract art of organising or analysing human activity.
a pure mathematical formula (unapplied), e.g. a claim to a method of calculating a value c, where: c = ex sin (t)
A paper delivered at the Commonwealth Administrative Appeals Tribunal (AAT)
Seminar on Reasons at Sydney on 17 August 2016 by By Mark A Robinson SC
In writing reasons for decisions, one is best guided by becoming aware of and applying the more general rules that apply to other State and Federal Tribunals and quasi-judicial decisionmakers in Australia. The extent of the reasons given by the Tribunal here should be so much as is necessary to properly and fully record the real or actual reasons for the decision (or draft or interim decision) and it should identify:
the statutory power(s) being exercised;
the documents, material, policy or matters taken into account;
the findings on material questions of fact; and
the reasoning process leading to the conclusions made.
The Tribunal may take guidance in this task from a number of useful sources. One recent source is the High Court decision in In Wingfoot Australia Partners Pty Ltd v Kocak (2013) 252 CLR 480, the High Court determined (in a Victorian workers compensation statutory regime concerning a Medical Panel) (at [55]), in relation to the duty to give reasons:
“The statement of reasons must explain the actual path of reasoning by which
the medical panel in fact arrived at the opinion the medical panel in fact
formed on the medical question referred to it. The statement of reasons must
explain that actual path of reasoning in sufficient detail to enable a court to
see whether the opinion does or does not involve any error of law. If a
statement of reasons meeting that standard discloses an error of law in the
way the medical panel formed its opinion, the legal effect of the opinion can
be removed by an order in the nature of certiorari for that error of law on the
face of the record of the opinion. If a statement of reasons fails to meet that
standard, the failure is itself an error of law on the face of the record of the
opinion, on the basis of which an order in the nature of certiorari can be made
removing the legal effect of the opinion.”
The NSW Court of Appeal in Zahed v IAG Limited t/as NRMA Insurance (2016) 75 MVR 1; [2016] NSWCA 55 held that Wingfoot applies to reasons given by a State Insurance Regulatory Authority (SIRA) claims assessor (assessing motor accident damages) in the subject legislative scheme in NSW (per Emmett JA at [34], Meagher and Leeming JJA agreeing).
In Sadsad v NRMA Insurance Ltd (2014) 67 MVR 601, the Supreme Court of NSW considered the adequacy of reasons of a SIRA medical assessor, rather than a claims assessor. However, the underlying principles are substantially the same. After applying Wingfoot Australia Partners Pty Ltd v Kocak (2013) 252 CLR 480, Hamill J stated (at [47] – [48]):
“It is one thing to give a “beneficial construction” to the reasons of an administrative decision-maker. It is another to fill in the gaps in the path of reasoning by reference to an assumption that the decision was made according to the relevant law (in this case cl 2.5). This accords with the approach taken by Stone J in SZCBT v Minister for Immigration and Multicultural Affairs [2007] FCA 9 at [26]:
[26] The minister urged a “beneficial” construction of the Tribunal’s reasons and referred to comments made in Minister for Immigration and Ethnic Affairs v Wu Shan Liang (1996) 185 CLR 259. The phrase “beneficial construction”, as used in Wu Shan Liang has a specific meaning, and was certainly not intended to mean that any ambiguity in the Tribunal’s reasons be resolved in the Tribunal’s favour. Rather, the construction of the Tribunal’s reasons should be beneficial in the sense that the Tribunal’s reasons would not be over-zealously scrutinised, with an eye attuned to error. In this sense a “beneficial” approach to the Tribunal’s reasons does not require this court to assume that a vital issue was addressed when there is no evidence of this and, indeed, the general thrust of the Tribunal’s comments suggest that the issue was overlooked.
Further, while to “fulfil a minimum legal standard, the reasons need not be extensive”, “where more than one conclusion is open, it will be necessary for the [decision-maker] to give some explanation of its preference for one conclusion over another”: Campbelltown City Council v Vegan (2006) 67
NSWLR 372 at [121]–[122] per Basten JA.”
In addition to guidance from the courts, rules and practices concerning writing reasons for decisions of any executive or administrative decision-maker are useful and relevant. In NSW, The New South Wales Civil and Administrative Tribunal (NCAT) and its appeal panel must give notice of any decision made on the proceedings (section 62(1) of the Civil and Administrative Tribunal Act 2013 (NSW)). If no reasons are provided, any party may, within 28 days of being given notice of a decision, request the tribunal to provide a written statement of reasons for its decision. The statement must be provided within 28 days after the request is made (section 62(2)). Written reasons must include the following:
– the findings on material questions of fact, referring to the evidence or other material on which those findings were based, – the tribunal’s understanding of the applicable law, – the reasoning processes that lead the tribunal to the conclusions it made.
(cf section 49(3) and 89 of the former ADT Act). The tribunal also has the power to correct obvious errors on the face of decisions (section 63).
This section may be compared with the Commonwealth provisions on which it was clearly modelled. The NSW provision was arrived at after taking into account long-established federal case law on the subject.
Section 62 of the NCAT Act should be adopted by all as the goal to be achieved so as to set out defensible and lawful reasoning.
Helpful guidelines were produced by the Administrative Review Council styled “Practical Guidelines for Preparing Statements of Reasons” in June 2000. A commentary on the said guidelines was also published at the same time. The guidelines (last revised on 26 May 2003) and the commentary are posted on the internet.
The Guidelines, for example, state in clear and practical terms (at page 12):
“State the real reasons for your decision. Do not rewrite history when preparing a statement of reasons. Every decision should be capable of a logical explanation. Your statement must contain all steps of reasoning, linking the facts to your decision, so that the person reading the statement can understand how your decision was reached. Your statement must go further than state your conclusions – you must give real reasons for those conclusions. You should also indicate any relevant policy statements or guidelines or other agency practices you took into account. In essence, you need to include any detailed background to the making of your decision, so that the person who receives the reasons will understand them (and not have to guess at any gaps).”
A checklist for the ensuring that the Tribunal sets outs proper reasoning is presented below.
Preliminary Matters
You have already made your decision. If so, you should have already undertaken most or all of the following steps:
(a) identified the decision to be made;
(b) identified your statutory powers;
(a) examined/considered/understood your statutory powers in their proper context;
(b) ensured that your copy of the statutory powers is complete, consolidated andup-to-date;
(c) noted/considered/identified any relevant government policy/manual/practice (you will later “engage” with this material);
(d) sought further information if required;
(e) undertaken any other investigation if required;
(k) decided whether any matter is appropriate to be attached to your decision, such as the imposition of conditions or qualifications and whether such matters are appropriate and lawful.
The Reasons for Decision
Follow, an established procedural form if one is available. If one is not, attempt to create a generic one and use it (but not slavishly).
As to your decision itself, there are 2 principal parts to this process. There are the easy parts and the hard parts. The easy parts are marked with an asterisk as follows:
-the decision to be made, by reference to the matters referred;
-the statutory powers/policy/guidelines/practice;
-the evidence both in support and against the making of the decision;
-the findings on material questions of fact, referring to the evidence or other
-material on which those findings were based; and
-your own reasoning process or processes that led you to the conclusion or conclusions you made (your real path of reasoning – your actual path of reasoning recorded in sufficient detail so as to enable a court to see whether your opinion does or does not involve any error of law – Wingfoot at [55]);
-your conclusion/decision/determination.
Writing Up the Hard Parts
This involves:
(a) findings of fact, referring to the evidence; and
(b) your reasoning processes
the hardest part of all;
read and consider everything first and bullet point the major factors which have turned your mind. Then set down those factors. This should ultimately comprise the core of your reasoning process;
be brief, simple and clear (Justice Kirby’s “blessed trinity”)
If you can (and if you need to) present a cogent explanation or argument in your reasoning;
be relevant, select only the principal and essential issues necessary for the decision;
no clutter or minor details should be included;
resist the temptation to stray into other (possibly more interesting) areas and ideas;
follow the language of the statutory power that you are applying. Always do this. Never attempt to paraphrase or rewrite the statute or the delegated instruments in the making of your decision;
include only the real reasons for your decision, not all possible reasons or other reasons which come to mind if those reasons have not being the reasons which turned your mind;
include only your reasons and not the reasons of any other person or entity. Failure to do this will probably render the decision void; use appropriate language that is plain and clear; remember your audience at all times:
(i) the applicant;
(ii) the Minister or the Department;
(v) the Federal Circuit Court; the Federal Court or the Supreme Court of a State; and
(vi) all those who have access to the relevant Registers where the decisions and reasons are published. inform them all, expose them all to your reasoning process in full;
-be honest and courageous in setting out your reasoning process;
-refer to the evidence you accept and say why you accept it; refer to the evidence you reject and say why you reject it (not always necessary, but it does not hurt);
-if you can’t explain it, you probably have not understood it;
-identify any aspect of policy or guidelines that you are relying on and in what respects. Do this with some precision;
-if in doubt – or just do it anyway, put down your draft written reasons for a while and review them later; and,
-review your draft written statement of reasons at least once before handing down your decision. The object of your review, or rewriting should be to:
-expunge superfluous details and repetition;
-remove unnecessary emphasis;
-eliminate the words not necessary to express the idea, clichés, verbiage, redundancies and grammatical errors; tighten the text;
-delete any sexist and otherwise prejudiced expressions; and
-verify punctuation and spelling.
17 August 2016 Mark A Robinson SC, Maurice Byers Chambers
The general principles in relation to the evaluation of the adequacy of reasons are well established (Chief Executive Officer, Department for Child Protection and Family Support v IGR [2019] WASCA 20; (2019) 54 WAR 222 [112] (Quinlan CJ, Murphy & Beech JJA). Necessarily the content and detail of reasons will vary according to the nature of the jurisdiction being exercised and the subject matter of the case ( DL v The Queen [2018] HCA 26; (2018) 266 CLR 1 (DL v The Queen) [32] (Kiefel CJ, Keane & Edelman JJ). In the context of a criminal trial heard by judge alone, the High Court most recently described the failure to resolve a particular dispute in the following terms:( DL v The Queen [33] (Kiefel CJ, Keane & Edelman JJ) )
At one extreme, reasons for decision will not be inadequate merely because they fail to address an irrelevant dispute or one which is peripheral to the real issues. Nor will they be inadequate merely because they fail to undertake ‘a minute explanation of every step in the reasoning process that leads to the judge’s conclusion’. At the other extreme, reasons will often be inadequate if the trial judge fails to explain his or her conclusion on a significant factual or evidential dispute that is a necessary step to the final conclusion. In between these extremes, the adequacy of reasons will depend upon an assessment of the issues in the case, including the extent to which they were relied upon by counsel, their bearing upon the elements of the offence, and their significance to the course of the trial. In particular:
‘Ordinarily it would be necessary for a trial judge to summarise the crucial arguments of the parties, to formulate the issues for decision, to resolve any issues of law and fact which needed to be determined before the verdict could be arrived at, in the course of that resolution to explain how competing arguments of the parties were to be dealt with and why the resolution arrived at was arrived at, to apply the law found to the facts found, and to explain how the verdict followed.’
“In the present case, the challenge to the adequacy of the learned trial judge’s reasons, which we accept to have been made out, rested principally on the way in which her Honour dealt with the evidence of the appellant. First, while the learned trial judge stated that she rejected the appellant’s evidence (including his denials of offending), her Honour did not provide any reasons for having rejected that evidence. In the context of her Honour’s rejection of his evidence the only two matters referred to by the learned trial judge were:
(a) that the appellant’s evidence as to the opportunity to have committed the offence was consistent with that of Z; and
(b) that there was no motive or reason for the appellant to have committed the offence.
Neither of these matters was a reason for rejecting the appellant’s evidence. The first (opportunity) was, at best, neutral as to the credibility and reliability of his evidence and the second (lack of motive) was in the appellant’s favour. Of course, it may be accepted that, in a case of ‘word against word’ (as her Honour recognised this case to be), the advantages of the trial judge having seen and heard the witnesses may be such that demeanour and the impression formed by the trial judge as to the credibility and reliability of the witnesses may assume particular importance. In that case, the legitimate use of such impressions and demeanour may be difficult for the trier of fact to articulate. A trial judge is not required, in that regard, to embark on an infinite regression of reasons for reasons.” (Child and Adolescent Health Service v Mabior by next friend Kelei [2019] WASCA 151; (2019) 55 WAR 208 (Mabior) [100] (Quinlan CJ, Murphy & Pritchard JJA).)
Artificial intelligence and the autonomous systems that embed it have become the brains of the modern data economy. As such, they have started to reshape human values, trust, and power around the world. Whether in medicine, money, or love, technologies powered by forms of artificial intelligence are playing an increasingly prominent role in our lives.
New AI technologies can help drive cars, treat damaged brains and nudge workers to be more productive, but they also can threaten, manipulate, and alienate us from others. They can pit nation against nation, but they also can help the global community tackle some of its greatest challenges from food crises to global climate change. As we cede more decisions to thinking machines, we face new questions about staying safe, keeping a job and having a say over the direction of our lives.
How AI evolves and what role it takes in our lives for better or worse, might depend on our race, gender, age, behaviour, cognitive capacity or nationality.
This presents manifold ethical and cross-cultural dilemmas.
Integrated development environments (IDEs) have long been used by computer programmers as a way to improve efficiencies, reduce mistakes, and standardize outputs. In this essay, Michael Jeffery provides an overview of the ways an IDE could improve the practice of legal drafting.
As a lawyer specialising in corporate and commercial law, I have spent a large proportion of the last 15 years in Microsoft Word drafting contracts and other legal documents. Microsoft Word is undeniably a fantastic product and .DOCX files are likely to remain the default format for sharing and editing legal and business documents for the foreseeable future. However, when it comes to the initial drafting of legal documents in Microsoft Word, there are some inefficiencies that would ideally be addressed.
What are the Problems?
A lawyer’s workflow when drafting a new document will typically start with finding the closest existing document or template that meets the criteria for the particular task – usually from a centrally managed precedent database or document management system. The base document will inevitably need further tailoring, which is normally addressed through:
manually updating terminology to suit the specific requirements of the transaction;
copying and pasting text from other documents – which will often also require time modifying fonts and other style settings;
manually checking that the clauses used are the most up-to-date versions (including that they incorporate any updates required to comply with recent changes to law);
manually drafting custom clauses – which will inevitably result in incidental amendments to other sections of the document; and
finally, reviewing and re-reviewing the whole document multiple times to ensure that all legal issues have been addressed, that clauses are drafted in a clear, precise and unambiguous manner, that defined terms have been used consistently and that the document does not contain formatting or typographical errors.
Some of these inefficiencies can be partially addressed through better precedent management processes and the use of document automation systems. However, since Microsoft Word does not really have any built-in tools to assist with the typical legal drafting workflow process (other than spelling and grammar correction), there is a case to be made that:
Microsoft Word may not be the ideal application for lawyers that draft long and complicated legal documents; and
perhaps lawyers should be looking at the systems and processes used by software engineers as inspiration for the development of a better legal drafting tool.
I am certainly not the first person to have had these thoughts.undefined In fact, I think that any lawyer who dips their toe into the computer science world would have the same epiphany – that the way we currently draft legal documents is incredibly antiquated and there is room for serious improvement!
Similarities between Drafting and Coding
At the outset of this paper, I must emphasise that I am not a computer scientist or software engineer. My programming experience is mostly limited to learning sufficient Python to build automated contract packages and interviews on top of the open source Docassemble framework.undefined
But coming from a legal background, when learning to code, the striking similarities between drafting legal documents and writing code were immediately obvious. Both:
require significant attention to detail;
have language, syntax and form rules that need to be consistently applied; and
at a fundamental level, are just rules and conditional logic reduced to text.
Programmers normally use an application called an integrated development environment (IDE) to facilitate the authoring, compiling and debugging of code. Most of the popular IDEs (and even more basic code editors) provide tools for:
colour coded syntax highlighting – to assist with readability and to separate different types of commands, variables, words and symbols;
automatic error detection – based on the specific programming language being used;
predictive auto-complete features – providing suggestions as text is typed; and
the ability to seamlessly pull code from hosted repositories – allowing for code to be easily shared and ensuring that up-to-date versions are used.
These are all features that would seem to be equally applicable to the workflow that lawyers go through when drafting legal documents.
So, why don’t lawyers use an IDE? In my opinion, we probably should be.
Features Required for a Legal IDE
If an IDE for legal drafting were to be developed, what would this potentially look like and what features could be incorporated into the IDE to improve legal drafting efficiency? The rest of this paper shares my views on this topic from a lawyer’s perspective.
File Format and Language
Microsoft Word is a WYSIWYG (what you see is what you get) editor. It allows the user to visualise their final document (in its printed form) while a document is being written or edited – which is useful and important for many use cases (including legal drafting). However, the inefficiencies associated with legal drafting in Microsoft Word stem from the fact that DOCX files are editable files – but they are not programmable files (or at least that is what the vast majority of lawyers think). If a change occurs in one section of a document that impacts on another section, in most cases the relevant change needs to be made manually (rather than being linked and controlled through code). Lawyers often find that they need to make the same types of incidental changes over and over again (meaning that many of the modifications being made are the result of legal or grammatical rules that could be broken down, codified and executed automatically in a format that allows both text and code).
The vast majority of lawyers are unaware that .DOCX files can be controlled through code (in the form of macros, conditional logic within mail merge fields and through code written in the Visual Basic programming language). However, for me personally, none of these methods have ever felt like a natural and logical part of the legal drafting process. This is primarily because the inputs and code are often inserted and displayed through different windows (or hidden fields), so it is difficult for the code, and the logic within the code, to be read and reviewed as part of, and in conjunction with, the legal text and the logic within the legal text.
Hybrid file formats (where code and natural language text are displayed together) do exist. In the scientific community, written reports (particularly those containing complex calculations) are often written and shared using a Jupyter Notebookundefined, RMarkdownundefined or Julia Markdownundefined. These are all interactive formats that allow for text to be written within a report (with basic formatting) and combined with code blocks (using the Python, R and Julia programming languages). The code blocks within a report can be executed and used to run calculations, pull data from other sources, display graphs and tables, and automatically update parts of the report. All of these formats could be used to hack together interactive legal documents (and an example is given later in this paper using Julia). However, these formats have been designed primarily for use in situations where the interactive component of the relevant document or report is a graph, plot or calculation. They can be used to control and update document text – but the method of doing so is quite syntactically complex and unnatural when compared to normal writing or legal drafting.
In the legal sector, there have been a few projects that have developed new programmable contract formats (such as OpenLawundefined and the Accord Projectundefined). The focus of these projects have been to develop interactive open source formats suitable for generating smart contracts for use on blockchain platforms. While traditional paper based contracts may not be considered as smart and innovative – interactive and programmable formats would be equally useful (if not more so) in the day-to-day drafting of traditional paper based contracts and legal documents.
Programmability
There is often debate about whether or not lawyers should learn to code. Finding lawyers who can code is rare, but I would argue that the programming skills required for interactive document design and drafting are very different than the skills required to develop software. For legal drafting (or legal programming) – the focus is linguistic – rather than mathematical – but the core concepts are the same.
Set out in the table below are the key programming concepts that could be taken into account when designing an IDE for legal programming and how they could be used to improve efficiency. The table also includes examples of how these programming concepts are already used by lawyers when preparing legal documents – albeit that these computations are currently done by lawyers in their heads.
Programming concept
Application to legal drafting
Variables
Details like party names, addresses, monetary figures and other defined terms are used throughout legal documents. The ability to change a variable once (with that update then automatically propagating across the rest of the document) is likely to save significant time and reduce the risk of human error in legal drafting. Most legal agreements contain a section with a dictionary of defined terms. If variables are defined within a document (through the code), this would also help to ensure that the relevant defined terms are used consistently throughout the drafting and that all defined terms are included within the document’s dictionary section.
Conditional logic (if-else statements)
Conditional logic is a normal part of legal drafting. The lawyer will need to include different types of clauses to satisfy the particular transaction requirements (e.g. if a loan agreement is secured, then include the relevant security clauses). Conditionality also often applies in the context of grammatical changes in a document (e.g. if there are multiple vendors in a transaction, references to vendor, vendor is and vendor has may need to be updated to vendors, vendors are and vendors have). The ability to code these changes into a clause would greatly assist in the future re-usability of the relevant document (or parts of the document). In an ideal world, when a new clause needs to be drafted for a transaction, or further customisation is required for an existing clause, those changes would be inserted into the base document and controlled through conditional logic (rather than deleting the irrelevant clause options and losing that intellectual property). Over time, base documents would become more complex (but also more powerful and capable of dealing with a broader range of transaction requirements).
Lists and datasets
Variables used in legal documents are often related to other variables. For example, in a shareholders agreement, the key variables associated with a particular shareholder might include data such as the name of the shareholder, any company number associated with that shareholder, the registered address of that shareholder, the type of entity that the shareholder is, the type of signing block required for that shareholder, the number of shares that they hold, the type of shares that they hold and the number of directors that the shareholder is entitled to appoint to the board of the relevant company. When combined with for loops (see below), this would significantly increase the versatility (and again re-usability) of the documents once they have been drafted.
Loops
Loops allow for code to be run and repeated multiple times. A simple legal drafting example would be: for each party stored in a list or dataset, include a signing block for that party. If the entity type associated with that party is also stored in the dataset, the type of signing block required for each party could also be automatically updated programmatically. Loops and the ability to iterate over datasets are critical requirements for reusability of documents (as the number of parties, assets, steps or other things in legal documents regularly vary from one transaction to the next).
Importing libraries and functions
Libraries and functions allow code (stored in other files and repositories) to be re-used. Most programming languages (if not all of them) have simple commands to import libraries and then run functions stored in those libraries. The same approach could be used with legal drafting. Text for specific clauses could be stored in separate repositories and then simply called when needed with a simple command (or included within the relevant document using a single line of code). Boilerplate clauses, party information blocks and signing blocks are all examples of document sections that rarely get modified (so would be ideally suited to being coded and stored as a legal function and allow for object oriented legal programming). Currently, this process is usually done manually by lawyers cutting and pasting text from other documents.
Comment blocks
Most programming languages include the ability to insert text comments to explain how sections of code work. A common method is to include a hash/pound sign (#) at the beginning of a line of code. Lines with a hash at the beginning are not processed by the interpreter or compiler and are ignored. In addition to using hash signs for comments, they can be used when writing code to experiment with different options. Rather than deleting a line of code (and loosing that work), the programmer may just put a hash at the beginning of a line so that it is temporarily ignored while another line of code is worked on and tested. Comments in legal documents (which are not then displayed in the output) would be similarly useful for lawyers sharing clauses and explaining factors that may need to be taken into account. But they would also be useful for quick and nasty updates to documents (when there are client time pressures). As mentioned above, in an ideal world, new and bespoke drafting would be added and controlled using conditional logic – but when there is insufficient time to do so, hash signs could be used to remove irrelevant clauses (without deleting them from the document and loosing that knowledge).
If a new legal IDE were to be developed, these programming concepts would ideally be provided for (whether through the IDE itself, or through the underlying file format or programming language that is used).
With a syntax designed for drafting and document generation, I believe that most lawyers who are experienced and skilled in drafting quality legal documents would find the process quite natural – as they already apply the core principles when manually drafting and updating documents in DOCX format.
Preview Windows
Each of the programming concepts above (with perhaps the exception of comment blocks) are used by good document automation platforms. Automation systems like Docassemble use specific syntax typed within a .DOCX template file. The result is a .DOCX file that will automatically update and change in form based on the variables and other data that is obtained from a user when completing an online interview. However, one of the most time consuming aspects associated with preparing a .DOCX formatted template for automation (whether using Docassemble or any other automation server system) is debugging the template file. Problems with code syntax or formatting issues within the output are generally only identified after a template has been uploaded to the server and the document generated. Documents then need to be updated and tested multiple times to identify the bugs (and this process becomes exponentially more complicated as document length and complexity increases).
Systems like RMarkdown using the RStudio IDEundefined (and most other Markdown editors) provide for a code window and a preview window to be displayed side-by-side (showing the formatted output as code is typed – or quickly after refreshing the preview window). If a new legal IDE were to be developed that used a programmable file format, a key requirement would be to have a preview window to display the output as it is being developed (and that could be refreshed quickly).
This would be particularly useful when testing conditional logic and loops within documents (as the output could be reviewed and checked as different drafting is tested). Since lawyers are accustomed to using WYSIWYG editors (such is Microsoft Word) this feature would probably make the transition process more natural and increase adoption rates for the new legal IDE.
Styling and Formatting
Styling and formatting in Microsoft Word is overly complicated and there are more features than are necessary – and as a consequence of lawyers hacking together documents by cutting and pasting from multiple sources, there are often multiple formats and styles within documents that need to be corrected (some of which are hidden and cause file corruption issues). However, simplified formats like Markdown are lacking in many of the areas that lawyers would want if they were to even consider switching from Microsoft Word.
In my opinion, the core styling and formatting requirements would be:
Style/formatting requirement
1.
Automatic heading and clause/paragraph numbering (including multiple levels and sub-levels of numbering).
2.
Fonts, font sizes and line spacing – These would need to be customisable as most firms and businesses have their own style guides and preferences.
3.
Tables and text indenting – These often help to improve the readability of documents.
4.
Clause cross-referencing – The ability to insert (and automatically update) cross-references is an important feature for many lawyers. Clauses could be drafted without the use of cross references (and arguably this may result in a clearer style of drafting). However, without cross references, many lawyers would need to substantially update the drafting of many of their existing documents – which could impact on the adoption rates of the new legal IDE.
5.
Page numbers, page breaks and “keep with next” paragraph settings – Legal documents will still be printed, so these features are useful to ensure that documents print as intended.
The new legal IDE would ideally have these core style and formatting features, and would control the look and feel of those formats and styles using something similar to CSS (used to style websites) to ensure that those style and formatting rules are consistently applied.
Syntax Highlighting
Most IDEs for software development display code using customisable themes that apply colour coding to the text to make it easier to read and to assist with identifying different elements within the code (such as variables, reserved words used by the relevant programming language and symbols that have a specific purpose). The new legal IDE would also ideally have these features. However, in addition to specific colour coding in code blocks, the colour coding would also (ideally) be used to make normal text sections more readable (and assist with identifying typographical and grammatical errors).
Auto-Complete
Many IDEs provide intelligent code completion tools that speed up the coding process and reduce errors. Microsoft’s own Intellisense system used in the Visual Studio IDE is a good example. Intelligent code completion tools behave in a similar fashion to predictive text on mobile phones, but suggest things like variable names, permitted functions and methods and appropriate syntax through the use of pop-ups.
Context aware auto-completion tools would be equally useful when drafting legal documents. In an ideal world, the auto-complete for a legal IDE would provide for each of the following:
handling both coding related syntax suggestions and natural language and grammatical suggestions; and
the ability to use custom machine learning models – this could allow firms and legal departments to use their own clause libraries and precedent databases to train the system (encouraging the use of consistent language and similar drafting styles).
Export Formats
While much of this paper is advocating the benefits of file formats that allow the combination of text and code, in many instances it may not be appropriate for sharing all of the code and possible clause options with clients and counterparties.
For example, if the relevant legal document will be negotiated and the underlying base file (from which the relevant legal document was generated) contains other possible clauses or scenarios (and those clauses/scenarios are more advantageous to the other side), it would not be appropriate for the underlying code to be shared.
As a result, the new legal IDE would need to be able to export to other file formats (i.e. DOCX and PDF) for the negotiation and contract finalisation stages of the legal process.
Demonstration of Core Features Using Julia
The screenshot below shows a very simple clause from a shareholders agreement (in Microsoft Word format) which sets out the number of shares held by each shareholder.
While it is a simple clause, it is an example that incorporates most of the programming concepts listed above, and how they are applied in practice to legal drafting. The key variables include:
whether the contract is an agreement or a deed;
the names of each shareholder (and then related to each shareholder, the number of shares that they hold, shareholding percentages and whether or not they are held on trust); and
the total number of shares issued by the relevant company.
Using the Julia programming languageundefined, the Julia IDE (Juno)undefined, Julia Markdownundefined and the Weave.JL extensionundefined, it is possible to achieve many of these basic legal IDE requirements without any further development.
The sample clause could be generated using the code below:
````julia; echo = false
# Refer to note 1
deed = "No"
if deed == "Yes"
contract_type = "Deed"
else
contract_type = "Agreement"
end
# Refer to note 2
company_shares_number = 50
# Refer to note 3
shareholder_details = (
name = ["Shareholder A", "Shareholder B", "Shareholder C"],
shares_held = [20,15,15],
capacity = ["Legally only", "Legally and beneficially", "Legally only"]
)
# Refer to note 4
function company_share_structure_clause()
println("#### Structure of the Company")
println("The parties acknowledge and agree that, as at the date of this ", contract_type, ", the Shares are held as follows:
")
println("| Shareholder | Shares held | Percentage held | Capacity held |")
println("| --- | --- | --- | --- |")
x = 1
for i in shareholder_details
println("| ", shareholder_details.name[x]," | ", shareholder_details.shares_held[x], " | ", 100*(shareholder_details.shares_held[x]/company_shares_number),"% | ", shareholder_details.capacity[x]," |")
x = x + 1
end
println("| **Total** |", company_shares_number, "| 100% | |")
end;
```
`j company_share_structure_clause()`
Note 1: This section is an example of conditional logic. The shareholders agreement could either be an agreement or a deed. Depending on the answer to this yes/no question, all references in the shareholders agreement to contract_type will display as either Agreement or Deed. There is only one reference in this short clause. However, in a full shareholders agreement, there are likely to be hundreds of instances that would need to change depending on whether the shareholders agreement is signed as an agreement or a deed.
Note 2: The variable company_shares_number is defined to be equal to 50. The variable is displayed in the bottom row of the table and is also used to calculate the shareholding percentages for each shareholder.
Note 3: This section of code creates a matrix of the data required for each shareholder. In a full shareholders agreement, there would be many more attributes required to be captured in relation to each shareholder and each other party.
Note 4: This section creates a function called company_share_structure_clause. The function is then called outside the code block in the line containing j company_share_structure_clause(). Ordinarily, when using formats such as Julia Markdown, RMarkdown and Jupyter notebooks, you can write text freely in standard Markdown format. It is possible to include variables within Markdown text sections. However, it is not possible to include conditionality or loops within standard text blocks. This function uses code to generate the required text and table in Markdown format.
The screenshot below shows what this code looks like when loaded within the Juno IDE. The left-hand side contains the code (with syntax highlighting) and the right-hand side displays the preview of the generated clause.
If the content of the function were instead stored within a separate library – perhaps a file called clause_library.jl the code could be significantly shortened (as set out below) and the output would be the same:
In my mind, this structure makes a lot of sense. There is an instruction at the top that specifies which clause library to use, with further lines of code to define the key variables and datasets. Below the code block, the lawyer could then write custom clauses or call pre-coded clauses stored within the clause library. In the further screenshot below, some custom drafting in Markdown has also been added to illustrate this point.
Note: When typing in the text sections, Markdown uses the hashtags to signify different levels of headings (not comments).
I am not advocating Julia Markdown as being the answer. It has not been designed for this process and there are clear limitations that are likely to dissuade lawyers from changing from their normal processes in Microsoft Word (particularly, the very limited formatting options associated with Markdown). However, it does illustrate (at a conceptual level) how it would be possible to change the typical legal drafting process to a method that combines both natural language and code.
With an IDE specifically designed for legal drafting (and probably a new file format – or even a new programming language – specifically designed with legal drafting in mind), it seems likely that significant efficiencies could be generated.
Additional Goals and Considerations
If this project went further than the theoretical concept outlined in this paper, improving the speed and efficiency of legal drafting would be the primary goal and measure that would need to be assessed. Being such a radical change to the current legal drafting process, it seems highly likely that this goal would not be achieved during the early stages of use (as it would require a substantial amount of time to train lawyers to use the new system and develop coded clause libraries). However, there could also be a number of other possible knock-on effects that would need to be evaluated when considering whether or not the use of the new legal IDE improves efficiency (and is otherwise beneficial to the legal professional).
From my perspective, the other key areas to consider would be:
Sharing – Does the process encourage lawyers to start creating and sharing more open source contracts, clause banks and other content through platforms like Github, and does this raise or decrease the overall quality of legal work?
Standardised legal language – Does this alternative method of drafting increase the use of standard legal language developed by organisations like SALIundefined and reduce the negotiation and clause re-drafting that currently goes on between lawyers?
Machine learning and automation – If the chosen file format is primarily text and code (being a much cleaner and structured format than DOCX files), how much does this facilitate the use of other machine learning and automation systems within the law?
Error reduction – Does the legal IDE and new drafting process decrease error rates in documents (or increase error rates as a result of lawyers becoming less thorough in their review process)?
Smart Contracts – Can the relevant file format (and programming language) be used for drafting both traditional paper based contracts and smart contracts (reducing the number of new processes and systems that lawyers need to learn)?
Final thoughts
Law is an old and traditional profession – but unfortunately, so are many of the tools and processes that we currently use.
There are some really exciting projects in the legal tech space that are seeking to modernise aspects of the legal sector. However, with document generation being such a large part of the role that lawyers play, I believe that we need to go back to basics and design the tools and systems that we need to perform this fundamental task more efficiently.
There was also no issue about the principles which govern the resolution of what lies in issue as to the proper construction of the endorsement to this insurance policy.
Where an insurance company prepares the document, it is bound to make its meaning as clear as possible: Craine v Colonial Mutual Fire Insurance Co Ltd (1920) 28 CLR 305; [1920] HCA 64. “A policy of insurance, even one required by statute, is a commercial contract and should be given a businesslike interpretation. Interpreting a commercial document requires attention to the language used by the parties, the commercial circumstances which the document addresses, and the objects which it is intended to secure”: McCann v Switzerland Insurance Australia Ltd (2000) 203 CLR 579; [2000] HCA 65 at [22].
The meaning of commercial documents must be determined objectively, their construction being determined by what a reasonable person in the position of the parties would have understood them to mean, which requires consideration both of the text of the documents and also the surrounding circumstances: Pacific Carriers Ltd v BNP Paribas (2004) 218 CLR 451; [2004] HCA 35 at [22].
If there is ambiguity, resort can also be had to the surrounding circumstances known to the parties: Codelfa Construction Pty Limited v State Rail Authority of NSW (1982) 149 CLR 337 at 352; [1982] HCA 24.
The interpretation of an exclusion clause “is to be determined by construing the clause according to its natural and ordinary meaning, read in the light of the contract as a whole, thereby giving due weight to the context in which the clause appears including the nature and object of the contract, and, where appropriate, construing the clause contra proferentem in case of ambiguity.”: Darlington Futures Ltd v Delco Australia Pty Ltd (1986) 161 CLR 500 at 510 [1986] HCA 82.
Where two meanings are open, “it is proper to adopt that meaning that will avoid consequences that appear irrational and unjust”: Public Transport Commission of New South Wales v J Murray-More (NSW) Pty Ltd (1975) 132 CLR 336 at 350; [1975] HCA 28. Further, in the event of ambiguity it is proper to give a construction “that would avoid irrational consequences that it is unlikely that the parties intended”: Distillers Co Bio-chemicals (Australia) Pty Ltd v Ajax Insurance Co Ltd (1974) 130 CLR 1 at 11; [1974] HCA 3.
A court may also depart from the “strictly literal meaning of a particular expression to place upon it an alternative construction which is more reasonable and more in accord with the probable intention of the parties if the words will bear that construction.”: Australian Casualty Co Ltd v Federico (1986) 160 CLR 513 at 520; [1986] HCA 32.
The contra proferentem rule is one of last resort, however, applying only when ambiguity remains after all other avenues of construction have been exhausted: Beefeater Sales International Pty Ltd v MIS Funding No 1 Pty Ltd [2016] NSWCA 217.
An interesting decision of the NSW Court of Appeal on the topic of recognition of a novel duty or care.
Ibrahimi v Commonwealth of Australia [2018] NSWCA 321
The Court of Appeal has dismissed an appeal from Mr Ibrahimi, representing a class of persons, against the Commonwealth of Australia concerning an alleged breach of duty of care owed to the plaintiffs during the shipwrecking of the boat on which they were travelling, SIEV 221, off the coast of Christmas Island in December 2010.
The Court (Payne JA, Meagher JA and Simpson AJA agreeing) (consistent with the primary finding at first instance) held that any alleged duty could not arise under the established categories of duty. Rather, any duty would have to arise as a novel duty of care, in which case the application of the salient features test is the correct approach.
On the facts of he case, there was no relevant reliance by the group members on the Commonwealth which would give rise to the relevant vulnerability, nor did the Commonwealth have control over the risk to the the group members in the relevant sense. In addition, there is no expectation placed on public authorities, of which the Commonwealth was one, of general reliance: that an entity will properly perform its public or private function.
It is important to note that this particular case dealt with potential harms flowing from omissions by a public authority, not from positive acts by such public authority. These aspects operate to mitigate against imposing a duty of care of a novel kind.
Finally, a $2 coin to the primary judge, on a difficult legal issue and emotionally charged issue, who was correct to reject case brought by Mr Ibrahimi.
