fix(specs): Resolve collaborators field contradiction in Conditions documents

- Override collaborators description in Conditions to clarify they cannot update
- Update Conditions document update rule documentation to state only author can update
- Add drafts requirement: conditions must be included on every submission including drafts
- Add collaborators exclusion: only document signer must accept conditions, not collaborators
- Update JSON, CUE, and markdown documentation for consistency
- Aligns with plan requirements for explicit acceptance, drafts, and individual signer responsibility

Author: nathanbogale

docs/src/architecture/08_concepts/signed_doc/docs/conditions.md

@@ -255,8 +255,8 @@ For example:
 * Contest-level conditions should be signed by Contest Admin or a parent-level
   admin
 
-Updates are allowed by the original author and from the 'collaborators' metadata field
-of the previous submitted document's version.
+Updates are allowed only by the original author of the document.
+Collaborators listed in the `collaborators` metadata field do not have permission to update Conditions documents.
 
 ## JSON Specification Requirements
 
@@ -337,7 +337,7 @@ Add a new entry to the `docs` section with the following structure:
       "user": []
     },
     "update": {
-      "description": "Updates are allowed by the original author and from the 'collaborators' metadata field of the previous submitted document's version.",
+      "description": "Only the original author can update and sign a new version of documents.",
       "type": "author"
     }
   },

docs/src/architecture/08_concepts/signed_doc/metadata.md

@@ -488,6 +488,18 @@ The validation process for user-submitted documents involves transitive collecti
 becomes required and must be present in the user document. **If the unified list is empty** (no conditions are
 required), the `conditions` field may be omitted.
 
+**Drafts Requirement**: Conditions must be included on **every submission**, including draft versions of proposals
+or other documents. This ensures positive and current assent at every stage of document creation. Without this
+requirement, a user could accept terms for the first draft, change their mind, and then submit a subsequent draft
+without the terms, meaning their assent is no longer positively asserted. It also ensures that rules, such as those
+against objectionable material, apply to the document at every stage of its creation.
+
+**Collaborators Exclusion**: The acceptance of terms is tied to the act of submission by an individual. The terms
+and conditions apply only to the individual who signs and submits the document. Collaborators listed on the
+document are **not required** to accept the conditions. This mirrors how contracts typically work, where each
+party must sign individually. Only the document author (signer) must include the `conditions` field to indicate
+their acceptance.
+
 **Validation Rules:**
 
 * The user document's `conditions` array must exactly match the union of all required conditions from the parameter hierarchy

specs/definitions/signed_docs/docs/conditions.cue

@@ -84,6 +84,29 @@ docs: #DocumentDefinitions & {
 				type:     signed_doc_types.allDocNames
 			}
 
+			collaborators: {
+				required: "optional"
+				description: """
+					A list of collaborators who may be associated with this document.
+
+					**Important**: For Conditions documents, only the original author can update
+					and sign new versions. Collaborators listed here do not have permission to
+					publish updates to this document. This field is optional and may be used for
+					documentation or organizational purposes only.
+				"""
+				validation: """
+					For Conditions documents, collaborators do not have update permissions.
+					Only the original author can create new versions of Conditions documents.
+
+					In the event there are **MULTIPLE** `collaborators` listed, they **MUST** be
+					sorted.
+
+					Sorting for each element of `collaborators` follows the same sort order as
+					specified for Map Keys, as defined by CBOR Deterministic Encoding
+					(4.3.2 Length-First Map Key Ordering).
+				"""
+			}
+
 			revocations: required: "optional"
 		}
 

specs/signed_doc.json

