TUEO Product Whitepaper

1. What is TUEO

TUEO is a private AI collaboration platform for enterprises — AI participates as full-time employees of the organization (with positions, responsibilities, growth trajectories, behavioral boundaries, and long-term memory), operating the business alongside people within the customer’s own environment.

This is not a slogan but a product system that has been delivered. TUEO consists of ten products covering everything needed to bring AI “onto the payroll”:

• Identity: AI employees and human employees share the same roster, the same login, and the same permissions;
• Knowledge & memory: AI’s knowledge base and memory have a dedicated foundation — the more it is used, the more accurate it becomes, automatically organized and self-growing;
• Compute & models: heterogeneous compute is uniformly managed, and model serving comes with governance — one closed control plane;
• Collaboration: AI employees join group chats like colleagues, run work orders, host meetings, and accumulate organizational knowledge;
• Orchestration: business people use conversation to compose processes into AI applications that the organization can invoke once published;
• Capability: every skill AI can invoke is governed like a marketplace — procurement, authorization, metering, credentials;
• Execution: where AI actually does work is enclosed in isolated sandboxes, auditable and schedulable;
• Coding: the AI development team uses a real coding engine to modify code, run tests, and produce MRs;
• Delivery: the whole system is installed into the customer’s own data center, with support for running fully disconnected.

TUEO’s core thesis: the next stage of enterprise AI is not “smarter conversations” but “employees who can enter organizational operations.” AI needs positions, boundaries, growth, and auditability — precisely the things an organization does when managing a real human colleague. TUEO engineers this mechanism and delivers it privately.

1.1 Second-layer positioning: the intelligent foundation for enterprise digitalization

“AI onto the payroll” is the first-layer positioning — it is about AI running your business for you. TUEO also has a second-layer positioning, about the foundation of an enterprise’s entire digitalization:

In the era of AI programming, what enterprise digitalization truly lacks is not more systems, but an intelligent foundation that links the “definition, production, operations, updates, and coordination” of systems into one complete loop. TUEO is that foundation — defining systems by task (rather than developing systems), so that an enterprise’s existing capabilities are reused and AI-enabled, and run continuously on a self-operated foundation.

The external narrative order is: first make clear “what kind of foundation this is,” then land on “how AI employees work on the foundation.”

• Definition layer — define systems by task: studio orchestration + cohort work-order pipeline + executor execution. Business describes tasks; AI analyzes, dispatches, develops, tests, and delivers;
• Coordination layer — AI-enable capabilities, govern system silos: capabilities + skillplugins + identity. Register systems that already exist — OA / ERP / CRM / MES — as capabilities, authorize them, host their credentials, and let them be safely invoked by AI — it does not replace your systems; it makes them, for the first time, capabilities that AI can invoke, authorize, audit, and meter;
• Operations layer — resource management, application deployment and release, operations: console + executor. New systems, old systems, AI systems — one entry point to operate the whole stack.

Foundation = it does not replace your systems; instead, all your systems are defined, assembled, operated, and AI-enabled on this base.

1.3 Core philosophy (five principles)

1.4 Three things we do not sell

• We do not sell chatbots — that is the most basic form of an AI employee, not a product;
• We do not sell standalone AI tools — this is not a “rewrite” of Dify / Coze / n8n; we sell a system, not components;
• We do not sell “being able to answer” — we sell “being able to answer and to run, to be governed, and to be delivered.”

2. The problem to be solved

2.0 The issue of the era: from “data silos” to “system silos”

AI programming has two sides: the good side is that the cost of building systems approaches zero, and “development” is no longer a scarce resource; the new problem is an explosion in the number of systems, with AI-generated systems growing wild — no one owns their operations, no one owns their updates, and no one connects them to existing systems.

Data silos are a “reading” problem — data can be copied, moved, and centralized; ETL / data warehouses / data platforms fought this battle for twenty years and largely won. But moving data into a lake does not make systems talk: what AI needs is not just to read data, but to log into systems, know what capabilities they have, execute actions safely inside them, and leave an audit trail for every action — this is a “doing” problem that data governance has never solved.

Both ends are silos: traditional legacy systems are not yet AI-enabled (running in the data center, no one understands them, no one dares to touch them); new AI systems have no one to manage or operate them (easy to build, hard to sustain). System silos are harder to cure than data silos — systems are alive and have a blast radius; you cannot move an ERP into a lake, only keep it alive and have it invoked safely.

TUEO’s answer is the complete software development loop: business raises requirements → AI analyzes them into tasks → the AI team develops → testing → UAT → go live → continuous monitoring and operations → first take stock of existing capabilities, reuse instead of redeveloping → capability coordination → back to requirements. Core idea: define systems by task, rather than develop systems.

On this basis, enterprises commonly hit four gaps when bringing AI into actual business:

2.1 Can answer, cannot run

General large-model applications can only “answer”; they cannot do work in an enterprise’s real environment: modify data in systems, integrate with existing systems, execute code, or produce real files. What an enterprise needs is not a smarter assistant but a pair of hands that can truly deliver.

2.2 AI is a tool, not an employee

Most enterprises integrate AI as a tool into some system: a customer-service chatbot, a writing assistant. No position, no responsibility boundaries, no growth trajectory, no long-term memory, no behavioral audit. An AI “without identity” cannot be managed by the organization or bear continuous business responsibility.

2.3 There are decisions, but no execution layer

Even if AI can make correct judgments, who actually executes? Running AI’s code directly inside business systems is dangerous — you need an isolated, controlled, auditable execution layer that treats “user code is untrusted” as the default premise.

2.4 There is AI, but no governance and audit

In strongly regulated industries such as finance, government, and healthcare, every AI decision must be traceable, replayable, and auditable. Yet most AI platforms treat audit as an afterthought, scatter permissions across products, and embed model keys into clients — none of this passes compliance review, let alone private delivery.

TUEO solves these four gaps at once with a ten-product system.

3. Product system overview

3.1 Ten products, one system

3.2 Layered structure

Consumption    cohort-desktop (Electron desktop client) · cohort-server admin console
───────────────────────────────────────────────────────────
Experience layer      cohort (collaboration core) · studio (application orchestration)  ← where people and AI work together
Capability layer      capabilities (capability marketplace · invocation gateway)    ← one capability contract, two consumers
Execution layer       executor (sandbox execution) · codex-build (coding engine) ← where AI actually does work
───────────────────────────────────────────────────────────
Three foundation bases identity (organization / tenant / identity SSOT, all OIDC RPs → it is the OP) · engram (knowledge-memory base) · inference (compute and model serving)
Operations base       console (intelligent-foundation operations layer · deployment / middleware / private IdP)
Ecosystem             skillplugins (plugin source + @tueo/plugin-sdk)

3.3 Data flow and responsibility boundaries (who is the source of truth)

3.4 Integration matrix (row calls column)

4. identity — the identity foundation

In one sentence: the platform-wide unified identity foundation — one account to access every product, one token that states which tenant you are in, one directory managing human and AI employees.

4.1 Positioning

identity is the identity single source of truth (SSOT) of the TUEO system, carrying three platform-level capabilities:

1. OIDC IdP: standard OpenID Connect / OAuth 2.0 authorization, tokens, sessions, federation, multi-tenancy;
2. Org directory single source of truth: org structure + people + employment relationships, the SSOT of the platform-wide address book;
3. Authorization decision center: RBAC roles converged to three tiers, decision logic returned to identity, downstream products must not hold role information.

