NAI Onto — the one you can model as code

nai-onto (github.com/udopnink/nai-onto) is a second, separate web application. Each ontology has a model layer (classes in a single-inheritance hierarchy plus mixins, directed relations, stored and derived properties, classification dimensions, tags), an instance layer (nodes of a class linked along the relations the model declares), and an evaluation layer (path and query expressions over the instance graph, JavaScript library functions executed in a QuickJS sandbox, and validation rules built on them). The interface and every entity name and description are localized in English and German. “The same model can be worked three ways: in the web app, as code through the nai CLI and the .nai DSL, and remotely by MCP agents through /api/mcp.”

Where it stands

Access & collaboration

Ontology management

Modeling

Instances

Views

Ontology as code

Remote modeling and agents

The app exposes one agent-facing surface: POST /api/mcp, “a stateless streamable-HTTP MCP endpoint authenticated with a personal access token (Authorization: Bearer nai_…, created at /tokens).” The token's scope decides which tools tools/list offers. The nai CLI is the second client of the same contract: “the CLI speaks the /api/mcp tools/call contract directly (src/cli/remote.ts), configured by NAI_REMOTE_URL + NAI_TOKEN env vars only — no credentials in files.”

The design that produced this lane rejected the obvious shortcut by name: handing Supabase service-role credentials to an agent sandbox “grants RLS-bypassing power to every session; rejected as anything but a consciously accepted stopgap.” The network policy follows from that — “Agent environments must allowlist the app host; nothing else (no Supabase host, no DB port) — that is the point.” On a managed-as-code ontology, remote apply requires an ontology admin; import_merge stays refused there entirely.

Transfer

Evaluation & scripting

Everywhere

How it's built

%%{init: {'theme':'neutral', 'flowchart':{'htmlLabels':false,'nodeSpacing':45,'rankSpacing':55}}}%%
flowchart TD
    W["Web app<br/>signed-in Supabase session"] --> SA
    C["nai CLI (remote mode)<br/>NAI_REMOTE_URL + NAI_TOKEN"] --> MCP
    A["MCP agent<br/>bearer token nai_..."] --> MCP

    subgraph L1 ["deployed app on Vercel"]
        SA["Server actions<br/>the web write path"]
        MCP["POST /api/mcp<br/>stateless streamable HTTP<br/>scope decides the tool list"]
        OPS["One server-side contract<br/>same operations, permission checks,<br/>payload caps, refusal reasons"]
        RB["rbac.ts matrix<br/>admin / editor / reader"]
    end

    SA --> OPS
    MCP --> OPS
    OPS --> RB
    RB --> RLS

    subgraph L2 ["Supabase Postgres"]
        RLS["Row Level Security<br/>coarse membership wall<br/>non-member reads as not found"]
        DB[("20 migrations<br/>0001_core to 0020_ontology_header_fields")]
    end

    RLS --> DB

    classDef orch fill:#dcefe9,stroke:#0f6f63,stroke-width:2px
    classDef tool fill:#f4f1ea,stroke:#8a7a5a
    classDef human fill:#fdf3e0,stroke:#8a5a00,stroke-width:2px
    class W,C,A human
    class SA,MCP orch
    class OPS,RB,RLS,DB tool

Structurally it is still the same shape as nai-analysis: Next.js on the frontend, Supabase (Postgres + Auth) as the sole backend, no agent orchestration inside the app. What changed is the direction of travel: the app now serves agents rather than containing one. “Next.js 16 App Router / React 19, with server actions as the write path — the only outside API is the MCP endpoint.” Its design record is one specification and one implementation plan per phase under docs/superpowers/, the same phase-based discipline as nai-analysis and not this workspace's orchestrator/subagent/tool pattern — there is no command file and there are no agent files for it anywhere.

The seam to this workspace

There is one, and it is documentation rather than operation. /nai-document keeps a product map, and its first row is | `nai-onto` | `docs/architecture/product-nai-onto.html` | `github.com/udopnink/nai-onto` | — this page, tied to the repository it is surveyed from. That row is the seam in its entirety, and the page you are reading is its output. The command's rule for that branch says so itself: “the product's own repository is the source, and it is not this repo. There is nothing here to survey: no command file, no agent files, and the code is somewhere else entirely.”

It runs in one direction only. The sources are “that product's own as-built documentation, in a local checkout of its repository: its README.md, its overview and feature pages under docs/, and its design specs”, and “The agents read those paths and write, as always, only inside this repo.” Nothing here reaches the running application: the command “uses no web tools, and neither does any agent it dispatches”, and “It never runs an agent system to find out what it does. Everything comes from reading files.” The deployment at nai-onto.vercel.app, the /api/mcp endpoint described above, and the database behind both are all outside what a documentation run can touch.

Designed, not yet shipped

Known limitations