Chapter 4: Vertical Document Domains

In the previous chapters, we established theoretical foundations and formal frameworks for understanding documents. Now we turn to the practical application: how do these patterns manifest in specific domains? What makes education different from legal services? What patterns appear universally across all domains?

This chapter provides a systematic methodology for analyzing vertical domains and identifying their document requirements. We introduce the concept of domain maturity and catalog cross-domain meta-patterns that recur regardless of industry.

The insights here enable: - Domain analysis: Systematic approach to understanding any new vertical - Pattern recognition: Identifying which patterns apply to which domains - Opportunity assessment: Evaluating which domains benefit most from automation - Implementation planning: Knowing what to build for a given domain

4.1 What Makes a Domain?

Not every industry grouping constitutes a meaningful "domain" for document automation purposes. A domain, in our sense, has specific characteristics that make domain-specific solutions valuable.

Defining Characteristics of a Domain

1. Shared Ontology

A domain has a common set of entities, attributes, and relationships that members understand and use:

Education: Students, Classes, Instructors, Grades, Assignments, Semesters
Legal Services: Cases, Parties, Attorneys, Documents, Deadlines, Courts
Real Estate: Properties, Agents, Clients, Listings, Transactions, Comparables
Healthcare: Patients, Providers, Encounters, Diagnoses, Procedures, Medications

Members of the domain speak a common language. When an educator says "transcript," other educators know exactly what information it contains. This shared understanding enables standardization.

Non-example: "Small businesses" isn't a domain in this sense because a small restaurant, a consulting firm, and a retail shop have entirely different ontologies. Their documents and workflows don't meaningfully overlap beyond generic business functions.

2. Recurring Document Types

The domain has identifiable document types that recur across organizations:

Education: Report cards, transcripts, rosters, certificates (all schools need these)
Legal: Engagement letters, time entry invoices, pleadings (all law firms need these)
Real Estate: Listing agreements, purchase contracts, CMAs (all agents need these)

These aren't one-off custom documents but established genres with conventions.

3. Established Conventions and Standards

Documents follow recognizable patterns with community-accepted formats:

Education: Transcripts have specific required elements; report cards follow grade-period structures
Legal: Court documents have mandatory formats; engagement letters include specific disclosures
Real Estate: MLS listings follow standardized schemas; purchase agreements vary by state but follow templates

These conventions emerge from: - Professional associations (ARMA for records management, ABA for legal) - Regulatory requirements (FERPA for education, state bar rules for legal) - Industry practice (what works gets copied) - Tool standardization (software shapes conventions)

4. Common Workflows and Processes

Organizations in the domain follow similar processes that generate similar documents:

Education: Enrollment → Class assignment → Grade tracking → Progress reports → Transcripts
Legal: Client intake → Matter opening → Time tracking → Document production → Billing
Real Estate: Listing → Marketing → Showing → Offer → Closing

These workflows create predictable document needs at predictable times.

5. Community of Practice

Domain members: - Attend common conferences and events - Participate in professional associations - Read shared publications - Exchange best practices - Recognize each other as peers

This community can evaluate, adopt, and spread domain-specific solutions. Word-of-mouth operates within these networks.

Domain Boundaries and Sub-Domains

Domains can contain sub-domains with specialized needs:

Education Domain contains: - K-12 Public Schools (standardized testing, state reporting) - K-12 Private Schools (admissions, development/fundraising) - Homeschool Co-ops (volunteer coordination, flexible structures) - Higher Education (research administration, accreditation) - Corporate Training (competency tracking, certification)

These share core concepts (students/learners, instructors, assessments) but have domain-specific variations.

Question for system designers: Build for the entire education domain with configuration options? Or build specialized solutions for each sub-domain?

Answer: Depends on overlap: - High overlap (80%+ shared documents) → Single configurable platform - Moderate overlap (50-80%) → Platform with sub-domain modules - Low overlap (<50%) → Separate solutions that share technology but not templates

Industry vs. Domain

"Industry" (SIC/NAICS codes) and "domain" (for our purposes) don't map one-to-one:

Healthcare (one industry) contains multiple domains: - Hospitals (inpatient care, surgery scheduling, complex documentation) - Physician Practices (ambulatory care, simpler workflows) - Laboratories (test orders, results reporting, quality control) - Pharmacies (prescription processing, medication management)

