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.

Formal product principles exist because teams face thousands of micro-decisions during a project’s lifetime — many of them under pressure, with incomplete information, or competing priorities. Without an explicit, agreed-upon set of principles, those decisions drift toward technical convenience, short-term speed, or the preferences of whoever is in the room that day. The SSA Health Platform’s eight principles were discovered and ratified during the product discovery phase through structured interviews with the institutional stakeholders. They are not aspirational guidelines — they are operational constraints. When a technical proposal conflicts with a principle, the principle wins. When a content decision conflicts with a principle, the principle wins. The only legitimate path to overriding a principle is a formal architectural decision with documented justification reviewed at the highest level of the project.
These principles are permanent and may not be overridden by technical convenience, timeline pressure, budget constraints, or individual preference. Any proposal that conflicts with one of these principles requires a formal architectural decision record before it can be considered.

​
The Eight Principles

Accuracy is non-negotiable.Every piece of content published through the platform must originate from or be validated against an authoritative source: the Jurisdicción Sanitaria itself, the Secretaría de Salud de Hidalgo, the OMS, the OPS, or official government programs. The platform exists precisely because misinformation spreads easily through informal channels. Publishing unreliable information would betray the institution’s public health responsibility and undermine the platform’s long-term credibility.Implications for the system:
  • Content workflow must include review and approval steps before publication.
  • The audit log must record who created, reviewed, and published every content item.
  • The AI chatbot must only answer using content retrieved from the platform’s own verified knowledge base — it must never fabricate or extrapolate beyond what the platform has officially published.
  • Source attribution must be a structured field in all content types, not optional metadata.
Write for the general population, not for health professionals.The primary audience of this platform is the general public — people who seek health information without formal medical training. Content must be written in plain, accessible Spanish. Technical terminology must be defined or replaced with common language wherever possible. Passive constructions, bureaucratic phrasing, and institutional jargon are prohibited in public-facing content.Implications for the system:
  • The CMS editorial interface should surface readability guidance for content authors.
  • Disease guides must include a plain-language summary in addition to any technical detail.
  • FAQ content must be written as genuine questions a regular person would ask — not as a way of presenting institutional talking points in question form.
Prefer plain language and visual structure over density.Clarity of language is necessary but not sufficient. Content must also be structured so that it can be understood quickly — with headings, short paragraphs, bullet points, and visual hierarchy. A population member seeking guidance during a health emergency does not have time to read a five-page document. Information must be surfaced at the right level of detail for the context in which it will be consumed.Implications for the system:
  • Content types must have structured fields (not a single free-text blob) that enforce editorial discipline.
  • Disease guides must have a consistent structure: what it is, how it spreads, symptoms, prevention, what to do.
  • The search interface must surface the most relevant answer at the top of results, not a list of documents.
Infographics, images, and video aid comprehension — they are not decoration.Visual content communicates health information faster and more memorably than text alone, particularly for audiences with limited reading time or lower literacy. The platform must treat multimedia not as supplementary material but as a primary communication format. Every content type should support visual resources. The multimedia library must be a first-class module, not an afterthought.Implications for the system:
  • Infographics are a dedicated content type — not a file attached to a news article.
  • The media library must support images, video, PDF, and audio as equal asset classes.
  • Campaign content must be designed assuming that infographics and visual elements are the primary format, with text as supporting material.
  • Social media publishing must support image and video attachments natively.
The architecture must evolve without changing its purpose.The channels through which people consume information change continuously. Today it is Facebook and WhatsApp. Tomorrow it may be platforms that do not yet exist. The platform’s architecture must be designed so that new distribution channels can be added without rebuilding the content management core. The CMS is the permanent foundation; the channels are pluggable adapters.Implications for the system:
  • Social media integration must be implemented as an adapter layer — not as hard-coded platform-specific logic embedded in the content model.
  • Adding a new distribution channel in the future must not require changes to the domain model or content types.
  • The chatbot interface is itself a channel — the RAG layer retrieves from the same content store that feeds the web and social outputs.
  • API design must treat all output channels as consumers of the same content API, never as special cases.
Every technical decision must serve the mission.The platform is not a showcase for emerging technology, a portfolio project, or an opportunity to experiment with the latest framework. It is a public health communication infrastructure. Technical choices — languages, frameworks, databases, AI services — are made because they serve the mission of publishing reliable health information reliably, at scale, over a ten-year horizon. Complexity introduced for its own sake is a liability, not an asset.Implications for the system:
  • No technology is added to the stack without a justification tied to a product or operational requirement.
  • The architecture must favour maintainability and long-term operability over novelty.
  • Microservices, event sourcing, CQRS, and other advanced patterns are not adopted unless the domain explicitly requires them — they are not architectural virtues in themselves.
  • The chosen stack (NestJS, React, PostgreSQL, Prisma) was selected for institutional reliability and developer availability, not trendiness.
Preventive content takes precedence over reactive content.The platform’s long-term value to the population is not in reporting on health crises after they have occurred — it is in providing the information that prevents those crises from affecting individuals in the first place. Vaccination guides, disease prevention protocols, seasonal health alerts, and wellness campaigns are the platform’s highest-priority content. Reactive news and emergency communications are important, but they are not the platform’s defining purpose.Implications for the system:
  • The homepage and default navigation must surface preventive content prominently.
  • Search ranking must favour preventive and educational content over time-sensitive news when both are relevant to a query.
  • Campaign planning tools must support long-running preventive campaigns, not only short-term reactive notices.
  • The AI chatbot must prioritise preventive guidance when answering health questions.
Reach people through the channels they actually use.Accessibility here means more than technical compliance with WCAG standards — though that is required. It means that the platform’s content reaches people where they already are: on social media, in search engine results, through a chatbot conversation, or via a link shared in a messaging application. Publishing on a portal that the population must actively discover is insufficient. The platform must push its content outward through all relevant channels.Implications for the system:
  • SEO is a core system requirement, not a post-launch optimisation.
  • Social media publishing is built into the CMS workflow — not a manual, parallel process.
  • The AI chatbot is a first-class access channel for people who prefer conversational queries to browsing.
  • All public-facing interfaces must be mobile-responsive — a significant portion of the population accesses information exclusively through smartphones.

​
Principles Mapped to Architectural Decisions

The eight product principles are not abstract values — they have direct architectural consequences. The table below shows how each principle shapes specific design decisions in the system.
PrincipleArchitectural Consequence
Information must be reliableDocumentation-as-source-of-truth (DA-002). Content workflow with mandatory review stages. Full audit log. Chatbot restricted to RAG over verified content only.
Language must be clearPlain-language requirements enforced at the content type schema level. Editorial guidance surfaced within the CMS interface.
Content must be easy to understandStructured content types with defined fields — not unstructured rich-text blobs. Search returns direct answers, not document lists.
Use visual resources intensivelyMultimedia library is a first-class module (DA-003). Infographics are a dedicated content type. Social publishing supports media attachments natively.
Adapt to new communication channelsAdapter pattern for all social media integrations. Output channels are consumers of a unified content API — never special-cased in the domain.
Technology is a meansTechnology decisions require mission justification (DA-004). No microservices in v1. Stack selected for long-term maintainability.
Prevention has prioritySearch ranking and homepage layout governed by content type priority rules. Campaign module supports long-running preventive programs.
Knowledge must be accessibleSEO as core requirement. Social publishing in CMS workflow. Chatbot as primary access channel. All UI responsive by default.

Build docs developers (and LLMs) love

Get started for freeTalk to us