ABYSS is a SaaS platform built and hardened over more than five years to run maritime training operations end to end. It is not a narrow back-office tool and it is not a prototype. It is the working product layer behind lead capture, student lifecycle, academic operations, certifications, invoicing, communications, reporting, student self-service, and ISO/SGC quality management in one integrated system.
This repository is the public technical brief for ABYSS. Its purpose is to make the scope, architecture, operational maturity, and engineering depth reviewable without exposing the production source tree, live datasets, billing artifacts, local secrets, or deployment-sensitive material.
- Product:
ABYSS - Delivery model:
operational SaaS for maritime training centers - Maturity:
5+ years of development and production iteration - Current live reference:
STCW España - Functional breadth:
18 documented modules - User model:
internal multi-role operations + student self-service portal - Stack:
React,Vite,Express,PostgreSQL - Runtime support:
JWT auth,RBAC,workers,PM2,Nginx/VPS - Expansion track:
tenant bootstrap,lead-to-student lifecycle,persistent SGC analytics - Review model:
public technical brief + private cleaned source review on request
ABYSS concentrates the operational spine of a maritime training center in one platform:
- lead capture and conversion
- student records and lifecycle management
- course templates, course instances, and academic operations
- attendance, assistance, evaluation, and dossier flows
- certifications, verification, and document-linked controls
- invoicing and finance-related workflows
- communications, workers, and scheduled processing
- reporting, management visibility, and KPIs
- student portal and self-service processes
- ISO/SGC quality, audits, objectives, risks, and DGMM-oriented control
ABYSS already behaves as a full operational product for a live training organization. The public brief presents it as such because that is the delivered reality:
- one coherent application shell with broad RBAC-governed module coverage
- backend services, workers, and business flows running in production conditions
- public and self-service flows such as portal access and verification routes
- business-critical modules operating together instead of as disconnected tools
- documented product evolution toward broader school and country reuse without permanent forks
The right public framing is ABYSS. STCW España is the live operating reference. This brief is intentionally written around the product, its delivered capabilities, and its operational maturity.
The platform currently documents 18 modules with substantial operational coverage across commercial, academic, compliance, portal, finance, and quality domains:
- Dashboard
- Leads
- Students
- Courses
- Venue Resources
- Career Plans
- Career Packs
- Academic Management
- Technical Support
- Certifications
- Invoicing
- Communications
- Tasks
- Reports
- Users and Team
- Settings
- Student Portal
- Quality and SGC
See Module Map.
ABYSS is not a single-panel tool. It separates internal operations from student self-service and enforces access through role-aware UI and backend authorization.
Core internal roles documented in the runtime:
adminsalesinstructorcoordinatorsupportstudent
In addition, some sensitive operational and quality flows are explicitly protected for specialized roles such as compliance, direction, and guarded super-admin paths.
The runtime currently exposes three main visual surfaces:
internal operations shellfor administration, sales, academic operations, finance, support, reports, and qualitystudent portal shellfor profile, courses, quizzes, documents, certificates, invoices, messages, and supportpublic/utility viewsfor login, password reset, certificate preview/verification, and invoice verification
See Role Model and Visual Surface.
One of the strongest signals in ABYSS is that it has not only breadth of modules, but also depth of production hardening:
- resolved authentication incidents and routing regressions
- resolved quiz and timeout defects affecting real student flows
- communications workers and automation safety controls
- invoice and certification verification flows
- documented post-mortems and operational fixes instead of ad-hoc patching
- quality/SGC coverage linked to real academic and documentary operations
This matters because serious software is not defined only by how many screens it has. It is defined by how it behaves under load, failure, change, and recovery in a live operation.
See Production Hardening.
ABYSS is no longer only a broad operational runtime. It also has a verifiable platform-expansion track that is already visible in the working system and in the technical planning produced around it.
What is publicly stated here is limited to what can be defended from the runtime and current documentation:
- config-driven tenant and country bootstrap already exists through runtime resolution and tenant packs
- a second tenant pack for
JJR Solutionsis already modeled as part of the expansion path - a unified customer lifecycle timeline exists across lead, communication, enrollment, payment, and certification events
- the SGC layer already includes persistent KPI snapshots, scheduled materialization, and trend-oriented read APIs
- strategic specifications already exist for next-step domains such as
WhatsApp, external payments, customer lifecycle visibility, and documentation prioritization
Important precision:
- this brief does not claim that every part of the multi-tenant platformization path is fully generalized and closed
- the defendable claim is stronger and more honest: ABYSS already has a real expansion base, a second tenant modeled, a lifecycle review surface, and an analytics persistence layer growing on top of the live product
See Platform Expansion Status, Lifecycle Lead to Student, SGC Analytics Persistence, and the Prompt Library.
The active ABYSS runtime follows a production-oriented full-stack architecture:
React 18 + Vitefrontend written inJavaScript / JSXTailwind CSS,Radix UI,Framer Motion, and charting/UI libraries in the browser layer- client integration layer in
JavaScriptusingfetch,sendBeacon, and service-based API access under same-origin/api Node.js + Expressbackend written inJavaScript, organized by routes, services, middleware, workers, and migrationsPostgreSQLoperational database accessed from Node through thepgdriver and SQL-based schema/migration flows- background workers in
Node.js(.js/.mjs) for communications, reminders, scheduled jobs, and document-related processing - JWT-based authentication, RBAC, and route-level permission checks
Socket.IOreal-time layer over/ws, backed by PostgreSQLLISTEN / NOTIFYfor event propagation- VPS-oriented backend operations with
Nginx,PM2, separate app delivery, and production smoke/deploy tooling
High-level runtime view:
flowchart TD
A["Users"] --> B["Browser"]
B --> C["React 18 + Vite SPA<br/>JavaScript / JSX"]
C --> D["UI Layer<br/>Tailwind CSS + Radix UI + Framer Motion"]
C --> E["Client Services<br/>fetch + sendBeacon + same-origin /api"]
E -->|HTTPS + JSON + JWT / cookies| F["Node.js + Express API<br/>JavaScript"]
F --> G["Middleware Layer<br/>Auth + RBAC + route guards"]
G --> H["Business Services<br/>students, courses, billing, certifications, SGC"]
H -->|SQL via pg| I["PostgreSQL"]
H --> J["Node.js Workers<br/>communications, reminders, scheduled jobs"]
I -->|LISTEN / NOTIFY| K["Socket.IO /ws Real-time Layer"]
K -->|WebSocket + JWT| C
F --> L["Nginx + PM2 + VPS Delivery"]
See Architecture.
The production working tree is too sensitive to publish directly. It mixes software layers with material that should not be made public, such as:
- local environment files and secrets
- billing artifacts and generated documents
- database files, dumps, and operational exports
- deployment-sensitive configuration and runbooks
- raw incident material with operational detail
For a serious evaluation, the correct model is:
- public technical brief for orientation
- private cleaned source repository for controlled review
See Publication Boundary.
If you are reviewing ABYSS:
- Read this README as the system brief.
- Review Architecture.
- Review Module Map.
- Review Platform Expansion Status.
- Review Lifecycle Lead to Student.
- Review SGC Analytics Persistence.
- Review the Prompt Library.
- Review Role Model.
- Review Visual Surface.
- Review Production Hardening.
- Review Publication Boundary.
If deeper technical review is required, the next step is controlled access to the private cleaned repository rather than broader public publication of the production tree.
Contact:
- GitHub: Robertgaraban
- LinkedIn: linkedin.com/in/robertgaraban
Repositorio privado: Robertgaraban/abyss-stcw-private — acceso como colaborador bajo solicitud
Solicitar acceso: robertgaraban@gmail.com — Asunto: [Acceso repo privado] abyss-stcw-private
- This repository is a technical brief and due-diligence layer for ABYSS.
- It is not an open-source release of the production implementation.
- See Architecture, Module Map, Platform Expansion Status, Lifecycle Lead to Student, SGC Analytics Persistence, the Prompt Library, Role Model, Visual Surface, Production Hardening, Publication Boundary, and Closeout.