The design criterion for identity is: “would this still hold if we switched to another product?” It only carries platform-level identity capabilities and no single-product business logic.

4.2 Core capabilities

4.2.1 OIDC IdP (ES256 + PKCE + token rotation)

Built on a standard OIDC authorization server: authorization code + PKCE login, ES256-signed JWT access tokens, refresh token rotation (RFC 9700), RFC 8628 Device Flow, RFC 7662 introspection, JWKS rotation. Signing keys are stored encrypted and support multi-replica hot reload. Access tokens use a strictly minimal claim set — profiles are always resolved authoritatively via /userinfo, avoiding token bloat and permission drift.

4.2.2 Suite-level SSO (RFC 8693 token exchange)

The glue for one login across the six products: exchange the identity root token for a user token with aud=<product>, so studio / executor / capabilities can be entered directly without a second login. Two safety gates: the subject token must be the current root token; the audience must be inside the first-party product allowlist — exchange only does same-user, first-party horizontal or down-scoping; holding a token does not grant privilege escalation.

4.2.3 Down-scoped least-privilege tokens

Issue least-privilege tokens to semi-trusted execution bodies (AI engine subprocesses, local coding engines): a dedicated audience + a single functional scope + a short TTL. The worst credential an engine holds drops from “vendor model keys / user full-permission token” to “a ticket that can only burn this tenant’s quota, expires in 15 minutes, and is bound by audience to a fixed path” — one ticket per blast radius.

4.2.4 Org directory single source of truth

The org structure tree, member employment relationships, and personnel search are all provided by identity. The tree is stored with ltree; employment relationships combine user_org_memberships JOIN users JOIN org_nodes, and the position_title title lives on the employment relationship. The platform-wide address book is 100% built from this; changing a person changes identity in one place, and desktop / server / Matrix localpart follow across the platform.

4.2.5 RBAC role convergence + scope universe

The entire platform has only platform_admin / tenant_admin / member role names; 11 legacy names are normalized through an alias table. Scopes are derived programmatically from the role catalog and consumed uniformly (previously a pitfall where 5 hand-maintained scope lists caused silent stripping). Adding a product = adding one row to the catalog + mounting scopes, zero downstream changes.

4.2.6 Tenant switching = token re-issuance

“Which tenant am I in” has only one source of truth — the token itself. Switching = redoing authorization with a tenant hint; identity validates and re-issues the token; every issuance re-validates authorization, and if a role is revoked or a tenant deleted, it immediately falls back to home. Consumption points that only validate the token (such as WebSocket gateways) are automatically correct and never drift into privilege escalation.

4.2.7 SCIM inbound provisioning

