Idea: Flags in section markup

[anseljh]

A common pattern in contracts is a survival clause, which has a list of sections that survive the contract's termination. Maintaining this section is error-prone because it's easy to forget to add a new section to the survival clause, etc.

One possible way to attack this problem would be to mark sections you want to survive, right in that section's markup. Then, in the survival clause, you would place a special tag that would cause Common Form to generate the list of marked sections automatically.

There might be other use cases for section flags like this. I haven't thought through what they might be, how one would implement this idea, or if it's really a good idea. It's certainly low priority.

Curious what you think, @kemitchell?

[kemitchell]

Rather than have software manage tags (metadata) and write them back into content, why not write the information you want to tag into the contract itself?

If the surviving language is one form, you might add This obligation will survive termination of this <Agreement>. to the end. If it's a form with sub-forms, you could add another sub-form with a reference to its parent: \\ {Parent} will survive termination of this <Agreement>.

We've all seen "by its nature intended to survive termination" in a laundry list of surviving provisions. I have also seen "by its terms intended to survive termination". Usually those phrases don't describe all provisions that survive. Rather, they're just one category in a list of categories and direct cross-references.

But if every provisions that needs to survive has its own survival language, there's really no need for a general provision on survival. And no list to screw up.

[kemitchell]

Unsolicited philosophical rambling 1 of 2:

My response leads us back to #1. Instead of:

This obligation will survive termination of this <Agreement>.

should Common Form allow?:

{this} will survive termination of the <Agreement>.

or?:

{parent} will survive termination of the <Agreement>.

or even?:

{parent(5)} will survive termination of the <Agreement>.

I don't know.

[kemitchell]

Unsolicited philosophical rambling 2 of 2:

Common Form embodies my view on modularity and reuse. As with code --- including CommonForm.org's code --- I think complex work should be made of small, interchangeable parts that achieve one goal apiece. As a result, Common Form software almost always rewards rewards more structure and gathering everything for a particular "feature" in one form. It rewards more subsections over long paragraphs. It rewards mentioning survival in situ.

This approach doesn't make sense with unstructured, typewriter-esque editors like Word. With those tools, each choice to split a section into multiple sections costs you more than the last time. Deeply nested forms are prohibitively expensive to format and proof.

Common Form's schema is rigid, and its tools don't abide exceptions. You can't use images or tables, for example, without postprocessing. Automatic numbering and dynamic references are mandatory, not optional "advanced" features, as in Word. All of that is cost; you have to shoehorn the content you want into the format Common Form tools will except. The offsetting benefit is that the high proofing and formatting costs of drafting modular contracts approach zero.

That's the hope, at least.

[tbrooke]

Unsolicited practical Rambling possibly in the wrong place:

Skipping over the issue of the survival clause I agree with the modularity or potential modularity - If I am correct it seems that Commonform.org assigns a hash for each paragraph in a contract. This is great because as you mentioned I view a contract in a structured way - but other than Commonform.org what are the tools - I can do multiple buffers in VIm but it is not convenient - Are we writing a New editor? I would love an easy way to deal with alternative clauses, survival clauses or other situation where you are juggling around clauses. I am not sure what this tool would look like

[anseljh]

Thanks, Kyle! I like your explicit approach to survival, and simply had failed to imagine it.

Let me think about your idea for {parent} syntax. I haven't run into a need for that yet, but I can see how you might want to with this approach, where you'd want to import a reference the same survival language rather than typing it out each time.