How It Works
Uniph.ai Documentation Wiki
Last updated: February 2026
This is the living docs hub for Uniph.ai. It tracks the current codebase and is the source of truth for architecture, API behavior, product status, and roadmap direction.
Deployed URLs
- Frontend:
https://uniph.ai - Backend API:
https://api.uniph.ai
What Uniph.ai is
Uniph.ai is an AI life orchestrator with three connected layers:
- LifeOS: users, goals, tasks, integrations, and inference-assisted planning.
- Orchestration fabric: internal execution context where agents coordinate and exchange structured signals behind the scenes.
- Governed execution: contracts, policy evaluation, execution queues, evaluation checkpoints, and persistent memory.
The system is API-first and event-driven, supporting both built-in agents and external agents through a stable contribution envelope and adapter contract.
System Overview
Frontend (Next.js) |- Landing, dashboard, goals, docs, settings |- Mission Control (evaluation and reliability surfaces) v Backend (Express + Prisma) |- LifeOS routes: users, goals, tasks, integrations, infer, schedule, github |- Internal collaboration routes: workspaces, contributions, agents, runs |- Governance routes: contracts, governance, execution, evaluation, memory, orchestrate |- Channels: Slack, Discord, Email v PostgreSQL
Core Product Areas
1) LifeOS
- User profile + preferences (
users) - Goals + categories (
goals,goal_categories) - Tasks with statuses/priority/source (
tasks) - Integrations with encrypted config (
integrations) - Inference endpoints for goal suggestions + chat (
infer) - Calendar context and scheduler triggers (
schedule) - GitHub repo/task synchronization (
github)
2) Internal Agent Collaboration
- Internal workspaces with goal context (
workspaces) - Structured contributions and references (
contributions) - Event stream for reactive automation (
events) - Runs and outcomes (
runs) - Agent registration + API keys + execution permissions (
agents,workspace_agents) - Agent identity lifecycle + audit trail (
agent_identities,agent_identity_audits)
3) Governance + Execution + Memory
- Contract schema/version/validation/composition (
contracts) - Policy evaluation and approval flows (
governance) - Action job queue + retry + execution trace (
execution) - SLO/friction/harness checkpoints (
evaluation) - Long-term memory store/recall/maintenance (
memory) - Friction-first one-click orchestration start (
orchestrate)
4) Channel Interfaces
- Slack events + replies (
/api/slack/events) - Discord interactions + slash commands (
/api/discord/interactions) - Email inbound-to-task + digest (
/api/email/inbound,/api/email/digest)
Repo Guide
| Path | Purpose |
|---|---|
| backend/src/app.ts | App wiring, middleware, route mounts |
| backend/src/routes/ | API route domains |
| backend/src/channels/ | Slack/Discord/Email adapters |
| backend/src/agents/ | Built-in agents and runner behavior |
| backend/prisma/schema.prisma | Canonical data model |
| frontend/src/app/ | App routes and docs UI |
| frontend/src/lib/api.ts | Frontend API client + shared types |
| docs/ | Source-of-truth markdown docs |
| frontend/public/docs/ | Mirrored docs rendered at /docs/* |
Start Here
- Quickstart - local setup and smoke flow
- API Reference - current backend routes
- Feature Catalog - complete inventory of frontend, backend, and automation capabilities
- Status - implemented capability snapshot
- Roadmap - near-term and next-phase plan
- Adapter Spec - external agent integration contract
- Strategy - positioning and product philosophy
- Docs Maintenance - how to keep this wiki current
Documentation Contract (Living Wiki Rules)
Any PR that changes one of these must update docs in the same PR:
- Prisma schema or model behavior
- API routes or request/response contracts
- Agent behavior, identity flow, or event types
- Frontend routes or user flows
- Environment variables or deployment behavior
Required updates:
- Update source docs in
docs/ - Mirror changed files to
frontend/public/docs/ - Register new docs in
frontend/src/app/docs/config.ts(if added) - Validate docs render in-app at
/docs
For the step-by-step checklist, use DOCS_MAINTENANCE.md.