@@ -1659,10 +1659,10 @@
           "validation": "Chained Documents do not support collaborators.\nAny document which is attempted to be published in the sequence\nwhich is *NOT* published by the author of the first document in the\nsequence is fraudulent, and to be discarded.\n\nIn addition, the chained document *MUST*:\n\n* Not have `collaborators`;\n* Have the same `id` as the document being chained to;\n* Have a `ver` that is greater than the `ver` being chained to;\n* Have the same `type` as the chained document;\n* Have `parameters` match;\n* Have not be chaining to a document already chained to by another document;\n* Have its absolute `height` exactly one more than the `height` of the document being chained to.\n\nIF any of these validations fail, then the entire sequence of documents is INVALID.\nNot just the current document."
         },
         "collaborators": {
-          "description": "A list of collaborators who may also publish updates to versions of this document.\nThis should include all parties who have not signed this document directly.\n\nEvery subsequent version can amend the collaborators list.\nHowever, the initial Author can never be removed from being able to\npublish a new version of the document.",
+          "description": "A list of collaborators who may be associated with this document.\n\n**Important**: For Conditions documents, only the original author can update and sign new versions.\nCollaborators listed here do not have permission to publish updates to this document.\nThis field is optional and may be used for documentation or organizational purposes only.",
           "format": "Collaborators Reference List",
           "required": "optional",
-          "validation": "This list does not imply these collaborators have consented to collaborate, only that the author/s\nare permitting these potential collaborators to participate in the drafting and submission process.\nHow collaborators are counted on a final submission is determined by a parameter defined at the\nBrand/Campaign/Category level (parameter name TBD). \nDepending on that configuration:\n\n* All listed collaborators may be required to submit a `final` Submission Action in addition\n  to the author; **OR**\n* Only collaborators who submit a `final` Submission Action for the referenced version are\n  included as collaborators on that submission.\n\nIf the parameter is not present, default to the latter mode (only final-signing collaborators are\nincluded).\nIn all modes a document is only considered final when the original author has submitted `final`.\n\nIn the event there are **MULTIPLE** `collaborators` listed, they **MUST** be sorted.\n\nSorting for each element of `collaborators` follows the same sort order as specified for Map Keys, \nas defined by CBOR Deterministic Encoding (4.3.2 Length-First Map Key Ordering)."
+          "validation": "For Conditions documents, collaborators do not have update permissions.\nOnly the original author can create new versions of Conditions documents.\n\nIn the event there are **MULTIPLE** `collaborators` listed, they **MUST** be sorted.\n\nSorting for each element of `collaborators` follows the same sort order as specified for Map Keys, \nas defined by CBOR Deterministic Encoding (4.3.2 Length-First Map Key Ordering)."
         },
         "id": {
           "description": "Document ID, created the first time the document is created.\nThis must be a properly created UUIDv7 which contains the\ntimestamp of when the document was created.",
@@ -2759,7 +2759,7 @@
           "validation": "In addition to the validation performed for `Document Reference` type fields: \n\n* Any linked referenced document that includes a `parameters` metadata must match the \n`parameters` of the referencing document,\nor a parent of those `parameters`.\n\nFor example, a linked reference to `Contest Parameters` is transitively a reference to\nthe Parameters document it references, and each parameters document they reference \nuntil the `Brand` parameters document is reached.\n\nThe use case here is for Templates.\nThe profile template, or proposal templates could be defined at any of these\nlevels, and as long as they all refer to the same chain of parameters in the\nhierarchy they are all valid."
         },
         "conditions": {
-          "description": "An array of references to all Conditions documents that the user has accepted.\n\nMust include ALL conditions required by the parameter hierarchy (Brand → Campaign → Category → Contest).\nThe act of listing these references and signing the document serves as the user's digital signature and acceptance.\n\n**Schema-level requirement**: This field is marked as optional in the schema, allowing documents to be created without it.\n\n**Validation-level requirement**: During validation, this field becomes required when the parameter hierarchy specifies conditions.\nIf conditions are required by any level in the parameter hierarchy (Brand, Campaign, Category, or Contest),\nthe field must be present and must exactly match all required conditions. If no conditions are specified\nin the parameter hierarchy, the field may be omitted.",
+          "description": "An array of references to all Conditions documents that the user has accepted.\n\nMust include ALL conditions required by the parameter hierarchy (Brand → Campaign → Category → Contest).\nThe act of listing these references and signing the document serves as the user's digital signature and acceptance.\n\n**Schema-level requirement**: This field is marked as optional in the schema, allowing documents to be created without it.\n\n**Validation-level requirement**: During validation, this field becomes required when the parameter hierarchy specifies conditions.\nIf conditions are required by any level in the parameter hierarchy (Brand, Campaign, Category, or Contest),\nthe field must be present and must exactly match all required conditions. If no conditions are specified\nin the parameter hierarchy, the field may be omitted.\n\n**Drafts Requirement**: Conditions must be included on every submission, including draft versions of proposals or other documents.\nThis ensures positive and current assent at every stage of document creation. Without this requirement, a user could accept\nthe terms for the first draft, change their mind, and then submit a subsequent draft without the terms, meaning their\nassent is no longer positively asserted. It also ensures that rules, such as those against objectionable material, apply\nto the document at every stage of its creation.\n\n**Collaborators Exclusion**: The acceptance of terms is tied to the act of submission by an individual. The terms and conditions\napply only to the individual who signs and submits the document. Collaborators listed on the document are not required to\naccept the conditions. This mirrors how contracts typically work, where each party must sign individually. Only the document\nauthor (signer) must include the `conditions` field to indicate their acceptance.",
           "format": "Document Reference",
           "required": "optional",
           "multiple": true,
@@ -2908,7 +2908,7 @@
           "validation": "In addition to the validation performed for `Document Reference` type fields: \n\n* Any linked referenced document that includes a `parameters` metadata must match the \n`parameters` of the referencing document,\nor a parent of those `parameters`.\n\nFor example, a linked reference to `Contest Parameters` is transitively a reference to\nthe Parameters document it references, and each parameters document they reference \nuntil the `Brand` parameters document is reached.\n\nThe use case here is for Templates.\nThe profile template, or proposal templates could be defined at any of these\nlevels, and as long as they all refer to the same chain of parameters in the\nhierarchy they are all valid."
         },
         "conditions": {
-          "description": "An array of references to all Conditions documents that the user has accepted.\n\nMust include ALL conditions required by the parameter hierarchy (Brand → Campaign → Category → Contest).\nThe act of listing these references and signing the document serves as the user's digital signature and acceptance.\n\n**Schema-level requirement**: This field is marked as optional in the schema, allowing documents to be created without it.\n\n**Validation-level requirement**: During validation, this field becomes required when the parameter hierarchy specifies conditions.\nIf conditions are required by any level in the parameter hierarchy (Brand, Campaign, Category, or Contest),\nthe field must be present and must exactly match all required conditions. If no conditions are specified\nin the parameter hierarchy, the field may be omitted.",
+          "description": "An array of references to all Conditions documents that the user has accepted.\n\nMust include ALL conditions required by the parameter hierarchy (Brand → Campaign → Category → Contest).\nThe act of listing these references and signing the document serves as the user's digital signature and acceptance.\n\n**Schema-level requirement**: This field is marked as optional in the schema, allowing documents to be created without it.\n\n**Validation-level requirement**: During validation, this field becomes required when the parameter hierarchy specifies conditions.\nIf conditions are required by any level in the parameter hierarchy (Brand, Campaign, Category, or Contest),\nthe field must be present and must exactly match all required conditions. If no conditions are specified\nin the parameter hierarchy, the field may be omitted.\n\n**Drafts Requirement**: Conditions must be included on every submission, including draft versions of proposals or other documents.\nThis ensures positive and current assent at every stage of document creation. Without this requirement, a user could accept\nthe terms for the first draft, change their mind, and then submit a subsequent draft without the terms, meaning their\nassent is no longer positively asserted. It also ensures that rules, such as those against objectionable material, apply\nto the document at every stage of its creation.\n\n**Collaborators Exclusion**: The acceptance of terms is tied to the act of submission by an individual. The terms and conditions\napply only to the individual who signs and submits the document. Collaborators listed on the document are not required to\naccept the conditions. This mirrors how contracts typically work, where each party must sign individually. Only the document\nauthor (signer) must include the `conditions` field to indicate their acceptance.",
           "format": "Document Reference",
           "required": "optional",
           "multiple": true,