These have different ontologies, documents, and workflows despite being in the same industry.

Conversely, "Member Organizations" isn't an industry but crosses industries—it's a horizontal workflow (membership tracking, directories, communications) that appears in: - Professional associations - Country clubs - Religious organizations - Homeowner associations - Alumni groups

So domain identification requires understanding workflows and ontologies, not just industry classifications.

4.2 Domain Identification Methodology

How do you systematically analyze a potential domain? Here's a repeatable methodology:

Step 1: Entity-Relationship Analysis

Goal: Identify core entities and their relationships

Process: 1. Interview domain experts (3-5 people representing different roles) 2. Ask open-ended questions: - "What are the main things you keep track of?" - "What information matters in your work?" - "Who are the key people/roles in your organization?" - "What's the lifecycle of your work?" (temporal flow)

Listen for nouns → candidate entities
People: Students, Parents, Teachers, Clients, Patients
Things: Products, Properties, Cases, Events
Concepts: Classes, Orders, Appointments, Projects
Identify attributes of each entity
"What do you need to know about a [Student]?"
Required vs. optional
Data types (text, number, date, image)
Map relationships
"How do [Students] relate to [Classes]?"
Cardinality (one-to-one, one-to-many, many-to-many)
Temporal aspects (changes over time?)
Draw entity-relationship diagrams
Visual representation helps validate understanding
Experts can correct misunderstandings
Reveals missing entities or relationships

Output: Preliminary domain ontology with 5-15 core entities and their relationships

Example (Homeschool Co-op):

