Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/LMendoza70/SSA/llms.txt

Use this file to discover all available pages before exploring further.

In software that is meant to last, the domain model is not a byproduct of the database schema or the API design — it is their origin. The SSA Health Platform follows a domain-first discipline: before a single table is defined in Prisma, before a single endpoint is declared in NestJS, the domain must be fully understood and modeled. This page describes the core abstractions that govern the entire platform: the Content concept that unifies all publishable knowledge, the Ubiquitous Language that keeps the codebase aligned with the real world, and the documentation roadmap that ensures every downstream technical decision can be traced back to a deliberate domain choice.

​
The Content Abstraction

The entire domain of the Jurisdicción Sanitaria revolves around one central act: publishing reliable information. Every major feature of the platform — the CMS, the social publishing pipeline, the chatbot — exists to serve that act. The architectural consequence of this clarity is that the domain has one primary abstraction: Content. All publishable entities are instances of Content. They are not eleven separate, unrelated models that happen to share a few fields. They are specializations of a single concept, unified by shared behavior (publishing lifecycle, SEO metadata, soft deletion, multimedia association) and differentiated only by the specifics of their content type. 
                    Content (base)
                         │
     ┌──────────┬─────────┼─────────┬──────────┐
     │          │         │         │          │
   News    Campaign   Disease   Event    Document
     │          │         │         │          │
Infographic   FAQ     Program  Announcement   ...
This hierarchy prevents model fragmentation. A query that retrieves “all published content created this month” does not need to join eleven tables — it queries the Content base. A publishing pipeline that marks content as PUBLISHED does not need eleven separate code paths. A chatbot indexing job that embeds all knowledge into pgvector does not need to know whether a piece of content is a disease record or a campaign announcement.
Specialized content types extend the base with fields unique to their domain: a Disease record may carry an ICD-10 code; a Campaign may carry a target demographic and a date range. These specializations are additive. They do not break the uniformity of the base.

​
Content Base Attributes

All content entities share the following fields. These are not optional — they are structural invariants of the domain: 
id            UUID          Primary key, generated by the database
createdAt     Timestamp     Set once on creation, never modified
updatedAt     Timestamp     Updated automatically on every write
deletedAt     Timestamp     Null until soft-deleted; presence signals logical deletion
createdBy     User ref      The user who created this content record
updatedBy     User ref      The user who last modified this content record
title         string        Human-readable title, required
slug          string        URL-friendly identifier, unique across content type, auto-generated from title
body          Tiptap JSON   Rich text body — stored as JSON, rendered client-side
status        enum          DRAFT | PUBLISHED | ARCHIVED
publishedAt   Timestamp     Null until first publication; set on first PUBLISHED transition
seoTitle      string        Override title for search engines; defaults to title if empty
seoDesc       string        Meta description for search engine result pages
tags          string[]      Flat list of classification tags; used for filtering and chatbot context
media         ref[]         Ordered list of MediaAsset references associated with this content
deletedAt is the soft delete mechanism. A content item is never physically removed from the database. Queries must always filter WHERE deletedAt IS NULL unless explicitly auditing deleted records. Prisma middleware enforces this automatically.

​
Ubiquitous Language

The Ubiquitous Language is the shared vocabulary agreed upon between the domain experts (the health jurisdiction staff) and the development team. It is used consistently in: database column names, TypeScript type names, API endpoint names, UI labels, documentation, and all verbal and written communication about the system. Deviating from this vocabulary — calling a MediaAsset a “file” in code, or a Channel a “destination” in a meeting — introduces translation overhead and eventual confusion. The terms below are canonical.
TermDefinition
ContentAny publishable unit of institutional knowledge produced by the Jurisdicción Sanitaria
PublishingThe act of making a Content item available on one or more Channels
ChannelA distribution medium through which Content reaches its audience (web portal, social network, chatbot)
MediaAssetA reusable binary file (image, video, PDF, audio) managed by the Multimedia module
Timeline EventA dated historical fact about the Jurisdicción Sanitaria, with full administrative metadata
RAGRetrieval Augmented Generation — the chatbot’s knowledge strategy: retrieve relevant content, then generate a grounded response
EmbeddingA vector representation of text, stored in pgvector, used for semantic similarity search in the chatbot
SocialPublisherThe interface that all social network adapters implement; the contract for posting Content to an external platform
StorageProviderThe interface for reading and writing binary files; abstracts the underlying storage backend (local, S3, Azure Blob, GCS)
Soft DeleteLogical deletion via the deletedAt field; the record is preserved in the database and excluded from normal queries
SlugA URL-friendly, human-readable string identifier derived from the content title; unique per content type
StatusThe lifecycle state of a Content item: DRAFT, PUBLISHED, or ARCHIVED
Audit LogThe append-only record of all write operations on the platform; maintained by the Admin module
When writing code, tests, API documentation, or UI copy — use these terms exactly as listed. If a new term needs to be introduced, it must be added to this glossary first and agreed upon before appearing in any artifact.

​
Domain Phases (Roadmap)

The documentation and development roadmap is organized into ten sequential phases. Each phase is a quality gate: the next phase does not begin until the current one is complete and reviewed. This sequencing is deliberate — it ensures that every implementation decision can be traced back to a documented domain or architectural choice.
1

Phase 1 — Foundation ✅

Project Charter and Architecture Guide. The non-negotiable constraints, technology decisions, and development philosophy of the platform. These documents do not change without a formal justification.
2

Phase 2 — Product ✅

Vision, Scope, Product Principles, and Personas. What the platform is for, who uses it, and what it will and will not do. The boundaries of the product are set here.
3

Phase 3 — Domain ⏳ In Progress

Ubiquitous Language, Domain Model, Business Rules, and Use Cases. The real-world concepts and rules that govern the platform. This page is part of this phase.
4

Phase 4 — Architecture

Architecture overview, module structure, and Architecture Decision Records (ADRs). The structural blueprint derived from the domain model.
5

Phase 5 — Database

Entity Relationship Diagram, database design documentation, and the Prisma schema. The persistence layer derived from the domain and architecture.
6

Phase 6 — API

API documentation and authentication specification. The contract between backend and frontend, derived from the use cases.
7

Phase 7 — Frontend

React component architecture, routing, state management, and UI conventions. Derived from the API and user personas.
8

Phase 8 — Backend

NestJS module implementation guide, service patterns, and backend conventions. Implementation of the architecture specification.
9

Phase 9 — AI

Chatbot design, RAG pipeline documentation, and embedding strategy. The AI layer built on top of the completed CMS.
10

Phase 10 — DevOps

Deployment configuration, CI/CD pipeline, environment strategy, and infrastructure documentation.
No code is written until the Domain (Phase 3) and Architecture (Phase 4) phases are complete. This is an intentional quality gate. Building on an incomplete domain model produces systems that are correct for the wrong problem — expensive to fix and painful to maintain. The upfront investment in domain clarity pays compound returns over the ten-year lifespan of the platform.

Architecture Overview

Understand how Clean Architecture, SOLID, and DDD Lite work together to enforce the domain model at every layer.

Modules

See how the domain concepts map to the seven modules and how each module’s boundaries are defined and enforced.

CMS Content Types

Detailed reference for all eleven content types that extend the Content base abstraction.

Chatbot & RAG

How the domain’s Content abstraction powers the semantic search and RAG pipeline of the AI assistant.

Build docs developers (and LLMs) love

Get started for freeTalk to us