Proposal: Adding support for 'questionnaires' to Accord Project

[OliverTod]

Background:

A comprehensive background to this proposal is set out in these slides and was discussed on this Tech WG call

In short, there is a compelling use case for making it easier for users to populate Accord Project instances through a 'questionnaire'/web form. This will help to:

• set standards for the legal industry for document automation;
• reduce barriers and speed adoption of Accord Project contracts by existing law firms & businesses that are already familiar with this type of document automation (most of them!); and
• capture valuable effort and thinking that has already gone into legal document generation tools (such as existing templates/questionnaires).

Proposals:

In the context set out above, it is proposed that Accord Project should develop either or both of the following:

1. a conversion that produces a file from model file(s) that is compatible with existing form generation tools; and/or
2. a 'questionnaire'/'model editor wizard' file which supplements the model file to produce a structured questionnaire (which in turn can be used to produce a JSON data file for an SLC instance).

Proposal 1: Integrations with online form tools

Currently, users need to either parse a sample (.md) file or manually write a data (.JSON) file in order to create an instance of an Accord Project template. Users should also be able to fill in a webform to populate this data file. This webform should be automatically generated based on the model file. ConcertoUI is based on this idea.

Concerto itself would need to be extended to support ‘presentation’ variables in a standardised way. For example, setting standard attributes in the @FormEditor decorator. It should be possible to provide a baseline of supported field types, which suit most legal applications.

How this would work in practice:

1. Developer prepares an Accord Project template with a model (.cto) file.
2. Developer decorates the model with presentation variables (such as question titles and notes that are supported by form generation tools).
3. The model is converted into a format (likely .JSON) that is understood by online form editors.

Proposal 2: using a 'model editor wizard' to produce an SLC instance

Although the proposal set out above will make it easier to create SLC instances from model files - it does not cover complete conversion from existing document automation tools (ie questionnaires that populate documents) into Accord Project SLCs. In order to achieve this, much more context, structure and guidance functionality will be needed. This is a huge part of the value that is delivered by existing legal document automation tools. This includes being able to include:

• statements that are not connected to a field
• group related questions within and across pages
• put guidance text before or after (or next to, or on mouseover) a question
• only ask relevant questions (based on the user’s answers) through the use of ‘logic’

How this would work in practice:

1. Developer prepares an Accord Project template with a model (.cto) file.
2. Developer prepares a 'quesitonnaire' file based on the model file which is written in a supported schema / language (maybe yaml). The developer can run a command to check that this questionnaire file is synchronised with the model file.
3. The questionnaire file can be run by any platform that supports this syntax (eg docassmble)

In due course, this work could be extended this so that, instead of just building the SLC data file, the questionnaire adds/subtracts from each of the other files in the SLC. For example, text is included in the grammar or code is included in the logic files based on the responses.

Next steps

This proposal is submitted to the TSC for approval. This represents a significant new direction for the Accord Project to pursue.

Members from the community (especially @mttrbrts, @dselman and @jeromesimeon ) are encouraged to comment on this issue with their thoughts and concerns.

[OliverTod]

Amended 'Accord Project Template' diagram if Proposal 2 is implemented:

[mttrbrts]

Thanks for writing this up @OliverTod. Here are some thoughts towards a technical solution for the questionnaire component:

1. We should separate the questionnaire's model from that of the SLC. They are related but distinct; this is a similar distinction to the presentation-layer vs database schemas, IMO. This implies that we'll need some way to transform between them (either in code, some transformation language, or using annotations) (i.e. a "controller").

2. The presentation / rendering "view" should also be separate from the model (which includes layout data and paging info for example). This allows us to support multiple views for a single SLC.

This gives a traditional model-view-controller (MVC) architecture to this new component.

[mttrbrts]

TSC Notes:

• Some relevance to Aadrika's APSoC project, no direct progress