Documentation Index
Fetch the complete documentation index at: https://cernio.gadulabs.com/llms.txt
Use this file to discover all available pages before exploring further.
System Architecture Overview
Cernio is designed as a multi-tenant SaaS platform with a web-first interface and a mobile companion application.
The architecture is composed of five major layers:
Client Layer
↓
Application Layer
↓
AI Orchestration Layer
↓
Data Layer
↓
External Data Sources
Each layer has clearly separated responsibilities.
Client Layer
The client layer contains the interfaces used by the exporter.
Web Application
Primary working environment.
Main responsibilities:
- buyer discovery
- company research
- decision maker discovery
- lead workspace
- follow-up management
Technology:
Mobile Companion App
The mobile app focuses on field workflows.
Main responsibilities:
- business card scanning
- meeting notes
- quick lead creation
- follow-up reminders
Technology:
The mobile app is not intended to replicate the full web interface.
Instead, it acts as a field capture tool.
Application Layer
The application layer orchestrates platform logic.
Main responsibilities:
- Authentication
- Organization management
- Search orchestration
- Lead management
- Credit accounting
- AI pipeline triggering
Typical request flow:
User request
↓
API Gateway
↓
Application Service
↓
AI Pipeline
↓
Database
↓
Response
API Layer
The API layer exposes platform capabilities.
Example endpoints:
| endpoint | description |
|---|
| POST /search | buyer discovery |
| GET /companies/{id} | company details |
| GET /contacts/{company} | decision makers |
| POST /leads | save lead |
| PATCH /lead/{id} | update status |
AI Orchestration Layer
The AI orchestration layer coordinates different AI tasks.
Responsibilities:
- model routing
- prompt management
- pipeline execution
- provider fallback
- cost optimization
This layer prevents direct calls from the frontend to LLM providers.
AI Provider Strategy
Different AI tasks require different models.
Example routing strategy:
| task | model |
|---|
| query expansion | Gemini |
| company analysis | Claude |
| contact extraction | GPT |
| web reasoning | Perplexity |
This approach optimizes:
- cost
- latency
- reasoning quality
AI Routing Logic
The routing logic determines which model should execute each task.
Example logic:
if task == query_expansion:
use Gemini
if task == company_analysis:
use Claude
if task == contact_extraction:
use GPT
Fallback logic:
if provider fails:
switch to backup provider
Retrieval Service
The retrieval service performs company discovery.
Responsibilities:
- execute search queries
- collect candidate companies
- aggregate results
- remove duplicates
Retrieval sources include:
- search engines
- trade directories
- company websites
- LinkedIn company pages
Enrichment Service
The enrichment service analyzes company data.
Responsibilities:
- industry classification
- distributor identification
- sector relevance
- company size estimation
This step transforms raw companies into structured company profiles.
Scoring Service
The scoring service evaluates companies using deterministic scoring.
Inputs:
- industry match
- distributor probability
- country match
- company size
Outputs:
- FitScore
- priority ranking
Lead Management Service
The lead management service powers the CRM workflow.
Responsibilities:
- lead creation
- status tracking
- note storage
- follow-up reminders
- interaction history
Data Layer
The data layer stores structured platform data.
Technology:
Key features:
- row level security
- multi-tenant isolation
- relational data model
Multi-Tenant SaaS Model
The system supports multiple organizations.
Core entities:
- organizations
- users
- organization_users
- subscriptions
- credit_wallets
This structure allows:
- team accounts
- billing per organization
- shared lead workspace
Database Entity Model
The database includes the following primary entities.
- organizations
- users
- companies
- contacts
- leads
- interactions
- search_history
Entity Relationships
Core relationships:
Organization
└ Users
└ Leads
└ Searches
Company
└ Contacts
Lead
└ Company
└ Contact
└ Interactions
Lead Entity
The lead table stores discovered opportunities.
Example structure:
| field | description |
|---|
| id | lead id |
| company_id | linked company |
| contact_id | linked contact |
| status | pipeline stage |
| notes | user notes |
| follow_up_date | reminder |
Contacts represent decision makers.
Fields include:
| field | description |
|---|
| name | person name |
| title | job title |
| email | contact email |
| linkedin | LinkedIn profile |
| confidence | discovery confidence |
Search History Entity
Searches must be stored for analytics.
Example fields:
| field | description |
|---|
| product | searched product |
| country | target market |
| queries_generated | search queries |
| companies_found | results |
Caching Strategy
AI discovery is expensive.
Caching helps reduce cost.
Example cache key:
Cache policy:
cache result for 30 days
Users can trigger:
search again
to force a new run.
Credit Economy
AI processing consumes credits.
Example credit costs:
| action | credits |
|---|
| buyer discovery | 1 |
| contact reveal | 1 |
| deep company analysis | 2 |
Credits ensure cost control.
Observability
The platform must track performance metrics.
Monitoring includes:
- pipeline latency
- search success rate
- ranking accuracy
- credit usage
- system errors
This ensures continuous improvement.
Security Model
Security features include:
- row level security
- API authentication
- organization data isolation
- secure AI provider keys
Supabase RLS ensures tenants cannot access each other’s data.
Infrastructure Strategy
Initial infrastructure is lightweight.
Example stack:
- Next.js (frontend)
- Supabase (backend)
- Edge functions
- AI provider APIs
Later scaling may introduce:
- worker queues
- vector databases
- analytics warehouse
Architecture Summary
The system combines:
- AI discovery
- buyer engagement workflow
- lead memory
- data intelligence
into a unified SaaS platform.