Docs Home

Goldie Blocks is an AI-assisted legal document drafting platform.

Lawyers or admins define reusable document templates made up of modules. Each module combines the data that must be collected with authored blocks that render document text from that data. This keeps question design, data structure, and drafting content tightly coupled, so the lawyer can think in one place about:

• what information needs to be collected from the user
• how that information should be interpreted
• which authored blocks should render from it
• which clause variant should be used in different situations

Modules can also contain multiple block variants plus human-authored conditions for when each variant should render.

At runtime, the app guides a user through an authenticated AI interview, stores structured answers, party details, and conversation history, then renders applicable authored blocks from the collected data. Document generation is the ordered rendering of the relevant modules and blocks.

The modular model also acts like a state machine. Because progress is stored per module, a new conversation thread can see what has already been completed, what collected data exists, and which modules still need to be asked or revisited.

Why This Design

The load-bearing idea in the system is the self-describing unit of content: a module (and, under the block-based data model, a block) carries its own capture logic — typed field declarations, interview guidance, flow conditions — alongside the prose it renders. This is what separates the platform from both document-assembly tools (where variables belong to a monolithic template) and generic AI drafting (where output has no structured substrate). It produces four properties the rest of the architecture exists to protect:

1. The library compounds. Because a unit travels with its questions, data shape, and conditions, promoting it to the library produces a live component, not dead text. Every matter worked can add units that make the next matter faster. Copy-write promotion with derivedFrom lineage keeps this reuse auditable.
2. Schema is authored, not engineered. The Convex tables are deliberately generic (documents / modules / blocks); the domain schema — what a will or a services agreement collects — is declared in the DSL by authors. New document types require authoring, not migrations or deploys. This is the property that lets the same engine serve other report-generating domains by swapping the semantic type registry and content library.
3. Output is auditable. Every value in a generated document traces to a typed, validated, versioned field collected against a declared schema. The AI interview fills a schema; it does not freestyle prose. In liability-bearing professional work this provenance is the defensible difference from freeform LLM generation.
4. The agent is grounded once, not per domain. The document agent operates on the uniform document → module → block grammar (guide text, closed select options, server-validated writes). It never needs domain-specific engineering to drive a new document type.

When making design decisions, protect these properties. Changes that couple capture logic to a fixed database schema, strip declarations from the portable unit, or let generation bypass typed validation trade away the system's core value.

Use these docs in this order:

• Tech Stack for implementation context

• Schemas for the data model

• Workflows & Logic for runtime behavior

• Coding Rules for engineering conventions

• Tech Stack

• Schemas

• Coding Rules

• Workflows & Logic

Phase Tags

Two product surfaces share these docs: the local skill (a standalone Claude skill that runs an interview from a folder of YAML/Markdown files) and the hosted app (the Convex-backed multi-user product). Both surfaces share the same authoring DSL, document/module/block model, and reference grammar. They differ in everything to do with persistence, identity sync, lifecycle promotion, and multi-user concerns.

To keep one source of truth without confusing readers about what's needed when, fields and sections are tagged by phase:

How to read this:

• If you're working on the local skill, read everything tagged [skill]. You can skip [app] sections — they describe Convex-backed shapes the skill never sees.
• If you're working on the hosted app, read both [skill] and [app]. The app builds on top of the same DSL the skill uses; it adds persistence and multi-user surfaces around it.
• If a field has no tag, it's [skill] by default (the DSL is the load-bearing shared surface).

Tags appear three places: page-level frontmatter (phase: skill | app), section headings (## Promotion semantics [app]), and rows in field tables. When a field has different meaning across phases (e.g. reuseType is always working in the skill but also supports library in the app), the row is tagged [skill] for the skill-relevant subset and [app] for the app-only values.

The DSL grammar itself is the same in both. A YAML file that conforms to the DSL is valid in the local skill and in the hosted app alike; the difference is what runs the file.