ABE TechLab Operations is the internal operations platform that connects ABE TechLab's lead intelligence, customer relationship management (CRM), research, outreach, content operations, analytics, integrations, and the ARIA intelligence layer.
SIGNALS + DATA
↓
OPERATIONS PLATFORM
↓
ARIA INTELLIGENCE
↓
HUMAN REVIEW / APPROVAL
↓
CONTROLLED EXTERNAL ACTION
↓
RESULTS RETURN TO OPERATIONS
The principle is simple:
AI proposes → ABE TechLab reviews → approved actions execute → results return.
ARIA is the intelligence layer — not the whole platform. High-impact external actions remain approval-gated until the relevant automation is proven reliable.
|
Organisations, contacts, leads, opportunities, activities, lead lifecycle, and operational dashboards. Organisation and market intelligence that feeds qualification, scoring, recommendations, and next actions. Human-reviewed communication plans, drafts, follow-ups, and approval-aware execution. |
Internal intelligence for research, classification, scoring, recommendations, drafting, monitoring, and governed action proposals. Operational content workflows plus surfaces for what needs attention, follow-up, or review. Website intake, email and future channels, analytics, GitHub, AI providers, and other operational services. |
flowchart LR
S[Signals & data] --> O[Operations platform]
O --> A[ARIA]
A --> R[Research]
A --> Q[Qualification & scoring]
A --> D[Drafts & recommendations]
A --> P[Action proposals]
R --> H[ABE TechLab review]
Q --> H
D --> H
P --> H
H -->|Approved| X[Controlled action]
H -->|Rejected / revised| A
X --> E[External system]
E --> F[Result / feedback]
F --> O
This keeps intelligence useful without silently turning model output into business action.
ARIA sits behind a shared AI gateway and provider router rather than being hard-wired to a single model provider.
flowchart TD
ARIA[ARIA / Client Assistant] --> G[AI Gateway]
G --> R[Provider Router]
R --> N[NVIDIA NIM]
R --> GM[Gemini]
R --> GX[Grok]
R --> OR[OpenRouter]
R --> C[Cerebras]
R --> AG[AgentRouter]
R --> OA[OpenAI fallback]
G --> POL[Runtime policy]
R --> H[Provider health + failover]
R --> U[Usage recording]
The gateway separates agent behavior from model transport. Provider configuration, failover, model selection, usage recording, and provider health remain replaceable behind the routing layer.
| Mode | Behaviour |
|---|---|
off |
Model execution disabled for the selected surface |
advisory |
Read-only intelligence, analysis, and recommendations |
action |
Reserved for governed write-capable tools and approval-routed actions |
Internal ARIA and the customer-facing Client Assistant can be paused independently.
graph TD
U[Authorised user] --> N[Next.js Operations app]
N --> AUTH[Supabase Auth / session boundary]
N --> DB[(Supabase PostgreSQL)]
N --> API[Server APIs]
N --> ARIA[ARIA workspace]
ARIA --> GW[AI Gateway]
GW --> PR[Provider Router]
PR --> MODELS[Model providers]
API --> APPROVAL[Approval queue]
ARIA --> APPROVAL
APPROVAL --> ACTION[Governed actions]
WEB[Public website / external signals] --> API
ACTION --> EXT[External systems]
EXT --> API
V[Vercel] --> N
| Layer | Technology | Role |
|---|---|---|
| Application | Next.js 15 | Routing, UI, server APIs, application runtime |
| UI | React 19 | Operations workspace and interactive surfaces |
| Language | TypeScript 5 | Type-safe application code |
| Data & auth | Supabase | PostgreSQL, authentication, server/client data access |
| AI | ARIA + shared gateway | Internal intelligence and governed AI runtime |
| Hosting | Vercel | Production deployment, runtime, scheduled heartbeat |
| Quality | ESLint + TypeScript + Vitest | Linting, type-checking, and automated tests |
The first milestone is deliberately focused: build the smallest useful internal operating system before introducing autonomous execution.
DASHBOARD
├── what is new?
├── what needs attention?
├── which opportunities matter most?
├── what is ARIA recommending?
└── what happened recently?
CRM
├── organisations
├── contacts
├── leads
├── opportunities
└── activities
Lead movement follows a defined lifecycle:
New → Researching → Qualified → Outreach Ready → Contacted
→ Engaged → Opportunity → Won / Lost / Nurture
AI-generated scores are expected to retain the evidence and reasoning behind the score rather than becoming unexplained numbers.
The application includes a lightweight health endpoint that performs a read against the isolated system_heartbeat table. It is infrastructure activity, not business-record creation.
GET /api/health/supabase
A Vercel Cron configuration keeps the heartbeat available for scheduled infrastructure checks.
Install dependencies and start the application:
npm install
npm run devQuality checks:
npm run lint
npm run typecheck
npm test
npm run buildProduction deployment is managed through Vercel from main. Build and type-check failures should be resolved before production changes are considered live.
| Document | Purpose |
|---|---|
docs/ARCHITECTURE.md |
Core system architecture |
docs/OPERATIONS-CORE-V0.1.md |
v0.1 product scope and success criteria |
docs/AI_ARCHITECTURE.md |
AI gateway, provider router, ARIA boundaries |
docs/AI_RUNTIME.md |
AI runtime behaviour and policy |
docs/AI_PROVIDER_SETUP.md |
Provider configuration guidance |
docs/DATABASE-SCHEMA-V0.1.md |
v0.1 database model |
| Release | Focus |
|---|---|
| Operations Core v0.1 | Auth, dashboard, CRM, lead pipeline, activity log, public lead intake, initial ARIA workspace |
| ARIA v0.2 | Research, qualification, scoring, recommendations, outreach planning |
| Automation v0.3 | Content, social publishing, email workflows, scheduled jobs, analytics |
Roadmap items describe direction, not a claim that every item is production-complete today.
ABE TechLab Operations is a private operational system in active development even though the repository may be publicly viewable.
Security expectations include authenticated access, role-aware permissions, server-side secrets, auditability for material changes, separation of AI output from verified business facts, and approval gates around high-impact actions.
Never commit production credentials, provider API keys, Supabase privileged credentials, webhook secrets, or other private operational values. Deployment secrets belong in Vercel environment variables or an approved secrets manager.
This repository is proprietary software. Public GitHub access does not grant permission to reuse, redistribute, commercialise, or create derivative commercial systems from the code. See LICENSE for the governing terms.