Vertical design systems — architecture + legal documents as first pilot

[mgoulao]

Description

Introduce the concept of vertical design systems — domain-specific template families that share styling, base models, and assets — and ship a legal document vertical as the first implementation.

Today each built-in template is a standalone class with its own fonts, colors, and spacing. There's no way to say "these templates belong together" or to inherit shared domain vocabulary. A vertical design system would bundle:

• Shared Typst styling — a theme file (fonts, colors, spacing, heading rules) imported by every template in the family.
• Shared Python base models — e.g. a LegalBase with fields like court, case_number, jurisdiction, parties that all legal templates inherit, so data flows consistently across briefs, memos, and motions.
• Shared assets — court-approved fonts, seal images, signature block components.

Why legal first

Legal documents have rigid formatting requirements where Typst's deterministic layout genuinely matters:

• Line numbering — many court filings require numbered lines (California state courts, federal courts for certain motions).
• Court-specific layouts — margin, font, and spacing rules vary by jurisdiction
• Case captions — structured blocks with court name, parties, case number, and document title.
• Citation formatting — Bluebook-style references with specific italicization and abbreviation rules.
• Signature blocks — attestation lines, notary blocks, certificate of service sections.
• Exhibit labels — numbered/lettered exhibit stamps and separator pages.

This also ties into NeuralShift's work in legal AI, creating a natural feedback loop between product use and template refinement.

Acceptance criteria

Architecture (TemplateFamily)

• New TemplateFamily (or DesignSystem) base concept that groups related templates with a shared theme and shared base fields
• A family-level Typst theme file (e.g. legal-theme.typ) that member templates import for consistent styling
• A Python base class pattern (e.g. LegalBase(Template)) with shared fields that specific legal templates extend
• .typy packages can declare which family they belong to via manifest metadata, inheriting the family's theme
• At least one example showing how a third party could create a new vertical (e.g. a stub clinical or financial family) using the architecture

Legal templates (first vertical)

• LegalBriefTemplate — court filing with line numbering, case caption block, signature block, and certificate of service
• LegalMemoTemplate — internal legal memorandum with issue/analysis/conclusion structure, citation-friendly formatting
• Both templates share a LegalBase with common fields: court, case_number, jurisdiction, parties, attorney_info
• Line numbering support that can be toggled on/off and configured (start number, interval)
• Case caption component as a reusable Typst function (court name, parties with "v.", case number, document title)
• Signature block component with configurable lines (attorney signature, date, bar number, firm)
• At least one example script per template in examples/
• Templates packaged as .typy packages (validates the packaging workflow end-to-end)

Documentation

• New docs page explaining the vertical design system concept and how to build a custom vertical
• Legal templates documented in templates.md with field schemas
• Cookbook recipe showing a realistic legal document generation workflow

Notes

• The existing 7 templates don't need to be refactored into a family immediately — the "default" set can remain standalone while the architecture is proven on the legal vertical.
• Line numbering in Typst can be achieved with set par(numbering: ...) or custom state tracking — worth prototyping early since it's a hard requirement.