Skip to content

Agreements and documents

Module id: agreements

The contract that binds parties to a product, plus the document record that evidence hangs on.

Signature providers and content stores stay behind adapters. This module keeps the contract and the document metadata.

Agreements, read top to bottom: journeys call contract services, then terms and signatures, then the contract and document records
Read top to bottom. Journeys call the contract services. The domain handles terms, parties, and signatures. The core stores the contract and the document.

There is no exp-agreements repository. Lending and onboarding journeys call these APIs when a contract is part of the step.

What it owns

  • Contracts, status history, and contract events
  • Parties and terms on a contract, including term templates
  • Document metadata, versions, folders, tags, and permissions
  • Signature requests and signature verification records

What it does not own

  • The party of record. That is customers.
  • The product definition. That is products.
  • The signature vendor or the content store. Those stay behind an adapter.
  • Loan schedules and collateral. Those are lending.

Repositories

Repository Layer What it holds OpenAPI
domain-common-contracts Domain Contracts, parties, terms, signatures, documents; lookup by party openapi.yml
core-common-contract-mgmt Core Contract lifecycle, terms, parties, events, status openapi.yml
core-common-document-mgmt Core Document metadata, versions, folders, signature requests openapi.yml

How the pieces fit

domain-common-contracts is the place a journey asks for a contract, its parties, its terms, its signatures, and its documents. A query by party answers "which contracts name this party?"

core-common-contract-mgmt persists the contract under /api/v1/contracts, with parties, terms, documents, events, and status history. Term templates and validation rules live beside the contract, not inside the channel.

core-common-document-mgmt persists document metadata, versions, folders, tags, permissions, search, signature requests, and signature verification. The signature provider resource is a boundary record. The provider toolkit stays in an adapter, not in the domain service.