PRD-65: Branded Document Templates v2

Status: Parked (TODO) Priority: P2 — Enhancement (bells & whistles) Created: 2026-02-25 Dependencies: PRD-63 (Document Generation Module), PRD-08 (RAG/Document System) Estimated Effort: MVP 20h | Full 36h

---

Executive Summary

PRD-63 delivered the document generation pipeline (PDF/DOCX/XLSX via WeasyPrint + Jinja2). Templates exist in the database with HTML, JSON schemas, and sample data. But the LLM has no awareness of available templates or their schemas, rendering the template system decorative. Additionally, templates are generic — users cannot brand them with their company identity (logo, colors, header/footer, address).

This PRD upgrades templates from "developer-seeded HTML" to a user-owned branded document system where every generated report, invoice, and export carries the user's professional identity.

---

Problem Statement

Current State (PRD-63 shipped)

1. 5 seed templates exist (Basic Report, Invoice, Executive Summary, Meeting Notes, Data Export)

2. Templates have data_schema (JSON Schema) defining required fields

3. Templates have template_content (HTML+CSS with Jinja2 tags)

4. LLM calls generate_document(title, format, data, template_name?) tool

5. Templates tab shows templates in the UI (CRUD works)

What's Broken

1. LLM is blind to templates — The generate_document tool description is static. The LLM doesn't know which templates exist in the workspace, what schemas they expect, or when to use each one. It always dumps data into {sections: [{title, content}]} regardless of template.

2. No branding — Templates use generic Automatos styling. Users can't upload their logo, set company colors, define headers/footers, or add their address/contact info.

3. No template designer — Creating/editing templates requires writing raw HTML+CSS and JSON Schema. No visual builder, no preview, no drag-and-drop.

4. No data source integration — Templates can't pull data from RAG, connected apps (accounting, CRM), or database queries. The LLM must manually research and populate every field.

---

Goals

G1: LLM Template Awareness

The LLM must know which templates exist, understand their schemas, and select the right template for the task.

G2: Company Brand Identity

Users upload their logo, set brand colors, company name/address, and this identity is automatically applied to every generated document.

G3: Template Designer (Phase 2)

Visual template editor with live preview — no HTML/CSS knowledge required.

G4: Data Source Binding (Phase 3)

Templates can declare data sources (RAG collections, connected apps, SQL queries) that auto-populate fields before generation.

---

Technical Design

Phase 1: LLM Awareness + Brand Identity (MVP)

1a. Dynamic Tool Description

When building the tool list for an agent, query the workspace's active templates and inject them into the generate_document tool description:

Available templates for this workspace:
- "Basic Report" (PDF) — sections + metrics. Required: title, sections[{title, content}]
- "Invoice" (PDF) — line items + tax. Required: company, client, line_items, total
- "Executive Summary" (PDF) — highlights + recs. Required: title, highlights[]
- "Meeting Notes" (DOCX) — agenda + action items. Required: title, date, attendees[]
- "Data Export" (XLSX) — tabular data. Required: columns[], rows[][]

Always specify template_name when a matching template exists.
Populate ALL required fields from the template's schema.

This approach costs zero extra tool calls — the LLM sees templates in the tool description and picks the right one.

1b. Brand Identity Model

New database model workspace_brand:

workspace_brand:
  workspace_id (FK, unique)
  company_name: string
  company_address: text
  company_email: string
  company_phone: string
  company_website: string
  logo_url: string (S3 key, uploaded via API)
  logo_base64: text (cached for PDF embedding)
  primary_color: string (hex, default #ff6b35)
  secondary_color: string (hex, default #1a1a2e)
  accent_color: string (hex)
  font_family: string (default 'Inter')
  header_html: text (optional override)
  footer_html: text (optional override)
  created_at, updated_at

1c. Brand Injection into Templates

All templates get automatic brand injection at render time:

• {{ brand.logo }} — base64 data URI for the company logo

• {{ brand.company_name }}, {{ brand.address }}, etc.

• CSS variables: --brand-primary, --brand-secondary, --brand-accent, --brand-font

• Default header: logo + company name + document title + date

• Default footer: company address + page number + "Generated by Automatos AI"

Templates can override header/footer or use the workspace default.

1d. Logo Upload API

POST /api/workspaces/{workspace_id}/brand
  - multipart/form-data with logo file + brand fields
GET /api/workspaces/{workspace_id}/brand
  - returns current brand settings
PUT /api/workspaces/{workspace_id}/brand
  - update brand fields

Logo stored in S3: workspaces/{workspace_id}/brand/logo.{ext}

1e. Frontend: Brand Settings Page

Settings > Brand Identity:

• Logo upload (drag & drop, crop/resize)

• Company details form (name, address, email, phone, website)

• Color picker (primary, secondary, accent)

• Font selector

• Live preview showing a sample document with current branding

Phase 2: Template Designer (Visual Editor)

• Drag-and-drop section builder (header, metrics row, text section, table, chart, footer)

• Live HTML preview powered by the actual Jinja2 renderer

• Schema auto-detection from template variables

• Template marketplace: share/import templates between workspaces

• Version history with diff view

Phase 3: Data Source Binding

• Templates declare data_sources in their schema:

  {
    "data_sources": {
      "revenue_data": {"type": "rag_query", "collection": "financial-reports", "query": "quarterly revenue"},
      "invoice_items": {"type": "composio_app", "app": "QUICKBOOKS", "action": "list_invoices"},
      "user_stats": {"type": "sql_query", "query": "SELECT count(*) FROM users WHERE created_at > now() - interval '30 days'"}
    }
  }

• Before generation, the system auto-executes each data source and merges results into the template data

• LLM can still override/supplement auto-populated data

---

Expanded Template Library (Target: 20+)

Reports

1. Basic Report (exists)

2. Executive Summary (exists)

3. Quarterly Business Review

4. Project Status Report

5. Competitive Analysis

6. Market Research Report

7. Technical Specification

Financial

1. Invoice (exists)

2. Expense Report

3. Budget Summary

4. Financial Statement

5. Quote / Estimate

Operations

1. Meeting Notes (exists)

2. SOW (Statement of Work)

3. Project Proposal

4. Onboarding Checklist

5. Incident Report / Post-Mortem

Data

1. Data Export (exists)

2. Analytics Dashboard (PDF with charts)

3. KPI Scorecard

4. Survey Results Summary

Legal / Compliance

1. NDA Template

2. Terms of Service

3. Privacy Policy Summary

---

Success Metrics

Metric	Target
LLM selects correct template	>80% of document generation requests
Brand identity configured	>50% of active workspaces
Template usage (non-Basic Report)	>40% of generated documents
User-created custom templates	>1 per active workspace

---

Implementation Order

1. Phase 1a: Dynamic tool description with template awareness (4h)

2. Phase 1b-c: Brand identity model + injection (8h)

3. Phase 1d: Logo upload API + S3 storage (4h)

4. Phase 1e: Frontend brand settings page (6h)

5. Expand template library to 20+ templates (8h)

6. Phase 2: Visual template designer (20h — separate sprint)

7. Phase 3: Data source binding (16h — separate sprint)

---

Non-Goals (for this PRD)

• WYSIWYG document editor (Google Docs-style) — too complex, not needed yet

• Real-time collaborative template editing — single-user is sufficient

• Template versioning with rollback — v1 just overwrites

• Print-to-PDF from browser — server-side WeasyPrint is the renderer

---

Open Questions

1. Should brand settings live at workspace level or organization level?

2. Do we need template permissions (admin-only vs all members can edit)?

3. Should the expanded template library be seeded per workspace or pulled from a shared marketplace?