feat(contract): add contract 1.0 model

[niallroche]

Closes N/A

Introduces a substantive org.accordproject.contract@1.0.0 model for agreement provenance and template identity. This is the first prerequisite for moving signature, runtime and obligation models onto a coherent 1.0 dependency family.

Changes

• Add Contract and Clause assets in the versioned 1.0 namespace.
• Require an agreement content hash and template reference on new contract instances.
• Add a portable AgreementReference for downstream obligation, evidence and protocol models.
• Add TemplateReference with archive and optional artifact-manifest hashes.
• Add named, hash-addressed TemplateArtifact entries for logic, model, grammar, prose, documentation, tests and resources.
• Allow executable artifacts such as logic.ts to record their path, language, runtime and entry-point role.
• Preserve the existing unversioned and contract@0.2.0 models unchanged for compatibility.

Flags

• org.accordproject.contract is proposed as the canonical family for new models; the legacy org.accordproject.cicero.contract family remains unchanged pending explicit migration guidance.
• archiveHash is mandatory in 1.0 so template provenance is verifiable rather than descriptive.
• An artifact list requires a normative manifest canonicalization rule before publication; the model cannot express the conditional requirement that artifactManifestHash accompany artifacts.
• AgreementReference.agreementId maps to Contract.contractId when the complete asset is available.
• Signature PR feat(signature): add org.accordproject.signature@1.0.0 #195 should import TemplateReference from this namespace once published.
• Obligation PR Codex/obligation 1.0 models #196 should replace its local agreement reference with the shared 1.0 type once published.

Screenshots or Video

Not applicable. This PR contains a Concerto model change only.

Related Issues

• Pull Request feat(signature): add org.accordproject.signature@1.0.0 #195
• Pull Request Codex/obligation 1.0 models #196
• Issue DIDs and Verifiable Credentials as the Identity and Verification Substrate for Accord Project [Contract Governance] apap#183

Author Checklist

• Ensure you provide a DCO sign-off for your commits using the --signoff option of git commit.
• Vital features and changes captured in unit and/or integration tests
• Commits messages follow AP format
• Extend the documentation, if necessary
• Merging to main from niallroche:codex/contract-1.0-model

[mttrbrts]

... Identified by identifier?

[niallroche]

This is intentionally a concept rather than an identifiable asset. It needs to be a self-contained value that can be embedded in contracts, signatures, states and obligations without requiring a separately registered template asset.
I agree that identifier is ambiguous, so I propose renaming it to templateId. The referenced archive is ultimately distinguished by its template id, version and archive hash, rather than by the identifier alone.
There is also a duplicate TemplateReference in #195. I plan to hold that PR and either import this shared type or remove the redundant transaction-level field when #195 moves to the 1.0 contract model.

[mttrbrts]

Should be identified too?

[niallroche]

Also intentional. agreementId identifies the agreement being referenced; it does not identify the AgreementReference value itself.
Making the reference an asset identified by agreementId would introduce identity and registry semantics for what is intended to be a portable provenance snapshot. It would also be problematic for distinct references to different clauses within the same agreement, since they would share the same asset identity.
I will clarify this distinction in the model documentation.

[mttrbrts]

Missing Template reference?

[niallroche]

Yes—good catch @mttrbrts , although I want to distinguish a clause’s source template from an enclosing contract template.
As in our current model a clause may be authored independently, maintained in a clause bank, and reused by multiple contract templates. A clause should therefore optionally identify its own source template rather than inherit provenance from whichever contract happens to use it.
Here is what I propose:

abstract asset Clause identified by clauseId {
  o String clauseId
  o ContentHash clauseHash optional
  o TemplateReference sourceTemplate optional
}

I have added sourceTemplate that identifies an independently versioned clause template or archive when one exists. It does not identify the contract templates that subsequently incorporate the clause.
The field is optional because a standalone or directly authored clause may not have been produced from a template at all. In serialised data, the property would be omitted rather than represented as null.

A contract template that consumes a banked clause should record that composition in its own manifest or composition metadata. I don't think it makes sense for a reusable clause should not maintain a changing list of every template that uses it. We could maybe build some tooling to aggregate this if needed