Skip to content

Commit 3f4780c

Browse files
authored
Create Interpretive Guidelines.md
Initial interpretive guidelines, incomplete
1 parent 43a1fa3 commit 3f4780c

1 file changed

Lines changed: 60 additions & 0 deletions

File tree

Manual/Interpretive Guidelines.md

Lines changed: 60 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,60 @@
1+
# Project Breeze Interpretive Guidelines
2+
3+
1. Introduction
4+
1. Project Breeze aims to create, refine and distribute reusable selections of legal language (each a "Package") to simplify the contract drafting process.  Users of Project Breeze may reference the standardized and immutable Packages available on the Project Breeze platform to be incorporated directly into their documents.
5+
2. These Interpretive Guidelines will aid Project Breeze users, whether they are drafting or reading a document containing references to Project Breeze Packages, to correctly interpret and construe any applicable legal language.
6+
2. Disclaimer
7+
1. Project Breeze is not a law firm and does not offer legal advice.  The use of Project Breeze creates no relationship with Project Breeze in any way.  Project Breeze and contributors to Project Breeze offer no warranty of any kind and disclaim all forms of liability.  Please seek independent legal advice prior to using Project Breeze.
8+
3. Interpretation
9+
1. Importing Project Breeze Packages
10+
1. The purpose of Project Breeze is to allow the "Import" (as defined in the Keywords section) of Packages.  The idea is similar to referencing attached appendices with several key differences.
11+
2. To Import a Project Breeze Package, a statement (each an "Import Statement") must be made beginning with the keyword Import and the statement must include at minimum:
12+
1. its own section/clause/chapter/article number; and
13+
2. a valid URL to a Project Breeze Package.
14+
1. A valid URL must point to either a specific version or to latest version of a Project Breeze Package.
15+
3. The Import Statement may also include:
16+
1. A version number, which must also be accompanied by a version number in the URL
17+
2. A name
18+
3. A definition
19+
4. References to specific enumerated clauses
20+
1. If the Import Statement includes specific references, only those referenced sections or subsections are Imported into the document and the rest of the Package is ignored and do not form part of the document.
21+
5. Packages that are Imported into a document are read inline as if they are subsections of the section of the document where they are Imported.  They are not attached to the beginning or end of the document akin to traditional appendices or schedules.  For clarity, an Import Statement in the contract are deemed to be substituted with the corresponding contents of the Package.
22+
6. Examples:
23+
<!-- Examples are missing -->
24+
2. Clause Enumeration
25+
1. All subdivided text in a Package, be they sections, subsections or any other form of subdivided text will be enumerated with cardinal numbers.  For example, there may be sections and several levels of subsections.  The reference to a sub-subsection would read as Section 1(2)(3).
26+
2. To preserve numbering between Package versions, inserted sections between two cardinal numbers may be given decimal enumerators, but will be functionally the same.
27+
3. Versioning and Amendments
28+
1. If the Import of a Project Breeze Package specifies a corresponding version number, the parties shall restrict and prohibit the use of preceding or subsequent versions of the Package in the reading or interpretation of the Package.  The Import shall reference only the exact language used in the specific version referenced.
29+
2. Where the Import of a Project Breeze Package does not specify a version number, the intention is to refer to the Package on the Project Breeze platform including any and all changes in both language and intent made from time to time.
30+
1. Any time a new version of the Package is published on the Project Breeze platform, such version shall undergo an "Acceptance Period" of thirty (30) calendar days beginning from the date it is published.  The Import of a Project Breeze Package without a version number shall refer to the latest version of such Package which is not undergoing an Acceptance Period.  During any Acceptance Period, any party may unilaterally object to the changes made by giving clear written notice to all other parties.  Such written notice shall lock the Imported Package and it shall refer to the latest version of the Package not undergoing an Acceptance Period from the date the written notice was given.
31+
2. At the end of the Acceptance Period, the new version shall replace the existing version with an effective date of the end of the Acceptance Period.
32+
3. Where a section reference in the Import Statement is no longer accurate to a new version, the section reference shall refer, to the greatest extent possible and in good faith, the natural successor based on the history of changes available.  Where such context remains ambiguous, the section reference shall refer to the latest version in which a natural successor can be determined.
33+
4. Document Continuity
34+
1. In the event that the Project Breeze platform is unavailable for any reason, the GitHub repository at [https://github.com/ProjectBreeze/ProjectBreeze](https://github.com/ProjectBreeze/ProjectBreeze) is an accurate and exact duplicate of the content on the Project Breeze platform.  The corresponding Package on GitHub shall have the same force as the Package on the Project Breeze platform.
35+
5. Hierarchy
36+
1. By the very nature of incorporating and amending referenced Packages, provisions may overlap and contradict each other.  To determine which provision shall govern and control, Project Breeze strictly adheres to a hierarchy of levels in which overlapping or contradictory provisions in a higher level of the hierarchy will override those in a lower level.  For clarity, the governing and controlling provision will be the provision found in the higher level Package.
37+
2. In the event where the hierarchy does not establish an unambiguous overriding provision, the provision that appears earlier in the document shall govern and control.  For the purposes of determining an overriding provision, the Import of a Package shall occur inline, meaning that its placement in the document lies where the reference is made and not at the end of the document like traditional appendices and schedules.
38+
3. To determine establish the hierarchy, the lowest level comprises of Packages which do not contain references to any other Package.  Packages which reference the lowest level are next in the hierarchy and the level will continue to raise with each subsequent reference.  The final document drafted by the end-user is on the highest level of the hierarchy, and will govern and control over any Package.
39+
6. Definitions
40+
<!-- Include clarification on: -->
41+
<!-- SCOPING DEFINITIONS WITHIN THE PACKAGE IF CONFLICTION -->
42+
<!-- REFERENCE RULES TO REFER TO DEFINING PACKAGE -->
43+
7. Metadata, Instructions, Comments and Formatting
44+
1. The metadata, instructions, comments and formatting contained in each Package are for reference purposes only and shall not affect in any way the meaning or interpretation of the Package or any document it is made part of.
45+
4. Syntax
46+
1. Intention
47+
1. The intention of Project Breeze is to standardize drafting language to reduce ambiguity where it is not intended.  Many of the syntactic and structural choices made by Project Breeze deliberately mirror basic computer engineering concepts and such concepts may be used to further clarify areas where these Interpretive Guidelines alone are insufficient.
48+
2. Keywords
49+
1. Whether capitalized or not, except as otherwise expressly provided or unless the context otherwise requires, the following keywords shall have the following meanings:
50+
<!-- Definitions should be made to the keywords -->
51+
1. Import
52+
2. Override
53+
3. Package
54+
5. Best Practices
55+
<!-- Entirely missing -->
56+
1. Git
57+
2. Backups
58+
1. Though GitHub is a reliable secondary store of Project Breeze materials, users with important legal documents should take advantage of the many tools available on GitHub to backup Packages from time to time (including downloading, cloning and forking).
59+
3. General formatting
60+
1. Underlining is the preferred styling to make text conspicuous when required.

0 commit comments

Comments
 (0)