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


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:

  1. Update source docs in docs/
  2. Mirror changed files to frontend/public/docs/
  3. Register new docs in frontend/src/app/docs/config.ts (if added)
  4. Validate docs render in-app at /docs

For the step-by-step checklist, use DOCS_MAINTENANCE.md.