TLL OS Protocol 2.0

Overview

TLL OS is not a web framework. Not a CMS. Not an ecommerce platform. TLL OS is an AI-Native universal application development protocol — a shared language that humans and AI Agents can both read, understand, and execute.

This specification defines the core concepts, contracts, models, and evolution rules of TLL OS Protocol 2.0. Runtime implementations may vary, but all must follow this protocol.

Core Principles

1. Application Graph is the primary source of truth

The Application Graph is a machine-readable description of an application's structure, capabilities, dependencies, and relationships. It is the primary source of truth — not the only one. Complex algorithms, UI pixel-level implementation, third-party library usage, and low-level optimizations naturally live in code and are not forced into the Graph.

2. AI Agents are first-class citizens

Traditional: Developer → Code → Framework → Application. TLL OS: Developer + AI Agent → TLL OS Protocol → Application → Module / Plugin / Adapter / Tool. Agents can understand applications, discover capabilities, select components, design implementations, test and fix, build and deploy, and discover and propose changes.

3. Don't reinvent the wheel

TLL OS controls protocols, lifecycle, extension models, permission models, application models, and agent protocols. TLL OS does not control every low-level implementation. HTTP → Fastify, Database → Drizzle, Validation → Zod, Queue → BullMQ, Logging → Pino, Testing → Vitest.

4. Protocol and Runtime are separate

The Protocol is a stable specification. The Runtime is an implementation — there can be multiple, they can be rewritten, they can be replaced. Even if the Runtime is completely rewritten, applications and Agents following Protocol 2.0 remain valid.

5. Global extension and evolution

TLL OS allows global developers and Agents to jointly discover, validate, and contribute improvements. The Evolution Protocol (TEP) defines the complete flow from "discovering a problem" to "merging into the protocol."

Five Models

Protocol 2.0 consists of five interconnected models:

17 Core Contracts

Application Graph

The Application Graph is the machine-readable map of an application. It describes what the application has, what it can do, what it depends on, and how things relate.

Node Types (17)

application, module, plugin, adapter, api, model, event, workflow, agent, tool, skill, permission, capability, build_target, config, command, dependency

Edge Types (15)

belongs_to, depends_on, provides, calls, triggers, requires, uses, extends, conflicts_with, listens_to, implements, exports, imports, builds_for, maps_to

Agent Development Model

Agents operate through a standard development loop:

Requirement → Understand (read Graph) → Select Capability → Select Module/Plugin/Adapter → Design (Graph nodes) → Implement (Projection → code) → Test → Discover issues → Fix → Verify → BuildTarget → Deploy

Agent Capability Levels

Ecosystem Model

The ecosystem model defines how external systems connect to TLL OS and how capabilities are discovered.

Adapter

Adapters connect external systems, mapping external concepts to/from the Application Graph. They support read, write, sync, and migrate operations. Migration is a first-class operation — the most valuable capability of an Adapter is migrating from an external system to native TLL OS modules.

Compatibility Manifest

Each Adapter carries a Compatibility Manifest that declares: supported system versions, which capabilities can/cannot be mapped, migration cost, dependencies, and compatibility level (production / beta / experimental / deprecated).

Capability

Applications declare what they can do through Capability nodes. Agents query the Capability Registry to discover available capabilities. Capabilities are provided by Modules, Plugins, or Adapters.

Build Model

Projection

Projection defines how the Application Graph projects to different output forms: code, OpenAPI, database schema, config, docs, tests. Projection is bidirectional — Graph can generate code, and code changes can sync back to the Graph.

BuildTarget

BuildTargets define the output platforms: web, h5, apk, exe, miniprogram, ai_agent, industrial, iot, cloud, edge. Each BuildTarget has a capability matrix declaring which capabilities are supported. TLL OS defines the contract — web/API is the first reference implementation, other targets are implemented by the community.

Evolution Model (TEP)

The TLL Evolution Protocol defines how the protocol and runtime evolve:

Discover (bug/optimization/new capability) → Evolution Proposal → Auto-generate ChangeSet → Auto-test → Compatibility verification → AI Review → GitHub PR → Maintainer review → Merge → Protocol/Runtime Release

TEP types: feature, bugfix, breaking, deprecation, refactor. Breaking changes require TEP + RFC + migration guide.

Versioning & Compatibility

• Protocol version: 2.x (stable). Breaking changes require Protocol 3.0.
• Runtime version: 0.x (evolving). Runtime 1.0 is the first production-ready release.
• Contract status: stable / beta / draft / deprecated.
• Deprecation: deprecated contracts remain for 2 MINOR versions.
• LTS: Every 4th Runtime MINOR is selected as LTS, supported for 12 months.