A standard SCIM (RFC 7643/7644) implementation lives under /scim/v2/*, and external IdPs (Okta / Azure AD) integrate per the standard. Each tenant pins its tenantId with a static bearer token, making cross-tenant access impossible. User / group CRUD, filter operators, externalId reconciliation, sync logs, and failure audits.

4.2.8 Traceable audit (cryptographic hash chain)

Every identity / authorization / directory change enters the audit log, and rows are chained with SHA-256 contentHash + prev_hash — insertion, deletion, reordering, and row edits can all be detected by verifyChainIntegrity. The audit retention policy is configurable per tenant (90 days by default), and exports carry hash validation.

4.2.9 User custom-field governance + sensitive information encryption

Tenant administrators declare a field schema (type / required / validation / sensitive / searchable). Sensitive fields (such as ID numbers) are physically separated from ordinary fields: non-sensitive fields go into metadata; sensitive fields go into a separate table, encrypted with AES-256-GCM, returned desensitized, with plaintext reads leaving an audit trail — meeting the PIPL hard requirement that sensitive personal information be traceable.

4.2.10 Admin console

Covers organization / users / roles / audit / tenants / SSO / SCIM / custom fields / sessions / Webhooks / API Keys / branding, delivered against the TUEO platform design system (paper / ink / celadon / cinnabar), with multi-language and white-label support.

4.3 Differentiation

• AI employees and human employees share the same identity: users.type='ai_staff' is a first-class user type — same payroll, same directory, same addressing;
• Authorization decisions return to identity: competitors scatter “who counts as an admin” across products; identity keeps it in one place;
• Provable audit: the hash chain makes “who did what” verifiable and forgery-detectable;
• Privately deliverable: single-domain appliance + setup wizard + keys managed by the operations configuration center, fully deployable offline.

5. cohort — the collaboration core (flagship)

In one sentence: make AI a full-time employee of your organization — human and AI colleagues work, grow, and deliver together in the same workspace.

5.1 Positioning

cohort is TUEO’s flagship product, consisting of a server (cohort-server, NestJS 11 + Fastify + PostgreSQL) and a desktop client (cohort-desktop, a three-process Electron app). It carries the full business logic of the “AI employee workspace”: the AI employee entity registry, multi-AI group-chat collaboration, the cognitive loop, the work-order pipeline, the organizational knowledge graph, conversational memory, weekly-meeting orchestration, audit trails, and multi-tenant isolation.

The server is the data SSOT and the desktop is a thin client — enterprise data is not scattered on clients.

5.2 Core capabilities

5.2.1 AI employee entity (AiStaffRegistry)

AI employees are first-class entities “on the payroll with a job profile,” JOINing two SSOT layers:

• identity roster: payroll identity / real name / department / title, sourced from the same place as the address book;
• cohort ai_staff_profiles job profile: roleLabel / workMethod / toolPolicy.allow / leadKinds / ownedCapabilities / responsibilities / persona card.

The entire pipeline reads only this registry. Adding / deleting / changing an AI employee changes only identity (+ job profile) in one place, and the address book, work-order triage, capability routing, and broadcast attribution all follow — zero code changes, zero name literals. Deleting from identity → gone everywhere.

5.2.2 Multi-AI group-chat collaboration (coordinator)

Which AI employee should pick up a human message in a group chat is decided server-side (coordinatorJudge = SSOT):

• Fast path: no AI → not picked up; @mention → must respond; DM from human → auto-reply; AI speaking → guard against self-response loops; noise / pure emoji → not picked up;
• Slow path: group chat + human + expected response → using the AI employees’ real job profiles for deterministic responsibility scoring (zero LLM cost), LLM arbitration when multiple candidates are close, then fall back to a secretary.

Every decision is written to the audit log (coordinator.dispatch_judged). A group chat always has “one responsible party responding” without flooding, and routing is based on real job profiles rather than hardcoded names.

5.2.3 AI employee cognitive loop (Perceive → Think → Act → Reflect → Wait)

Every decision by every AI runs the full five-phase cognitive loop:

1. Perceive: reads the session, signals, and organizational context, first passing the principle gate (principleEnforcer.check('perceive')); a deny writes a rejection artifact directly;
2. Think: fuses long-term-memory retrieval + experience rules + project context, calling the LLM to output a structured intent; falls back to rule-based degradation when the LLM is unavailable;
3. Act: high-risk actions require human confirmation;
4. Reflect: the LLM reflects and writes back to memory, driving self-evolution;
5. Wait: returns to listening for the next round of signals.

The whole flow is timed with phaseTimings, observable and traceable.

5.2.4 Work-order system (intent → DoR → triage → agent execution)

The full pipeline from a chat message to the AI development team doing real work:

1. Intent recognition: LLM jsonMode + validation, recognizing bug / feature / incident;
2. DoR acceptance: accepted by severity level; AI can self-supplement — using the LLM to turn a Chinese work order into code search terms, and local ripgrep over real files to locate reproduction steps, never fabricating;
3. Triage: passport gate → LLM infers assigned_role / priority / AC → dispatched to the dev_team_room; assignable roles are dynamically injected by the registry;
4. State machine: 14 states + a transition matrix validated in O(1);
5. Agent execution: 5-phase single run-role, with validateToolList doing server-side hard validation of out-of-bounds tools against toolPolicy.allow.

The desktop client visualizes this with TriageCard / BuildProgressCard; AI really modifies files, really runs tests, and really commits back to the work order on locally checked-out repos. Human messages can also be auto-classified into work orders.

5.2.5 Organizational knowledge graph (“organizational air”)

Distills organizational conversation into a knowledge graph: the LLM extracts entities and typed relationships from messages into kg_entities / kg_edges (pgvector + relational tables + provenance); on retrieval, pgvector cosine top-K (tenant-isolated) → graph multi-hop neighbors (commitments / dependencies / conflicts) → sensitivity gate (strictest by default; sensitive information does not leak).

Knowledge storage uses a single database, three-in-one (Postgres + pgvector + relational tables), with zero dual-writes and zero drift; an air-gapped install depends only on two services: Postgres + identity.

5.2.6 Conversational memory (individual long-term memory + shared substrate)

Every AI has long-term memory shared across rooms (7-day half-life decay, capped at 200 entries), with the server-side /cognitive-loop/memory as the authoritative copy. All AI decisions share the same “meeting-room state” substrate: main topic / settled facts / open questions / unfulfilled commitments. Switching rooms or multi-AI collaboration never starts fresh independently — the more the organization uses it, the smarter it gets.

5.2.7 Shadow AI invisible twin

Behind every real person sits an invisible twin: it learns the person’s own messages (style / tone / length) and, when the other party sends a message awaiting a reply and the person has not responded in 30s, drafts in the person’s voice in the background. The send-impersonation master switch is off by default — it only generates + audits, never sends automatically. The impersonation gate = master switch ∧ not frozen ∧ not protected zone ∧ confidence ≥ trust threshold ∧ risk ≤ L2, with independent thresholds across four buckets: finance / customer / technical / internal.

5.2.8 Server-side weekly-meeting orchestration

The closed loop of 8 AI employees reporting, discussing, asking for help, and resolving every week runs entirely server-side: per-AI attendee evidence gathering (last ~50 room messages) → inference → speaking signed with the AI’s real uuid. Total failure = honest failure that does not advance the phase and logs a system message explaining the real cause (curing the production incident where “LLM gateway quota 403 was silently swallowed into an empty meeting”). Auto-initiated every Friday.

5.2.9 Message engine + realtime channel

Chat message CRUD, delivery / read receipts, streaming AI replies, and translation are all server-side SSOT and broadcast over WS. Concurrency / races / cross-tenant issues are stopped at the server; translation is bounded (context-hash deduplication + technical-literal mask/restore + slot queue). The WS gateway is hardened on three axes (strict tenant-claim validation, jti revocation, per-tenant sliding-window rate limiting).

5.2.10 Engine model gateway (credentials never leave the server)

The AI coding engine holds no vendor model keys: the engine’s base_url points to the server’s OpenAI-compatible endpoint, holding a down-scoped short-lived ticket issued by the server (15 minutes, audience bound to a path), and the real key is resolved per tenant and injected by the server. Three hard properties: model is decided by the server and client-side values ignored, client credential fields are always discarded, and upstream responses are desensitized before being passed back.

5.2.11 MCP Tueo Server (the unified outlet for business capabilities into the engine)

Exposes cohort business capabilities (work orders / knowledge / attachments / commitments / speech) as standard MCP tools to execution engines, forming the loop of “AI works → results flow back into the collaboration system.”

5.2.12 Desktop client (cohort-desktop)

• Three-process Electron: main process (OS integration / OIDC / IPC / crash self-healing) + preload (contextBridge allowlist + per-category token-bucket rate limiting, destructive channels with separate small buckets) + renderer (React 19 + Zustand);
• Four-pane workspace: conversation list / message area / details / WorkspacePanel (document Markdown/HTML interconversion → PDF/PPTX export + IDE workbench);
• Security in depth: OIDC PKCE + ES256, three down-scoped tokens, CSP enforcement, audit funneled upstream to the server console, IPC rate limiting;
• Local pairing: the main process spawns the coding engine directly (ACP protocol); file reads/writes stay within the working-directory boundary, and permission requests are denied by default — “a human holds the gate at the critical checkpoints” is not a slogan.

5.3 AI employee positions and permission boundaries (AI employees are equally governed)

An AI employee’s capability boundary is determined by position, responsibilities, and granted tool permissions, not by what it is capable of — this is one of the most fundamental differences between TUEO and a “general-purpose AI assistant.”

• How boundaries are set: each AI employee declares its responsibility scope and tool allowlist (toolPolicy.allow) in its job profile. identity governs “who it is” (payroll identity), and the registry governs “how it works” (position / responsibilities / permissions); the two lines jointly determine what it is allowed to do. A secretary is a secretary — Su Wan is a secretary; she cannot operate operations servers;
• How boundaries are enforced: out-of-bounds tools are hard-validated server-side (validateToolList against toolPolicy.allow) and always rejected; the perceive phase first passes the principle gate (PrincipleEnforcer, pattern hits are adjudicated immediately); high-risk actions require human approval; every decision and every rejection goes into the audit log — four lines of behavioral defense backing each other up;
• Why boundaries are hard: a human changing positions and an AI changing positions are the same — edit one position configuration and the capability scope follows everywhere. AI employees and human employees follow the same governance logic: it is strong, but only strong within the boundaries the organization grants it.

This mechanism makes “the stronger the AI, the clearer the boundaries” an engineering fact: an AI that can write code, when not granted operations permissions, will have any request touching the operations server hard-rejected by the system with an audit record — an organization can loosen trust in AI gradually instead of betting everything at once.

5.4 Differentiation

• AI is “an employee within the organization’s payroll” rather than a tool — zero name literals, the single source of names is identity;
• Group-chat moderation is a server contract rather than a client heuristic, preventing self-response loops, with an audit record for every decision;
• Work orders are not questionnaires: DoR graded acceptance + AI self-supplement, borrowing rigor without borrowing bureaucracy;
• Credentials never leave the server, audit is funneled upstream through one outlet, enterprise data is not scattered on clients;
• Positions determine boundaries: AI employees and human employees follow the same governance logic; out-of-bounds tools are hard-rejected server-side with an audit record.

6. studio — the application orchestration platform

In one sentence: business people use conversation to compose processes into applications where AI cognizes, decides, and acts on business objects — the AI-native successor to BPM, not another workflow canvas.

6.1 Positioning

studio is TUEO’s “orchestration engine layer / intelligent-labor legislation layer”: it composes intelligent labor in the organization (AI employees + connectors + human review) into applications that can be published, audited, and evolved, invoked with trust by people / AI employees / external agents. It runs in combination with cohort: cohort provides the AI employee runtime, human-review cards, and result feedback; studio provides structured orchestration, the acceptance release gate, and governance guardrails.

6.2 Core capabilities

6.2.1 Event-sourcing orchestration engine

11 node types (start / end / branch / AI cognize / AI employee / human / capability / subprocess / loop / wait / parallel), and every state transition appends one append-only run-trace event. State is derived from events: human / subprocess / loop / timer / parallel / AI-employee all run through durable pause (process restart resumes the run; zero threads held). Supports breakpoint single-step / continue, rerun from a failed step, and recursion protection.

6.2.2 Conversational copilot (natural-language orchestration)

Business people state an intent (e.g., “reimbursements over 3000 go to the finance director for approval”), and the copilot produces a high-level approval spec, deterministically compiled into a valid FlowDef — the LLM only outputs the simple JSON of “what to judge / how to route / how many approval levels,” and the structure is guaranteed valid by the compiler, with at most 3 self-corrections. Deterministic conversion · intelligent content.

6.2.3 Release governance: draft/published version isolation + acceptance test gate

The orchestrator stores drafts; on release it takes an immutable semver version snapshot, and production always runs the latest published version. Before release, an acceptance test suite runs first (stubbed AI output + scripted human review + stubbed capabilities, deterministic replay); release only proceeds when all pass — acceptance tests = the release gate, and it doubles as the L2/L3 regression safety net. Historical versions can be rolled back.

6.2.4 AI cognize-decide-act nodes

One primitive supports classification / judgment / extraction / image reading / autonomous tool invocation: structured JSON output contract + strong schema validation of model output, an agentic loop (function-calling, every tool_call leaving a trace), multimodal vision (images passed through a vision model into descriptions), and node-level model-field overrides for semantic routing.

6.2.5 AI employee nodes + human review nodes (human-machine peer actors)

The ai_staff node dispatches work to AI employees on the identity payroll (working inside cohort); the human review node pauses pending human adjudication — both actor types each have SLAs and each have an organizational escalation chain. AI employees are colleagues, not scripts; people are peer actors in the process.

6.2.6 Orchestration variable model: obj/steps/sys/env four scopes

Node input mappings and branch conditions use a typed expression AST, making the data flow deterministic, replayable, and testable — branch conditions are not black-box prompts but verifiable declarations.

6.2.7 Governance spine (enforcement, not display)

• Kill-switch circuit breaking: global / per-application one-click circuit break (423);
• Quota rate limiting: per-app run rate (429);
• Token budget: if cumulative tokens in a single run exceed the limit, the engine aborts;
• Content-safety gate: forbidden words + PII regex (phone / email / ID number), mode = off/flag/block;
• Audit: audit logs are projected from run-trace events and exportable (SOC 2 / MLPS / EU AI Act forensics).

6.2.8 cohort integration (app-as-tool)

Inside cohort conversations, applications are used as tools: select an app → form card (precise input) → start a run bound to the session thread → results / human-review cards fed back. Form prefill goes through the provenance gate (only fills fields with evidence); result-card narrative templates replace placeholders with real results (if a value cannot be obtained, the whole segment is dropped — zero LLM, zero fabrication).

6.2.9 Design tab + multi-channel adaptation

AI generates declarative building-block layouts from real artifact fields, hard-validated by the backend (block enumeration + bind keeps only real fields + array blocks must bind array fields; fabrication is always discarded). One orchestration, multi-channel delivery: cohort’s four-pane shell / enterprise IM (WeCom / DingTalk / Lark cards) / web widgets.

6.2.10 Automated triggers + MCP exposure + debugging and observability

Applications can move from manual invocation to scheduled / webhook auto-trigger; every published application is exposed as an MCP tool that any agent can invoke (no walled garden); SSE streaming debug + dry-run rehearsal + node Mock coverage + breakpoint debugging.

6.3 Differentiation

• Not Dify / n8n: it is “AI-native orchestration on business objects,” with business-object type contracts + event sourcing;
• Acceptance tests = the release gate: AI orchestration is quality-controlled like software engineering;
• AI employees are human-machine peer actors: with positions, SLAs, and an organizational escalation chain;
• Governance really intercepts rather than displays: circuit breaking / quota / token budget / content-safety gate all enforced at the engine layer.

7. capabilities — the capability marketplace

In one sentence: the App Store for enterprise AI capabilities — one capability contract, AI uses it as a tool and people use it as a UI, with end-to-end governance from production and marketplace to procurement, authorization, and air-gapped distribution.

7.1 Positioning

capabilities is the independent platform layer for “where capabilities come from” (production / platform), belonging to no consumption host. The load-bearing wall is the production/consumption dichotomy: the capability platform owns the registry SSOT + marketplace + installation governance + credential vault + invocation gateway + platform console; cohort (chat / AI employees) and studio (application orchestration) are both hosts that consume via the SDK contract, each with its own native UI, never depending in reverse.

This fixes the earlier architecture defect of welding the registry / gateway into cohort-server — studio used to hardcode env config to connect directly to executor, bypassing the entire platform.

7.2 Core capabilities

7.2.1 Registry SSOT + release lifecycle

The single source of truth for the manifest, version, and state of skills / plugins. Producer side goes draft → in_review → published / rejected, orthogonal to state (active / archived). .tueopkg uploads land as drafts after validation (semver / capability declaration / payload integrity), and the original package is stored content-addressed by sha256 digest.

7.2.2 Signature and trust governance (Ed25519)

Manifests can be signed with a key → Ed25519 detached signature → verification derives a three-tier trust level: official / partner / community. Cross-repo signature algorithms are byte-for-byte consistent (locked by drift-lock tests). A declared signature that fails verification = tampering / impersonation, and installation is rejected.

7.2.3 Installation governance (tenant-level)

Which skills a tenant has installed + whether they are enabled. Installation = deployment state, enablement = run switch, user preference = personal switch — the three layers are never confused. The invocation gateway fronts a hard assertEnabled gate.

7.2.4 Credential vault (tenant-level encryption)

Plugin configuration: settings in plaintext + secrets encrypted (AES-256-GCM); the gateway decrypts and injects at invocation time, and neither users nor AI ever see the secrets. Visible from the same origin across hosts (cohort / studio).

7.2.5 Invocation gateway (dispatch by kind + paywall / usage welded in)

One invocation passes the installation gate + paywall gate + availability-scope gate → decrypt and inject credentials → dispatch by kind: action → executor sandbox / knowledge → return content directly and inject it into the host’s LLM context (zero sandbox, zero cost).

★The paywall and usage metering are both welded into the gateway: any indirect / delegated invocation naturally passes the gates and is metered, curing the “bypass the charge” vulnerability.

7.2.6 Procurement governance loop

Trial → apply-approval → order (corporate / online) → finance confirmation → invoice, fully traced. Budget gate (spent + pending + this order ≤ cap), and a buyer self-audit derived flow (orders / entitlements / applications / installations / scope changes aggregated into a timeline).

7.2.7 Monetization / pricing

Price lives on the product (Stripe paradigm): operators set a global price per skill and can override with a B2B contract price for a specific customer tenant. Billing-scope rule: only outright purchase or subscription duration — no usage / seat billing (usage is pure business analysis, not metering).

7.2.8 Entitlement SSOT + subscription lifecycle

The single source of truth for “this tenant is authorized to use this paid skill.” Online and offline paths write to the same table, and gates read it uniformly. Expiry invalidates immediately, scheduled sweepbacks catch stragglers, and banner warnings appear before expiry. Subscription renewal re-runs contract + invoice + re-issuance.

7.2.9 Offline license activation (signed License as the single SSOT)

Paid activation for private / air-gapped customers: the signed License file is the single trust root, network is just a transport layer, and air-gapped environments carry the same file by hand. Soft node lock = deploymentId (generated on first platform start; prevents one file being copied to multiple deployments; no hardware lock, no customer friction). No online activation / heartbeat / technical revocation (pure contractual trust).

7.2.10 Air-gapped offline distribution (.tueoupdate unified artifact)

Getting skill bits into the intranet: one signed update package carries both the catalog and platform components, with a single import entry in console. The signed manifest is an immutable load-bearing wall (bundles are stored locally in a separate column; the manifest is never mutated, or verification breaks). Bundle-runtime by default needs no image.

7.2.11 Availability scope + usage operations dashboard

“Who in the tenant can use this skill” authorization assignment (mode = all / departments / users, sourced from identity SCIM). The usage dashboard answers “is the capability worth it, and is there waste or risk” (idle-authorization detection = entitlement with zero invocations = wasted money).

7.2.12 Four-step permission loop

Developers declare permission[] → frontend risk-tier red labeling (network / file system / execution / keys) → consent dialog at install time (grant moment, audited) → executor sandbox runtime enforcement (an ungranted network permission uses unshare network namespace for true disconnection — zero outbound, preventing exfiltration).

7.3 Differentiation

• One capability contract, two consumers: the same capability can be used by AI as a tool (executor sandbox) or by people as a UI (declarative / frontend bundle);
• Commercial loop natively welded into the invocation gateway: delegated / indirect invocations naturally pass gates and are metered;
• Signed License as the single authorization SSOT: air-gapped and online use the same mechanism;
• Production-state keys fail-closed: missing official signing private key / vault master key / session key / S2S token → refuses to start (prevents public dev seeds from forging official signatures and offline licenses);
• Anti-clock-rollback high watermark + scheduled sweep of all expired tenants, specifically curing air-gapped customers who roll the clock back to keep expired subscriptions alive.

8. executor — the sandbox execution base

In one sentence: the hands of AI — putting untrusted code / commands / images into isolated sandboxes, auditable, schedulable, and scalable, doing real work on behalf of AI employees and returning structured results.

8.1 Positioning

cohort (workspace), studio (orchestration), and capabilities (marketplace) decide “what to do”; executor does the “actually producing it” — receiving code packages / commands / self-provided images, launching isolated Runner sandboxes as K8s Jobs for execution, and returning structured results via callback, fully audited. It is the platform-wide unified capability execution surface and the isolation wall for “user code is untrusted” inside the trust boundary.

8.2 Core capabilities

8.2.1 Multi-runtime sandbox execution (python packages / generic commands / self-provided images)

One job contract supports three execution modes: python code package (pip installs dependencies → import entrypoint → main(**inputs)), command mode (language-agnostic, runs arbitrary shell), and image mode (each job starts the specified image). Large inputs (>64KB) spill to mounted files to avoid env limits; command-mode jobs without granted network permission run subprocesses in an unshare --net disconnected network namespace.

8.2.2 K8s-native isolation + five-level priority scheduling + per-job resource quotas

Each job lands as an independent Pod: no privileges, read-only root filesystem, all capabilities dropped, seccomp RuntimeDefault, auto-reclaimed after execution. Five priority levels (CRITICAL can preempt BACKGROUND) + per-job configurable CPU / memory.

8.2.3 Admission control + priority queue

Triple backpressure: global concurrency cap + per-tenant quota (DB-modifiable at runtime) + host resource pressure. Jobs above the concurrency cap enter the QUEUED queue, drained by priority + FIFO; atomic claiming prevents double dispatch, and one tenant hitting its cap does not block other tenants.

8.2.4 Reconciliation loop (pull is truth, callback is optimization)

Callbacks are an optimization; the reconciliation loop actively asks K8s for the truth every 30s, driving zombie jobs to a terminal state, marking them lost, and self-healing the in-flight count. A callback that never arrives does not leave a job stuck running.

8.2.5 DAG workflow orchestration

A directed acyclic graph expresses dependencies and parallelism (a set of jobs sharing a dag_id, zero standalone tables); failed steps can be re-run at fixed points (incremental / full).

8.2.6 Multi-tenant isolation (fail-closed)

All resources are bound to tenant_id, and queries / writes enforce tenant filtering. If the tenant cannot be obtained, reject rather than pass everything. “Want to see everything” and “forgot to pass the tenant” look different at the code level; platform-level aggregation must be explicitly declared.

8.2.7 Full security audit + Transactional Outbox events

All lifecycle operations write to the audit table; business operations and events land in the outbox in the same transaction, delivered asynchronously as CloudEvents 1.0 (consumers: CI / notifications / billing), without blocking business.

8.2.8 Credential and callback security

Job Pods are injected with least-privilege MinIO credentials (bucket-scoped); callback URLs embed a per-job HMAC token, preventing anyone holding a shared token from driving arbitrary job states; terminal-state callbacks are idempotent (preventing state resurrection).

8.2.9 AI coding agent coding-agent

An autonomous coding agent: clones a GitLab repo → tool loop to implement the work order → self-test → commit → push branch. The passport (tueo-passport extension point) compiles into hard file-edit gates (any zone crossing is BLOCKED); visual self-verification = real Chromium screenshots + a vision model judging the image, not jsdom guesses.

8.2.10 Observability

Prometheus metrics (scheduling latency / queue wait / per-tenant in-flight / node water level) + real-time node resource snapshots + real-time container logs of running jobs + execution timeline rebuilt from persistent data.

8.3 Differentiation

• A unified multi-runtime contract (python / command / image) rather than a single Python sandbox;
• Scheduling is a first-class citizen: tenant-level fairness + priority preemption; most sandbox products only have a simple concurrency count;
• Self-healing reconciliation loop: competitors often get stuck when a callback never arrives;
• Per-job HMAC callback binding + least-privilege credentials + network-isolated sandbox — both callbacks and credentials are isolated per job.

9. skillplugins — skill plugins and the SDK

In one sentence: one capability contract, two consumers — letting AI assistants truly “do business,” turning enterprise process capabilities into plugins that can be signed, sandboxed, and brought to market.

9.1 Positioning

skillplugins is the production side and contract load-bearing wall of the TUEO plugin platform, the source of the four-layer architecture: skillplugins (plugin package + SDK) / capability platform (registry + governance + distribution) / executor (backend sandbox) / desktop (frontend rendering). @tueo/plugin-sdk is the single source of the four-layer manifest / capability / invocation contract.

9.2 Core capabilities

9.2.1 Plugin manifest contract (PluginManifest)

Defining a plugin = manifest (capability declaration) + backend (executor execution) + frontend (desktop rendering), three parts. Language-neutral (input / output use JSON Schema, so even executor’s Python can validate). humanSurface provides three entries: slash (commands) / form (auto-derived form) / preview (fourth-pane preview).

9.2.2 Plugin signature and trust governance

On the release side, a private key signs an Ed25519 detached signature over the manifest; on the load / install side, a trusted public-key registry verifies the signature and derives the trust level. Tampering fails verification, with anti-tampering assertions at install time.

9.2.3 Backend runtime I/O contract

Inputs are read from cwd/inputs.json, results are written to $OUTPUT_DIR/result.json, and large-file artifacts are uploaded by the runner to MinIO. Authors only need serve({capabilityId: handler}); I/O, error normalization, and exit codes are all handled by the SDK.

9.2.4 Reference implementation: deck (presentations)

17 layouts (title / section / bullets / kpi / twocol / process / chart / statement / agenda / compare / timeline / composite / scorecard / matrix / gantt / pillars / figure) + action titles + 4 design languages. The same DSL produces an HTML preview and an editable .pptx export (preview = export consistency; no more “preview looks good, export breaks”). PptxGenJS motifs degrade gracefully.

9.2.5 Inheriting existing PPT styles

Import an existing .pptx: content is parsed server-side, and the plugin extracts the color palette + fonts from theme1.xml into a design language, changing only colors and fonts while preserving the platform’s layout quality — the customer’s brand assets are inherited.

9.2.6 pharma-doc (pharmaceutical compliance example)

A drug delivery-note recognition plugin: the VLM extracts 12 fields → the plugin does deterministic rule validation (approval-number format / production date < expiry / expiry > today / quantity > 0 / required fields) → green / yellow / red colored review preview. The zero-model-invocation validation layer is idempotent, testable, and auditable; humans only step in below 1% of the time.

9.3 Differentiation

• One capability contract, two consumers: the same capability is exposed to both AI (function-calling tool) and people (slash / form / preview), with byte-identical input;
• AI handles extraction and content; the rule engine handles deterministic validation: results are idempotent, testable, and auditable;
• Design-token-driven rendering: preview = export; changing language = swapping token files, zero engine changes;
• Resilient and honest degradation: a broken page → a placeholder page instead of ruining the whole deck; when data cannot be obtained, show ”—”, never fabricate.

10. codex-build — the coding engine

In one sentence: TUEO’s coding kernel — letting AI employees “really work, really produce,” no longer a self-reported agent but a real coding execution engine with enterprise identity boundaries and auditable traces.

10.1 Positioning

codex-build is the unified execution engine of the entire TUEO platform, serving as the coding kernel of the AI development team. It replaces the three hand-built agent loops (about 13,300 lines) that the server and desktop sides each maintained before.

The architecture division in one sentence: the engine is responsible for “how to do it” (really reading codebases / modifying files / running shell / searching the web / long tasks / subagents), the Server is responsible for “whether it can, what it does, and what traces remain” (identity, authorization, context, credentials, audit), and the Desktop is responsible for “visible, clickable, and locally reachable” (pairing and rendering).

The engine’s native interaction and built-in login capabilities are all locked down, leaving only the managed entry points — it is a first-class-citizen runtime “tamed” by the TUEO platform into an enterprise executor, not a standalone terminal product.

10.2 Core capabilities

10.2.1 Real coding execution (not narrative)

From “claims it did” to “really did”: the agent works inside a real repository workspace — clone → read code → modify files → run tests → commit → push → produce an MR, outputting real files / diffs / branches. Built-in tool family: read_file (including image / pdf / pptx / metadata parsers), search_replace, bash, grep, list_dir, monitor, scheduler, todo, web_search / web_fetch.

10.2.2 Understanding the codebase

Builds and navigates the structure of large codebases: code indexing (index_manager + languages + scope_graph), workspace management (folder trust + filesystem notifications), and Context Packs (role / constraints segments + work-order spec / plan / AC + model routing) materialized and injected into the workspace along with the task.

10.2.3 Managed runtime (ACP embedded)

Driven by desktop / executor over the Agent Client Protocol (stdio JSON-RPC), supporting long sessions, realtime event streams, and permission / approval cards. Extension methods implement request-permission, ask-user, subagent consent, and folder trust — all presented as cards by the desktop and returned back.

10.2.4 Subagent collaboration (engine-level hard gate)

The main agent can start subagents in parallel / nested by task complexity, but any first subagent spawn must pass an engine-level consent hard gate. Invariants: ask only once, per-user request expiry, no tool-capability grant — turning “whether to use subagent collaboration” into a confirmable enterprise decision on every request, not a matter of prompting.

10.2.5 MCP business capability integration

The engine acts as an MCP client consuming the server’s tueo MCP Server: work orders / applications / connectors / knowledge / commitments / attachments / messages enter the engine through one outlet. Business capabilities are not scattered on the engine side, and credentials are not handed down to clients.

10.2.6 Enterprise identity boundaries

Native API keys / built-in account login / interactive terminal / headless / relay / session-history execution are all permanently disabled; the managed entry for model execution = ACP + identity. Sessions are written to an owner sidecar (0600, issuer / tenant / subject), and new / load / prompt / cancel all fail closed, preventing cross-tenant session takeover.

10.2.7 Credentials never leave the server

The engine holds no vendor model keys, only a short-lived session ticket issued by the server, and real models are reached via the engine gateway. The real key never leaves the server process memory even once.

10.2.8 Vision and speech multimodality

A text-only main model receiving images / audio does not error: images are converted to descriptions via an auxiliary vision model (falling back to the raw image for the main model is forbidden), and speech is handled by the engine’s built-in voice runtime (streaming dictation + synthesis). Model routing is always decided by the server; clients cannot name arbitrary models.

10.2.9 Sandbox and process isolation

Built-in multi-tier sandbox profiles + deny globs + network-disconnection policy. Multiple tenants share one installation without seeing each other: Linux users + separate homes (all user-mode data paths) + Bubblewrap, with each tenant’s engine data in its own separate directory.

10.2.10 Folder Trust gate (the code-execution red line)

Cloned repos carrying hooks / MCP config / environment config are not loaded or executed by default (otherwise, cloning = remote code execution). Compile-time version stamps: builds without the stamp silently disable folder trust; releases must go through the release script + red-line validation (a repo with hooks must raise a trust prompt, or it must not be released).

10.2.11 Upstream traceable governance (fork health)

TUEO manages its changes to upstream with a patch ledger + source-equivalence verification + layered-customization constraints: TUEO_UPSTREAM.toml pins the upstream commit SHA, source-archive equivalence is verified (file_count + manifest_sha256 + status=passed), and CI enforces metadata consistency. At any time, it can answer “which upstream commit does this code come from, which patch changed it, and can it be rolled back.”

10.3 Differentiation

• From “self-reported agent” to “real execution”: output is real files / diffs / MRs, making coding delivery trustworthy;
• One coding engine unifies the platform: eliminating the desktop / server three hand-built agent loops;
• The enterprise-trust four-piece set: identity boundaries, credentials never leaving the server, triple confirmation gates for subagents / permissions / folder trust, and auditable traces;
• Fork governance is a selling point: every patch has a ledger, every release has source-equivalence verification, and rollback is possible — private customers dare to use it;
• Multi-tenant process isolation + single-binary delivery, ready for offline / private deployment;
• Dogfood engineering: the AI development team is using this engine to develop TUEO’s own products.

11. console — the intelligent-foundation operations layer · private delivery and operations

In one sentence: the operations layer of the intelligent foundation — one click turns bare metal into a TUEO production environment, and then one interface operates all services and middleware.

11.1 Positioning

console (the TUEO Console operations platform) is the operations layer of the intelligent foundation and the “delivery and operations base”: it carries all product lines above and manages k3s / Harbor / CNPG / middleware below. New systems, old systems, AI systems — one entry point to operate the whole stack. A three-piece set covers the complete lifecycle — console = private installer + on-site operations hub (deployment orchestration / configuration center / status wall / logs / backup / upgrade / audit), tueo-ci-images = two-layer immutable offline CI images, and tueo-build = the coding-engine source and release pipeline. The base (db / redis / k3s / MinIO) is itself a managed object operated by it — even itself is a managed object (self-upgrade only swaps images; the genesis manifest is the SSOT forever).

11.2 Core capabilities

11.2.1 Service catalog SSOT (manifest)

Converges registries scattered in many places into a single declarative service catalog (11+ services: ops-console / postgres / redis / minio / identity / cohort-server / executor / studio-api / studio-web / capabilities-api / cohort-desktop / skillplugins), with static topology as the single source of truth. Adding a product line = adding one JSON entry + a PR, zero code.

11.2.2 Three-driver deployment orchestration (local-dev / compose / k8s)

Three runtime domains under one domain model: local native processes, single-machine Docker, and the customer’s existing K8s. One platform manages both local development and customer single machines and existing clusters; customers without K8s can still install (built-in k3s base).

11.2.3 Image promotion gate + one-click deployment (build registry → runtime registry)

CI only pushes images to the build registry; the platform copies tags via Harbor pull-replication to promote them into the intranet runtime registry, then applies + rolls out once the tag is in place. A product repo including one template gets the complete build-image + deploy-prod production pipeline, with images auto-promoting from the connected build registry to the intranet runtime registry, zero manual work.

11.2.4 Configuration center (AES-GCM secrets stored + version rollback)

Ordinary configuration renders declaratively; secrets are stored encrypted (AES-256-GCM, master key); version snapshots can be rolled back; secrets never enter git. Supports both local AES and Vault backends.

11.2.5 The private operations lifeline

Pre-install health check (comprehensive preflight assertions), full-database backup and restore, air-gapped remote-support diagnostic bundles, and backup-first upgrade migrations. Backup-first + rollback points + upgrade history — when something really goes wrong at a customer site, there is a backup to restore and a diagnostic bundle for remote rescue.

11.2.6 Status wall + data operations panel

Operators run all managed workloads and middleware from one interface in the Console: no kubectl, no memorizing subdomains, no data ports exposed. PG / Redis never open public ingress; heavy operations go through on-demand temporary secure tunnels (short TTL + audit).

11.2.7 Offline update import (.tueoupdate signature verification + preflight + catalog forwarding)

The platform acts as the offline update distribution hub: .tueoupdate packages go through Ed25519 official verification → preflight compatibility gate → the bundle segment forwarded to capabilities for import, the image segment loaded into Harbor via skopeo. Failed verification / unsigned → rejected.

11.2.8 Platform self-upgrade (dogfood, only swapping images)

The operations platform deploys itself: the genesis bootstrap is manual once; afterward, pushing to main auto-builds → promotes → swaps images → polls /api/version to convergence. Upgrades only change image tags and never blow up the genesis manifest (PVC / master keys / ConfigMap / gateway all preserved). The classic self-managing-platform pattern.

11.2.9 Reproducible CI base images (supply-chain security)

Two-layer immutable offline CI images: lock pins all inputs (base-image digests + Debian snapshot timestamps + name=version apt packages + binary checksums), making builds reproducible, offline, signed, and with SBOMs. Ordinary MRs are zero-network, zero-download, and build credentials exist only on protected runners — minimizing the supply-chain attack surface.

11.2.10 Private deployment kit (replayable kit)

A replayable set of scripts + manifest that turns bare metal into a TUEO production environment: fill in one site manifest, execute in 00 → 60 order, replayable, no hand-typed SSH. TUEO uses the same kit to harden itself (dogfood).

11.3 Differentiation

• Private deployment is the main path rather than SaaS: each customer gets an independent, single-site, isolated installation, offline / air-gapped by default, one-click install, delivered with offline bundle + license;
• Anti-overengineering: no Argo / Vault / Loki family bundles; tool weight matches the scale of the problem;
• Service catalog = manifest-file SSOT: curing the recurring “DB is truth, file is seed” drift root cause;
• True dogfood: the platform deploys itself with its own k8s driver and deploys real services to the cluster with its own API;
• Offline update supply chain: .tueoupdate package signature verification + preflight compatibility gate + catalog-segment forwarding; unsigned packages are rejected.

12. engram — the knowledge-memory base

In one sentence: let AI answer the enterprise’s questions with the enterprise’s own knowledge — knowledge base, conversational memory, and knowledge association on a single base, ever more accurate through use, growing on its own.

12.1 Positioning

engram is the knowledge / memory single source of truth (SSOT) of the TUEO system, carrying three platform-level capabilities:

1. Enterprise knowledge base: settles policies, documents, and processes into retrievable, verifiable enterprise knowledge;
2. Conversational memory: daily collaboration and Q&A automatically settle into long-term memory, so the organization never forgets through use;
3. Knowledge association: understands the connections between knowledge, supporting multi-step follow-up questions — connecting facts into judgment.

engram, identity, and inference are the three foundation bases, consumed by every product in the suite. It answers “what you know and what you remember”, complementary to identity’s answer of “who you are”.

12.2 Core capabilities

12.2.1 Enterprise knowledge base

Settles policies, documents, and processes into an enterprise knowledge base; Q&A answers directly from internal material — grounded in evidence and never fabricated, letting AI answer the enterprise’s questions with the enterprise’s own knowledge rather than vague generalities.

12.2.2 Conversational memory · automatic settlement

Daily collaboration and Q&A automatically settle into long-term memory; the system automatically summarizes, removes noise, and resolves contradictions — the more the knowledge base is used, the more accurate it becomes, growing on its own. Switching rooms or collaborating across multiple AIs never restarts from zero.

12.2.3 Knowledge association · multi-step follow-up

Beyond answering isolated questions, it understands the connections between knowledge and supports multi-step follow-ups such as “ask A first, then pursue B” — connecting facts into judgment rather than scattered retrieval results.

12.2.4 Content security · tiered governance

Sensitive content is governed by tier — who can see what and what cannot be shared externally, flexibly configured to the enterprise’s own policies — the more sensitive, the more controlled, preventing leaks at the source.

12.2.5 Unified permissions · fully traced

Knowledge access and identity permissions are managed in one place; every read and every answer is traceable — strict isolation between departments, each seeing only its own, all wired to the same identity authentication.

12.2.6 Lightweight deployment · data never leaves its domain

Lightweight to deploy, small footprint, Chinese-first; enterprise knowledge always stays inside the enterprise — data never leaves its domain, the more it is used the better it understands the enterprise, and it is fully deployable offline.

12.3 Differentiation

• Three-in-one base: knowledge base, conversational memory, and knowledge association flow through one base, rather than assembling multiple single-purpose tools;
• Ever more accurate through use: automatic settlement lets the knowledge base grow itself — “data stays in the domain, knowledge accumulates, and it cannot be swapped out” is a tangible sales story;
• Lightweight for private deployment: light deployment, a single base, Chinese-first — checking every box for to-B private delivery;
• Consumed by every product: cohort’s AI employees use its memory to make decisions, and studio-orchestrated applications use its knowledge base for grounded answers.

13. inference — compute and model serving

In one sentence: give the enterprise’s private AI infrastructure a unified control plane for compute and models — heterogeneous compute under one management, model serving with governance, one closed loop that is verifiable and reversible.

13.1 Positioning

inference is the compute and model serving foundation base of the TUEO system, carrying three platform-level capabilities:

1. Unified management of heterogeneous compute: acceleration hardware from different vendors and models managed in one control plane, each pool operated independently;
2. Standard model serving: industry-standard model invocation, so existing applications connect with almost no changes;
3. Compute governance loop: models, deployments, training, quotas, usage, and audit in one control plane — costs always visible.

inference, identity, and engram are the three foundation bases. It is the unified entry point for model invocation across the whole system — products no longer each wire up their own model serving.

13.2 Core capabilities

13.2.1 Heterogeneous compute, one plane

Acceleration hardware from different vendors and models is managed in one control plane — each pool operated independently without interference, compute status transparently visible, without lumping heterogeneous resources into one.

13.2.2 Standard model serving, out of the box

Industry-standard model invocation, so existing applications connect with almost no changes — applications are unaware of the underlying hardware, and runtime differences are shielded.

13.2.3 Full model lifecycle management

End-to-end management of model onboarding, launch, upgrade, scaling, and rollback — running services stay stable and uninterrupted, every change controlled and reversible.

13.2.4 Model training as managed tasks

Fine-tuning and training run as managed tasks on the same platform as online serving, with visible progress — no more ad-hoc scripts, training outputs uniformly archived.

13.2.5 Access governance · quotas · audit

Who can call, how much they call, and how much it costs, all wired to identity and permissions — every invocation attributable, metered, and auditable, costs always visible.

13.2.6 Offline delivery · on-site acceptance

Fully offline installation, upgrade, and rollback, with on-site diagnostics and acceptance — deliverable even in air-gapped environments, compute capability lands with confidence.

13.3 Differentiation

• Compute enters the data center too: not just applications deployed in the customer’s data center, but model serving and inference as well — data and models make zero outbound calls;
• Heterogeneous honesty: different hardware stays in separate pools, never masquerading as a unified resource pool, compute status transparently visible;
• One closed loop: models, deployments, training, quotas, usage, and audit in one control plane — verifiable, observable, and reversible;
• Consumed by every product: the AI applications of cohort and studio call models through it, and engram’s knowledge Q&A draws its compute from it.

14. The complete journey of one invocation

From a single sentence to controlled real execution, the complete journey of one work order:

① A person in a cohort group chat: @engineering AI "help me fix this bug"
   ↓ coordinator routing (server-side responsibility scoring + LLM arbitration + audit)
② The AI development team triages: intent recognition → DoR (AI self-supplements reproduction steps) → TriageService dispatch
   ↓ passport gate + hard tool-allowlist validation
③ Work-order state machine: triaged → spec → plan → coded → reviewed → tested → merged
   ↓ coding execution (executor sandbox / local pairing)
④ The engine really modifies code, really runs tests, really commits; visual self-verification
   ↓ MR opened by cohort via the GitLab API → Code Review → Merge gate
⑤ Results written back to the work order, fed back to the session thread; AI retrospective written into long-term memory

End to end, identity authorizes, capabilities governs (if third-party capabilities are invoked), executor / the engine isolates, and audit leaves traces — the stronger the AI, the clearer the boundaries.

15. Cross-product design principles

TUEO is not a collection of products each minding its own business, but a system with a unified design philosophy:

Production/consumption dichotomy is the most central architecture decision of the whole system: who holds “the truth of a capability” (capabilities) vs. who merely “consumes capabilities” (cohort / studio) — no boundary-crossing, no parallel worlds.

SSOT convergence is the second core of the whole system: org directory → identity, AI employee names → identity, AI employee job profiles → the registry, capabilities → capabilities, messages → cohort, execution → executor, orchestration → studio, delivery → console. Every boundary has a single source of truth, eliminating the “two copies in two places, slowly drifting apart” root cause of defects.

16. Security and compliance system

16.1 Defense in depth

16.2 Provable audit

• identity: per-tenant SHA-256 contentHash + prev_hash hash chain; tampering (insertion / deletion / reordering / row edits) is detectable;
• cohort: 20 audit event categories collected server-side + queryable / retainable / archivable in the admin web console;
• studio: run-trace event log (append-only) projecting audit, with every entry “replayable” back to the execution trajectory;
• capabilities: first-class immutable audit tables (migrations grant only SELECT + INSERT; tamper-proof);
• executor: full-operation audit + CloudEvents event emission.

16.3 Multi-tenant isolation

A unified platform-wide model: identity’s token states the tenant → RLS physically isolates in each product → fail-closed (no tenant → reject). One system can serve multiple tenants / departments with zero leakage between tenants.

17. Private and offline delivery

17.1 Delivery forms

• Offline bundle + license: the whole system is packaged into an offline bundle, activated by a signed License, supporting fully disconnected operation;
• Built-in k3s: no dependency on the customer’s existing K8s cluster; can also manage a dedicated namespace in the customer’s existing cluster;
• Single-domain appliance: one external domain + path routing, all products same-origin, one session over standard OIDC;
• Data never leaves the enterprise: models go through the customer’s own managed gateway / local models; keys never leave the customer network; fully auditable.

17.2 Air-gapped supply chain

• Reproducible CI: two-layer immutable offline images, zero-network builds, signed with SBOMs;
• Controlled updates: .tueoupdate signed packages (Ed25519 verification + preflight compatibility gate + catalog-segment forwarding); unsigned packages are rejected;
• Offline activation: signed License activates with zero network access + soft node lock deploymentId.

17.3 Operations accessibility

One entry point to operate all services + middleware: configuration / logs / status / deployment / backup / upgrade / audit, all in one interface of the operations platform. Data ports are never exposed; heavy operations use on-demand temporary secure tunnels.

18. Applicable scenarios and customer value

18.1 Target industries

Industries with high complexity, high governance, and high-realtime collaboration: manufacturing (contract fulfillment), finance (risk-control processes), healthcare (sensitive collaboration), government, public security, energy, logistics, retail, education, legal.

18.2 Typical customer profiles

• Primary: mid-to-large enterprises that already have digital systems and want AI to enter organizational operations; enterprises that already have AI but lack execution / security / recovery layers;
• Secondary: department-level customers who want to pilot an enterprise AI platform.

18.3 Customer value

19. Current status and roadmap

The following is the status as of August 2026. All ten products are in production operation; capabilities still under continuous iteration are marked after the corresponding product entry.

19.1 Verified end-to-end closed-loop capabilities

The following capabilities have been verified running in real environments and can be confidently presented externally:

• AI development team dogfood loop: work order → Passport gate → LLM triage → real coding → LLM review → real GitLab CI → automatic failure repair → real merge → automatic deployment → liveness check → rollback. TUEO develops its own 5 code repositories with its own 8 AI employees;
• AI operating legacy systems: the ai-ops operations AI integrates via MCP, carrying alerts / inspections / capacity care / local multi-step execution plans, assisting traditional system operations;
• Capability coordination (System-as-Capability): connecting existing systems such as OA / ERP / CRM / MES into capabilities that AI can invoke, authorize, audit, and meter, fused with the capability-platform gateway;
• studio orchestration engine: 11 node types + event sourcing + durable pause-resume in production, serving as the orchestration heart of the intelligent-foundation definition layer;
• Capability-platform consumption convergence: cohort / studio both consume the capability platform via SDK / S2S (installation gate / paywall / scope gate / credential injection); consumption sides no longer connect directly to the execution base.

Milestone: private delivery is the constitutional main line; all ten products are in production operation; the AI development team developing TUEO with TUEO’s own products (dogfood) is now the norm; the intelligent foundation’s complete closed loop (definition → development → testing → production → operations → capability reuse → coordination) has been proven in a real environment.

Appendix C · Glossary

TUEO — making AI a full-time employee of your organization.