Templates — overview

Last updated Jun 14, 2026

Matter Templates is the system every legal document a company signs flows through. One catalog of versioned platform templates (Action of Incorporator, Bylaws, Board Resolutions, SAFEs, NVCA Series A documents, NDAs, MSAs, …), with two narrower override layers — org-level customizations that apply to every entity in an org, and entity-level overrides for one-off situations. Every render is content-addressed; every signed document carries a tamper-evident audit chain anchored to a public transparency log.

Use the same surface to:

• Render an unmodified Ironsides Certificate of Incorporation for a new Delaware C-Corp.
• Customize a SAFE template at the org level to auto-attach your pro-rata side letter.
• Override the Notice Address default for a single entity that uses a different registered agent.
• Sign documents via Matter's native e-signature path (esign / wet_signature / agent_authorized).
• Export a litigation-grade evidence bundle that verifies in court using only public artifacts.

Three-tier model

Every render composes four layers in this order:

Platform body  →  Jurisdiction Variant  →  Org overlay  →  Entity overlay

The result is the effective set of clause-position selections, field defaults, signer-role renames, and attached children. Body text is never replaced by an overlay — overlays propose values within the platform clauses' three-position grammar. Body-text edits require a fork: an org-private TemplateRevision authored via multipart upload to POST /templates/{template_id}/revisions. Forks are rare, surfaced as a docs-linked CTA in the dashboard's customization editor.

Why a three-position grammar

Each negotiable clause declares three positions:

• standard_position — Matter's default; what every customer gets if they don't customize.
• fallbacks[] — acceptable alternatives. Overlays may select any of these without escalating.
• unacceptable_deviations[] — values that would compromise the document's enforceability. Overlays proposing one of these are server-side rejected with 422 deviation_not_permitted.

The grammar makes governance customization safe by construction: an org can change the default behavior without weakening the document below Matter's enforceability floor.

Layered composition guarantees

• Cross-mode isolation. mode is part of the lookup predicate at every layer — a test-mode customization can never apply to a live render.
• method_forbidden_in_live is union, not intersection. Overlays may ADD forbidden signature methods (e.g. "no agent_authorized for this template in our org"). They may NEVER REMOVE them — a compromised tier_3 token cannot weaken the platform's live-mode signature-method gate on formation documents.
• Overlay-size bounds. Hard cap at 200 clause overlays, 500 field defaults, 50 attachments, 20 signer renames, 256 KB per overlay column. Enforced at three layers: Zod, Postgres CHECK, and x-matter-explainer field documentation.

Render → envelope → sign

A tier_3 agent token follows three steps:

1. POST /templates/{template_id}/render — composes overlays, validates parameters, classifies the document, computes a content-addressed render_fingerprint, and queues a render job. Returns 202 Accepted immediately with { request_id, render_fingerprint }. Terminal status arrives via the document.rendered_from_template webhook.

2. POST /signing_envelopes — wraps the resulting Document in a signing envelope with the resolved signers. ESRA disclosure packet hash

   • intent text + disclosure version captured at envelope create.

3. POST /signing_envelopes/{id}/send — dispatches signing invitations. Webhooks fire to completion. The final signature triggers the archive write: the frozen render bundle lands in the object-lock archive store with 7-year Compliance retention, the Document transitions to executionStatus: executed, and document.archived fires via the WebhookOutbox.

The full flow is reproducible from the OpenAPI spec alone — no out-of-band SDK, no proprietary client library. Render + envelope + sign all expose both REST and MCP surfaces.

Test-mode safety contract

Three independent guards, each sufficient by itself, all required for test- and sandbox-mode renders:

1. PDF watermark. Every page carries a diagonal TEST · DO NOT FILE · sig <fp16> banner at 30% opacity, with the fingerprint suffix anchored to the test-mode KMS key. The watermark is post-processed by pdf-lib after render — engine-agnostic; works for both react-pdf and Playwright pipelines.

2. Cryptographic key separation. Every test signature carries signing_key_fingerprint from the test-mode Ed25519 hierarchy. The .well-known/matter-keys.json endpoint returns mode-segregated key sets; test signatures cannot validate against live keys.

3. Dashboard TEST badge. Amber chip (matching the test-mode banner) on every list row, detail page, and preview thumbnail. Implemented as <TestModeBadge> in @matter/components.

Day-1 inventory

YC SAFE + NVCA Series A templates are placeholder catalog entries with license_review_required: true — bodies land once Matter's licensing clearance with Y Combinator and NVCA is final.

See also

• MCTF format — the seven-file directory shape of a template revision and what every field means.
• Customization — the org + entity overlay editor flow.
• Render and sign — end-to-end agent walkthrough.
• Test-mode safety — deep on the three-layer defense.
• Evidence bundle — the litigation-grade export format + how a court verifies it.
• Multi-jurisdiction — how jurisdiction_scope
  • JurisdictionVariant resolve overrides per ISO-3166-2 code.
• Sources — auto-generated provenance + license catalog.