Core Entities Identified:
├── People
│   ├── Student (the children being educated)
│   ├── Parent (responsible adults)
│   └── Instructor (teachers/coordinators)
├── Academic
│   ├── Class (what's being taught)
│   ├── Subject (curriculum areas)
│   ├── Assignment (work assigned)
│   └── Grade (assessment results)
└── Administrative
    ├── Semester (time periods)
    ├── Enrollment (student-class linkage)
    └── Event (field trips, meetings)

Key Relationships:
- Student enrolled_in Class (M:N via Enrollment)
- Parent parent_of Student (1:N)
- Instructor teaches Class (1:N or M:N)
- Class covers Subject (N:1)
- Assignment belongs_to Class (N:1)
- Grade links Student to Assignment (N:1:N)

Step 2: Document Type Enumeration

Goal: Catalog all document types the domain produces

Process: 1. Collect examples: Ask for actual documents (with sensitive data redacted) 2. Categorize by purpose: Apply communicative function taxonomy - Declarative (reports, directories) - Performative (certificates, contracts) - Directive (schedules, procedures) - Commissive (plans, proposals) - Expressive (reviews, feedback)

Identify frequency and volume:
How often created? (daily, weekly, monthly, quarterly, annually, ad-hoc)
How many instances? (1, dozens, hundreds, thousands)
Example:
- Report cards: Quarterly, 100 students = 400/year
- Certificates: End of year, 100 students × 5 classes = 500/year
- Rosters: Beginning of semester, 10 classes = 20/year
Assess complexity:
Simple (field substitution only)
Moderate (some calculations or conditions)
Complex (multiple relationships, sophisticated logic)
Map to patterns: Which architecture pattern does each use?
Atomic: certificates, individual letters
Directory: rosters, contact lists
Master-Detail: report cards, invoices
Hierarchical: course catalogs, manuals
Matrix: grade sheets, schedules
Identify dependencies: Which documents require which entities?
Report card needs: Student + Grades + Classes
Certificate needs: Student + Class + Completion status
Roster needs: Students + Class

Output: Comprehensive document inventory with metadata

Example (Homeschool Co-op - Partial):

Administrative Documents (14 per year):
1. Student Roster by Class (Directory, moderate, 10× per semester)
2. Master Student Directory (Directory, simple, 2× per year)
3. Instructor Directory (Directory, simple, 2× per year)
4. Class Schedule by Student (Master-Detail, moderate, 100× per semester)
5. Emergency Contact Sheet (Directory, simple, 2× per year)

Academic Documents (400+ per year):
6. Progress Report (Master-Detail, complex, 100× per quarter)
7. Report Card (Master-Detail, complex, 100× per semester)
8. Assignment Sheet (Directory, moderate, 10 classes × 4/semester)
9. Grade Summary (Matrix, moderate, 10× per semester)

Certificates (500+ per year):
10. Completion Certificate (Atomic, simple, 100 students × 5 classes)
11. Achievement Award (Atomic, simple, variable)
12. Attendance Award (Atomic, simple, ~50 per year)

Communication (12+ per year):
13. Newsletter Template (Narrative, complex, monthly)
14. Event Announcement (Atomic, moderate, variable)

etc.

Step 3: Workflow Analysis

Goal: Understand when documents are created and how they fit into processes

Process: 1. Map key workflows: What are the major processes? - Education: Academic year cycle (enrollment → teaching → assessment → reporting) - Legal: Matter lifecycle (intake → research → production → billing → closing) - Real Estate: Transaction cycle (listing → marketing → showing → offer → closing)

Identify document triggers: What events cause document creation?
Scheduled: End of quarter → report cards
Event-driven: New enrollment → welcome packet
On-demand: Parent requests transcript
Approval-triggered: Committee approves → certificate issued
Understand data readiness: When is data available?
Report cards can't be generated until all grades entered
Certificates can't be issued until completion verified
Invoices can't be sent until time entries approved
Identify approval workflows: Who must review/approve?
Some documents require no approval (rosters)
Some require instructor review (progress reports)
Some require administrator approval (transcripts, official documents)
Map distribution methods: How are documents delivered?
Email to parents
Print and hand-deliver
Portal upload for parent access
Official mail (transcripts to colleges)

Output: Workflow diagrams showing document generation in context

Example (Homeschool Co-op - Semester Workflow):

Week 1: Semester Begins
├── Generate class rosters (instructors need these)
├── Generate student schedules (students/parents need these)
└── Generate master directory (everyone needs contact info)

Weeks 2-15: During Semester
├── Instructors post assignments (weekly/bi-weekly)
├── Students submit work
├── Instructors grade and record
└── [Ongoing] Generate assignment sheets for each class

Week 8: Mid-semester
├── Generate progress reports (informal check-in)
└── Email to parents

Week 16: Semester End
├── All grades must be finalized (deadline)
├── Generate final report cards
├── Generate completion certificates
├── Generate attendance awards
└── Distribute all end-of-semester documents

Post-Semester:
├── Archive semester data
└── Generate transcripts (on demand)

Step 4: Regulatory and Compliance Analysis

Goal: Identify legal/regulatory requirements that shape documents

Process: 1. Research regulations: What laws apply? - Education: FERPA (student privacy), state homeschool laws - Legal: State bar ethics rules, court rules, attorney-client privilege - Healthcare: HIPAA (patient privacy), state licensing, quality reporting - Real Estate: State real estate law, disclosure requirements, MLS rules

Identify required content: What must documents include?
Educational transcripts: Specific elements required by colleges
Legal invoices: State bar may require specific disclosures
Real estate contracts: Mandatory disclosure forms by state
Understand retention requirements: How long must documents be kept?
Education: Student records often 5+ years
Legal: Case files often 7+ years
Healthcare: Medical records often 10+ years
Access control and privacy: Who can see what?
Student grades: Parents can see own child only (FERPA)
Legal documents: Attorney-client privilege
Healthcare: HIPAA restricts access
Audit requirements: What proof of compliance needed?
Who generated document?
When was it created?
What data was used?
Who accessed it?

Output: Compliance requirements matrix

Example (Homeschool Co-op - Compliance):

Legal Requirements:
├── State Homeschool Law (varies by state)
│   ├── Attendance tracking (180 days/year in some states)
│   ├── Subject coverage documentation
│   └── Assessment/testing requirements
├── FERPA (if co-op receives federal funds)
│   ├── Parent consent for photo use
│   ├── Directory information restrictions
│   └── Access controls on grades
└── Safety Requirements
    ├── Emergency contact information
    ├── Medical/allergy alerts
    └── Background checks for instructors (some states)

Document Implications:
├── Attendance records must be maintained
├── Transcripts must meet state/college requirements
├── Photo releases needed before using images
├── Secure storage for sensitive data
└── Parent access to own child's records only

Step 5: Stakeholder Analysis

Goal: Understand who creates and uses documents

Process: 1. Identify roles: Who are the key people? - Creators: Who makes documents? - Approvers: Who must review/authorize? - Recipients: Who receives documents? - Administrators: Who manages the system?

Assess technical sophistication: How tech-savvy are they?
Comfortable with Excel/Google Sheets?
Can handle database concepts?
Prefer guided workflows or direct control?
Need mobile access?
Understand pain points: What frustrates them most?
Time consuming tasks
Error-prone processes
Inconsistent formats
Difficult coordination
Identify motivations: What would make them adopt a solution?
Time savings (quantify hours/week)
Error reduction
Professional appearance
Reduced stress
Compliance confidence

Output: Stakeholder personas and use cases

Example (Homeschool Co-op - Stakeholders):

Coordinator (Primary User):
├── Role: Volunteer managing co-op operations
├── Tech Level: Moderate (Excel, email, basic Word)
├── Pain Points:
│   ├── 20+ hours/month on document creation
│   ├── Errors in manual data entry
│   ├── Inconsistent formatting
│   └── Difficult to update when data changes
├── Motivations:
│   ├── Save time for actual teaching
│   ├── Reduce stress and frustration
│   ├── Professional-looking outputs
│   └── Easy to train replacement coordinator
└── Use Cases:
    ├── Generate all documents at semester start
    ├── Create report cards at semester end
    ├── Issue certificates for completions
    └── Produce rosters when parents request

Instructors (Secondary Users):
├── Role: Teach specific classes
├── Needs:
│   ├── Class rosters with photos
│   ├── Assignment sheets to distribute
│   ├── Grade sheets to record scores
│   └── Student contact info for emergencies
└── Tech Level: Low to moderate

Parents (Recipients):
├── Role: Receive information about their children
├── Needs:
│   ├── Progress reports and report cards
│   ├── Contact information for other families
│   ├── Schedules showing what/when/where
│   └── Certificates for achievements
└── Tech Level: Varies widely

Step 6: Synthesis and Prioritization

Goal: Decide what to build first

Process: 1. Score documents by value: - Frequency × Volume = total instances per year - Time to create manually (hours per document) - Error rate/risk - Stakeholder priority (how important?)

Assess implementation complexity:
Simple (atomic pattern, no relationships)
Moderate (directory or master-detail with 2-3 tables)
Complex (multiple relationships, calculations, conditionals)
Create priority matrix: High Value + Low Complexity → Build First (Quick Wins) High Value + High Complexity → Build Second (Core Features) Low Value + Low Complexity → Build Third (Nice to Have) Low Value + High Complexity → Defer or Don't Build
Define MVP: What's the minimum useful system?
Usually: Top 5-10 highest-value documents
Must support core workflow
Should demonstrate value quickly
Can expand from there

Output: Prioritized roadmap

Example (Homeschool Co-op - Priorities):

Phase 1 (MVP - Immediate Value):
1. Student Roster by Class (high frequency, moderate complexity)
2. Master Student Directory (high value, low complexity)
3. Class Schedule by Student (high value, moderate complexity)
4. Completion Certificate (very high volume, low complexity)

Phase 2 (Core Academics):
5. Report Card (critical, high complexity)
6. Progress Report (important, high complexity)
7. Assignment Sheet (moderate value, low complexity)

Phase 3 (Extended Features):
8. Transcript (low frequency but critical when needed)
9. Achievement Awards (variable, low complexity)
10. Newsletter Template (moderate value, high complexity)

Deferred:
- Custom forms (too variable)
- Complex integrations (not yet needed)

4.3 Domain Maturity Model

Not all domains are equally ready for domain-specific automation. We can assess maturity along five levels:

Level 1: Manual Processes

Characteristics: - Users create documents from scratch each time - No templates or minimal templates (Word files passed around) - Heavy copy-paste from previous documents - Each person does it differently - No shared data structures - High error rates - Time-intensive

Tools Used: - Word processors for narrative writing - Excel for basic data tracking (but not integrated with documents) - Email for distribution - File cabinets or folders for storage

Pain Points: - Reinventing the wheel repeatedly - Inconsistent quality - Errors in data transcription - Difficult to update when data changes - No version control - Hard to train new people

Example Domains at This Level: - Small nonprofits - Individual professional practices - Volunteer-run organizations - Early-stage startups

Readiness for Domain Solutions: High potential impact but may need education on what's possible

Level 2: Template Collections

Characteristics: - Organization has collection of Word/Excel templates - Templates have placeholder text or merge fields - Mail merge for simple documents - Templates shared via email or network drive - Some standardization but still manual work - Multiple versions of templates proliferate

Tools Used: - Word with mail merge - Excel templates with formulas - Google Docs templates - Dropbox/Drive for template storage

Pain Points: - Templates drift (different versions) - Mail merge breaks with complex data - Still lots of manual work - Can't handle relationships (master-detail) - Calculations error-prone - Difficult to maintain consistency

Example Domains at This Level: - Small to mid-size schools - Small law firms - Real estate teams - Medical practices

Readiness for Domain Solutions: Ready! They understand the value of templates but are hitting limitations.

Level 3: Basic Document Automation

Characteristics: - Using document automation software - Templates more sophisticated (conditionals, loops) - Some integration with data sources - Workflow automation (scheduled generation) - Version control on templates - Still requires technical knowledge to create templates

Tools Used: - WebMerge, Formstack, PandaDoc - Practice management software with document features - Custom scripts/macros - API integrations

Pain Points: - Template creation requires expertise - Learning curve for staff - Expensive per-user pricing - Each document type is separate project - Limited domain knowledge embedded - Still manual data preparation

Example Domains at This Level: - Mid-size law firms - School districts with IT support - Real estate brokerages - Corporate HR departments

Readiness for Domain Solutions: May resist ("we already have something") but could benefit from domain-specific approach with lower learning curve.

Level 4: Domain-Specific Platforms

Characteristics: - Using purpose-built tools for their domain - Domain ontology embedded in system - Pre-built templates for common document types - Guided workflows for document creation - Relationship management automated - Community contributions and shared practices - Lower technical barriers

Tools Used: - Vertical SaaS with document features - Domain-specific document platforms - Integrated practice management systems

Capabilities: - Users select document type, system knows requirements - Data relationships handled automatically - Calculations and business rules encoded - Templates reflect domain best practices - Compliance features built-in - Community template library

Example Domains at This Level: - Some legal practice management systems (Clio, Smokeball) - Some school information systems - Some real estate platforms

Challenges: - Still requires configuration - May not fit non-standard workflows - Template customization can be limited - Vendor lock-in

Readiness for Domain Solutions: Market already exists; compete on better domain knowledge, easier UX, or different sub-domain focus.

Level 5: Intelligent Domain Systems

Characteristics: - AI-powered document generation - Natural language interfaces ("create report cards for honor roll students") - Predictive document creation (anticipates needs) - Continuous learning from usage - Adaptive templates (improve based on outcomes) - Autonomous quality checking - Multi-modal documents (text, data, visualizations, interactive)

Capabilities: - AI generates document structure from intent + data - Natural language content generation (narrative sections) - Smart defaults based on context - Anomaly detection (flags unusual patterns) - Optimization recommendations - Cross-document consistency checking

Example Domains at This Level: - Emerging (no domain fully at this level yet) - Some experimentation in: - Legal tech (AI contract analysis) - Healthcare (AI clinical documentation) - Financial services (AI reporting)

Future State: This is where we're heading. Current AI capabilities make this feasible now, but integration challenges remain.

Maturity Model Application

For System Designers: Understand where target users are: - Level 1-2: Need lots of hand-holding, guided workflows, examples - Level 3: Need to show advantages over current tools (ease of use, lower cost, better domain fit) - Level 4: Need differentiation (better domain coverage, superior UX, unique features) - Level 5: Research and development focus

For Market Analysis: - Level 1-2: Large addressable market, high impact, but education needed - Level 3: Established market, must compete on value proposition - Level 4: Mature market, differentiation critical - Level 5: Future opportunity, first-mover advantages

4.4 Cross-Domain Meta-Patterns

While domains differ, certain document patterns appear universally. These meta-patterns transcend verticals and represent fundamental organizational needs.

Meta-Pattern 1: Identity & Membership

Universal Need: Organizations need to know who belongs and how to reach them.

Core Documents: - Directories (who's in the organization) - Contact lists (how to reach them) - ID cards and badges (proof of membership) - Rosters (who's in which subgroup) - Organizational charts (relationships and hierarchy)

Appears In: - Education: Student rosters, instructor directories, parent contact lists - Legal: Attorney directories, client lists, witness lists - Real Estate: Agent rosters, client lists, vendor directories - Business: Employee directories, team rosters, supplier lists - Healthcare: Provider directories, staff rosters, patient registries - Membership Organizations: Member directories, committee rosters

Common Attributes: - Name (often with formal/preferred variants) - Photo (increasingly expected) - Contact information (email, phone, address) - Role or affiliation - Status (active, inactive, alumni)

Pattern Variants: - Simple Directory: Alphabetical list with basic info - Photo Directory: Grid of photos with names/roles - Hierarchical Directory: Organized by department/team/group - Cross-referenced Directory: Multiple groupings (alphabetical + by role + by location)

Implementation Commonalities: - Usually uses Directory pattern - Source data: single table (people/members) - Common layouts: grid, list, table - Frequent updates (people join/leave) - Privacy considerations (FERPA, GDPR)

Why Universal: Every organization with multiple people needs to maintain identity and contact information.

Meta-Pattern 2: Status & Progress Tracking

Universal Need: Organizations need to monitor and communicate progress toward goals.

Core Documents: - Progress reports (how things are going) - Status dashboards (current state at-a-glance) - Performance reviews (assessment of individuals/teams) - Analytics reports (metrics and trends) - Scorecards (performance against targets)

Appears In: - Education: Report cards, progress reports, learning assessments - Legal: Case status reports, billing summaries, matter progress - Real Estate: Sales activity reports, pipeline status, market updates - Business: Project status reports, OKR tracking, employee reviews - Healthcare: Patient progress notes, quality metrics, census reports

Common Structure: - Entity being assessed (student, project, employee, patient) - Metrics or dimensions of assessment - Current status/score - Historical comparison (change over time) - Narrative commentary (context, explanation) - Goals or targets (expected vs. actual)

Pattern Variants: - Individual Progress Report: Master-Detail (entity + metrics over time) - Aggregate Dashboard: Matrix (entities × metrics) - Trend Report: Linear narrative with charts - Scorecard: Matrix with status indicators (red/yellow/green)

Temporal Dimension: Progress implies change, so these documents inherently compare points in time.

Why Universal: Organizations exist to accomplish things; tracking progress is fundamental.

Meta-Pattern 3: Transaction & Exchange

Universal Need: Organizations need to document what was given and received.

Core Documents: - Invoices (request for payment) - Receipts (proof of payment) - Orders (commitment to purchase) - Contracts (exchange of obligations) - Statements (account history)

Appears In: - Education: Tuition invoices, activity fees, donation receipts - Legal: Legal invoices (time × rate), expense reimbursements - Real Estate: Commission statements, earnest money receipts, closing statements - Business: Sales invoices, purchase orders, payroll statements - Healthcare: Patient bills, insurance claims, EOBs (explanation of benefits)

Common Structure: - Parties: Who's giving, who's receiving - What: Goods/services exchanged - Quantity and Price: How much × cost - Total: Aggregate amount - Terms: When due, payment methods, late fees - Line Items: Detail of transaction (Master-Detail pattern)

Pattern Variant: Almost always Master-Detail - Header: Transaction metadata (date, parties, total) - Detail: Line items (what was exchanged) - Footer: Totals, terms, signatures

Legal and Compliance Aspects: - Often performative documents (create obligation) - Require precision (errors costly) - Audit trail essential - Retention requirements (IRS, SOX, etc.)

Why Universal: Economic exchange is fundamental to organizations; documentation creates accountability.

Meta-Pattern 4: Reference & Discovery

Universal Need: Organizations need to make information findable and accessible.

Core Documents: - Catalogs (what's available) - Inventories (what exists) - Indices (where to find things) - Menus (options and choices) - Guides (how to navigate/use)

Appears In: - Education: Course catalogs, curriculum guides, resource libraries - Legal: Document indices, court rules, legal research guides - Real Estate: Property listings, MLS books, area guides - Business: Product catalogs, service menus, policy handbooks - Healthcare: Formularies (medication lists), provider directories, treatment protocols

Common Structure: - Items: The things being cataloged - Descriptions: What each item is - Specifications: Attributes and details - Organization: How items are grouped/sorted - Navigation Aids: Index, table of contents, search

Pattern Variants: - Flat Catalog: Directory pattern, simple list - Hierarchical Catalog: Hierarchical pattern, nested categories - Comparison Catalog: Matrix pattern, feature comparison - Rich Catalog: Narrative flow with product showcases

Design Considerations: - Findability: Can users locate what they need? - Completeness: Are all available options shown? - Currency: Is information up-to-date? - Usability: Clear descriptions, good navigation

Why Universal: Organizations offer choices; catalogs make options discoverable.

Meta-Pattern 5: Authorization & Validation

Universal Need: Organizations need to grant permissions, certify achievements, and create proof.

Core Documents: - Certificates (achievement recognition) - Licenses (permission grants) - Authorizations (approvals) - Credentials (qualification proof) - Permits (right to proceed)

Appears In: - Education: Diplomas, certificates of completion, transcripts, awards - Legal: Bar licenses, notarizations, powers of attorney, court orders - Real Estate: Broker licenses, property deeds, certificates of occupancy - Business: Professional certifications, quality certificates, ISO compliance - Healthcare: Medical licenses, board certifications, accreditations

Common Structure: - Authority: Who is granting (organization, certifying body) - Recipient: Who is receiving (person, organization) - What: What is being granted/certified - When: Effective date, expiration (if applicable) - Signatures/Seals: Proof of authenticity - Unique Identifiers: Certificate numbers, license numbers

Pattern: Almost always Atomic - One certificate/license per individual - Formatted for official use (framing, official files) - Often includes security features (signatures, seals, watermarks)

Legal Weight: - Often performative (certificate confers status) - Fraud prevention important - Verification mechanisms needed - Long retention requirements

Why Universal: Organizations need to officially recognize achievements and grant permissions; formal documentation creates legal/social reality.

Meta-Pattern 6: Communication & Notification

Universal Need: Organizations need to inform stakeholders.

Core Documents: - Announcements (one-way information push) - Newsletters (periodic updates) - Notifications (triggered messages) - Correspondence (targeted communication) - Reports (formal information sharing)

Appears In: - Education: School newsletters, parent notifications, event announcements - Legal: Client updates, case notifications, court notices - Real Estate: Market updates, new listings, open house invitations - Business: Company newsletters, policy updates, meeting notices - Healthcare: Patient reminders, health alerts, test results

Pattern Variety: Depends on content - Simple announcements: Atomic pattern - Newsletters: Narrative flow pattern - Notification lists: Directory pattern - Comprehensive reports: Multiple patterns combined

Timing Considerations: - Scheduled: Weekly newsletters, quarterly reports - Event-triggered: Enrollment → welcome letter - On-demand: User requests information

Distribution Channels: - Email (most common) - Print/mail (official communications) - Portal/app (access-controlled) - Social media (public announcements)

Why Universal: Organizations must communicate with stakeholders; documentation creates record and ensures delivery.

4.5 Domain Analysis Framework Summary

We can now analyze any domain systematically:

Analysis Checklist

1. Domain Definition - [ ] Shared ontology identified? - [ ] Recurring document types cataloged? - [ ] Conventions and standards documented? - [ ] Common workflows mapped? - [ ] Community of practice exists?

2. Entity-Relationship Model - [ ] Core entities identified (5-15 main entities) - [ ] Attributes defined for each - [ ] Relationships mapped (1:1, 1:N, M:N) - [ ] Cardinality specified - [ ] ER diagram created

3. Document Inventory - [ ] All document types enumerated - [ ] Communicative functions categorized - [ ] Architecture patterns identified - [ ] Frequency and volume estimated - [ ] Complexity assessed - [ ] Dependencies mapped

4. Workflow Analysis - [ ] Key processes mapped - [ ] Document triggers identified - [ ] Data readiness assessed - [ ] Approval workflows understood - [ ] Distribution methods known

5. Compliance Assessment - [ ] Regulations identified - [ ] Required content specified - [ ] Retention requirements known - [ ] Access controls defined - [ ] Audit requirements understood

6. Stakeholder Analysis - [ ] Roles identified - [ ] Technical capabilities assessed - [ ] Pain points documented - [ ] Motivations understood - [ ] Use cases defined

7. Prioritization - [ ] Value scoring complete - [ ] Complexity assessment done - [ ] Priority matrix created - [ ] MVP defined - [ ] Roadmap established

Applying to New Domains

This framework enables:

For Developers: Systematic approach to building domain-specific solutions - Know what entities and relationships to model - Know what documents to support - Know what features matter most - Know what compliance to address

For Product Managers: Market assessment and opportunity analysis - Evaluate domain maturity - Estimate addressable market - Identify differentiation opportunities - Prioritize feature development

For Researchers: Comparative domain analysis - Which patterns appear in which domains? - What makes some domains more amenable to automation? - How do conventions evolve? - What transfer learning is possible?

For Domain Experts: Understanding their own needs - See their domain from outside perspective - Identify gaps in current tools - Articulate requirements clearly - Evaluate potential solutions

4.6 Domain Selection Criteria

Not all domains are equally attractive for domain-specific solutions. How to choose?

Evaluation Framework

1. Document Intensity - How many documents does domain create? - Hours per week spent on document work? - High intensity = high potential value

2. Coordination Complexity - How many people involved? - How much collaboration required? - Complex coordination = high value of automation

3. Standardization Opportunity - How similar are documents across organizations? - Do conventions exist? - High standardization = easier to build domain solution

4. Willingness to Pay - Economic value of time saved? - Cost of errors prevented? - Compliance value? - Calculate: Hours saved × hourly rate = value delivered

5. Technical Sophistication - How tech-savvy are users? - Do they already use templates or mail merge? - Too low = education burden; too high = entrenched tools

6. Market Size - How many organizations in domain? - How many users per organization? - Large market = more opportunity

7. Competitive Landscape - Existing solutions? - Level of satisfaction? - Switching costs? - Differentiation opportunities?

8. Domain Maturity - Level 1-2: Greenfield opportunity but education needed - Level 3: Replace inadequate tools - Level 4: Must differentiate clearly

Example: Why Homeschool Co-ops?

Let's apply this framework to justify Richard's choice:

Document Intensity: High ⭐⭐⭐⭐⭐ - Coordinators spend 20+ hours/month on documents - Multiple document types needed - Recurring (semester after semester)

Coordination Complexity: Moderate ⭐⭐⭐ - 50-150 families per co-op - 10-30 instructors - Parent involvement - Volunteer coordinator (not full-time staff)

Standardization Opportunity: High ⭐⭐⭐⭐ - Co-ops share similar structures - Common document types across co-ops - Some variation but clear patterns - Strong community practices

Willingness to Pay: Moderate ⭐⭐⭐ - Limited budgets (volunteer organizations) - But high pain point (frustration with current process) - $50-200/year per co-op feasible - Small but reasonable

Technical Sophistication: Moderate ⭐⭐⭐ - Excel comfortable - Mail merge attempted but frustrated - Need simple, guided tools - Not intimidated by technology

Market Size: Medium ⭐⭐⭐ - ~10,000 homeschool co-ops in US - Growing (homeschooling increased 30% 2020-2023) - Adjacent: private schools, tutoring centers - Niche but viable

Competitive Landscape: Low Competition ⭐⭐⭐⭐⭐ - Generic tools (Word, Google Docs) inadequate - School management systems too complex/expensive - No purpose-built co-op document solution - Greenfield opportunity

Domain Maturity: Level 1-2 ⭐⭐⭐⭐ - Mostly manual processes - Some use templates - Ready for better solution - Will appreciate innovation

Overall Assessment: Strong opportunity - High pain, low competition - Clear patterns to encode - Reachable market - Room for expansion (private schools, tutoring)

Strategic Advantage: - Wedge strategy: dominate co-ops, expand to adjacent - Community-driven: co-op networks spread word-of-mouth - Proof point: other education segments see value

What We've Established

This chapter provides:

Definition of Domain: What qualifies as a distinct domain for automation purposes
Analysis Methodology: Systematic 6-step process for understanding any domain
Maturity Model: 5 levels from manual processes to intelligent systems
Universal Meta-Patterns: 6 patterns that appear across all domains
Selection Criteria: How to evaluate domain opportunity

Key Insight: While domains differ in content, they share structural patterns. The framework we've built transcends any single vertical. - This becomes the template others follow for their domains