Templates

Last updated Jun 14, 2026

What templates are

A Template is a versioned, reusable definition for generating a Document. Each template carries:

• A kind — the Document.type value the template produces. The join key from Template → Document; multiple templates can share the same kind (variants).
• A category — formation, financing, commercial, governance, tax.
• A version — semver or date-coded; templates are immutable per version.
• An availability — preview, ga, deprecated, or retired (see Versioning and deprecation).
• A successor_template_id — set on deprecated and retired rows; pointer to the rollover replacement.
• An optional cover_page_field_schema — JSON Schema for the negotiable fields on the Cover Page (null for templates that derive every variable from entity state, like bylaws and charters).
• An attachable_to[] array — parent template_ids this template can be attached to as a child Document.

template_id is conventionally formatted matter:<kind>[:<variant>]:<version> (e.g. matter:safe:postmoney_cap_only:2018-09, matter:bylaws:de_c_corp:2026-04-26). The format is descriptive — clients should treat the full string as opaque and filter on the structured fields.

The Cover Page model

Matter's commercial templates follow the Cover Page model: an immutable Standard Terms body plus a small editable Cover Page populated with the deal-specific fields. Both parties sign the Cover Page; it incorporates the Standard Terms by reference. The combined artifact is the executed Agreement.

The negotiation surface is the Cover Page — typically just parties, fees, and term. By constraining what's negotiable to a small, well-defined surface, the Cover Page model avoids the redline-everything pattern that makes traditional contracting slow.

On the Document resource, the Cover Page model is expressed via three fields:

For non-Cover-Page templates (formation packet, SAFE, bylaws), cover_page_fields and standard_terms_template_id are null — the template renders against entity state, not against caller-supplied negotiation values.

Variants

Multiple templates may share the same kind. SAFE alone has variants spanning post-money × {cap-only, discount-only, cap-and-discount, MFN}; each variant is its own row with its own template_id and Cover Page field schema, all carrying kind: safe.

The picker is the natural shape that follows: the client lists templates filtered by kind, the user picks a row, and the client renders a form from that row's cover_page_field_schema.

GET /v1/templates?kind=safe&availability=ga

returns the variant rows; the user picks matter:safe:postmoney_cap_only:2018-09; the client renders the field form from the schema and POSTs the values back as cover_page_fields on generateDocument.

Common operations

Workflow — using a template

GET /v1/templates?kind=safe&availability=ga
GET /v1/templates/matter:safe:postmoney_cap_only:2018-09
POST /v1/documents
  entity_id: ent_...
  template_id: matter:safe:postmoney_cap_only:2018-09
  cover_page_fields: { investor_name: "...", investment_amount_usd: 50000, valuation_cap_usd: 5000000 }

Matter renders the document from the supplied fields against the entity state, attaches the immutable Standard Terms by reference, and creates the Document with provenance: matter_generated and execution_status: draft. Send via createSigningEnvelope to collect signatures.

Picker — board consents

The v1 governance catalog supports the board-and-stockholder consent surface. Filter by kind to scope the picker:

GET /v1/templates?kind=board_consent&availability=ga

returns 12 rows (11 substance-specialized + 1 general):

The Day-0 organizational consent (?kind=initial_board_resolution), the officer-change cascade (?kind=officer_change_consent), the director-change cascade (?kind=director_change_consent), and the seven stockholder-side parallels (?kind=written_consent) carry their own dedicated rows.

Specialized rows have cover_page_field_schema: null — substance is derived from the linked resource (Round, EquityPlan, CorporateTransaction, etc.) and entity state. The two :general: rows are the only consent templates with a non-null Cover Page schema, which accepts caller-supplied recitals[], resolved_clauses[], and effective_date for any Resolution.kind not covered by a specialized template.

Status today

The registry surface ships in the spec. The v1 catalog ships 22 governance-category templates (see picker above). Other categories ingest via separate workstreams. Until those land:

• ?category=formation, ?category=financing, ?category=commercial, ?category=tax return zero rows.
• generateDocument calls that pass a template_id outside the v1 governance catalog are rejected.
• Documents with provenance: counterpart_received (state certificate filings, EIN acknowledgements, mail scans) and provenance: user_uploaded (custom-typed contracts) work today via the upload path with template_id: null.
• The Document.type enum carries the commercial and hiring categories (csa, mnda, psa, pilot_agreement, independent_contractor_agreement, advisor_agreement, employment_agreement, etc.) so callers can categorize ad-hoc uploads correctly today.

See conventions: templates for the deeper architectural commitments — provenance classification, Cover Page model, versioning, and deprecation.

What Matter does and does not do

Matter is the standardized-template tier. The product makes baseline legal artifacts trivial to generate, sign, and track — formation packets, SAFEs, mutual NDAs, SaaS subscription agreements, and the like — by constraining each artifact to a small Cover Page negotiation surface sitting on top of an immutable Standard Terms body.

Matter is not a custom-legal AI platform. Heavily-negotiated commercial deals, M&A definitive agreements, and complex licensing structures where the Standard Terms themselves need redlining are out of scope. For that work, founders should use a custom-legal AI platform or outside counsel.