Status: stable — public version of the canonical 0.8.0 platform object model (concept freeze), as amended on 2026-07-28. Section 6 lists what is frozen and what is deliberately open; open decisions must not be closed by inference from this page.

Platform Object Model

This is the public version of the Xtrape 0.8.0 object model — the vocabulary the rest of this site, and future public repositories, use consistently.

Amendment 2026-07-28. The execution unit a Service uses is named Worker; the earlier term Runner is retired and must not be reintroduced. Four previously open questions were closed at the same time: Service Instance is not an independent entity (it is the Worker); Replica is the technical-domain synonym of Worker, never a second object; Capability is exactly the grouping of Actions; and the Platform topology cardinality is recorded below. Outside this object model, runner keeps its ordinary meaning — a CI/CD runner is an unrelated homonym.

1. Platform boundary

Xtrape is a shared platform for tools that choose to connect to a common management and governance plane instead of each building an independent one. The Platform supplies broadly reusable mechanisms: registration and discovery, lifecycle governance, controlled interaction, policy and authorization mediation, credential references, and audit/event infrastructure.

The Platform must not absorb business-specific behavior. The boundary test:

If a function requires domain/business knowledge, or is not broadly useful to a large population of unrelated Widgets and Services, it belongs outside the Platform.

The Platform is a concept; implementation repositories (such as the Community Edition platform runtime) carry it but do not define it.

2. Concept map

Xtrape Platform
  |
  +-- Interaction Layer
  |     +-- Panel                    web operator UI
  |     +-- Exposure                 AI-facing disclosure (Xtrape Exposure)
  |     |     +-- Exposure Task
  |     |     +-- Skill references   (Skill is an Artifact)
  |     |     +-- Task Template      (structure within a Task; not an Artifact type)
  |     |     `-- MCP                protocol projection
  |     +-- Telegram / Channels
  |     `-- future interaction products
  |
  +-- Artifact Repository
  |     `-- Artifact
  |           +-- Widget --start/deploy--> Service --has--> Worker
  |           +-- Skill
  |           +-- Component
  |           +-- Script
  |           +-- Snippet
  |           `-- Source Code
  |
  +-- Execution semantics
  |     +-- Service --provides--> Capability --groups--> Action
  |     +-- Command --requests--> Action
  |     `-- Event --records--> fact
  |
  `-- Governance
        `-- Participant model        (taxonomy open)

Do not add Agent, Installed, Package, Instance, Replica, Runtime, Gateway, or Store as parallel top-level concepts to preserve legacy wording.

2.1 Topology cardinality

Interaction Layer  n : 1  Platform
Platform           1 : n  Service
Service            1 : n  Worker

Many interaction products face one Platform; one Platform holds many Services; one Service holds many Workers. This states logical object cardinality only — it prescribes nothing about the Platform's process count, clustering, or replication, which remain open (section 6). The n : 1 on the first row describes the object model, not a claim that a Platform may never federate; Platform-to-Platform is a separate future model.

3. Interaction Layer

The Interaction Layer covers the products through which users, AI systems, and external tools reach the Platform: Panel, Exposure, Telegram / Channels, and future interaction products. They are parallel siblings, and none of them owns independent copies of registry, repository, authorization, or runtime state — they consume shared Platform foundations.

• Xtrape Exposure is the AI-facing capability-disclosure product. It composes Exposure Tasks, references to Skill Artifacts and Task Templates, and protocol projections — MCP being the first. Exposure is one interaction product, not the umbrella for the others.
• MCP is a real protocol, placed under Exposure as one projection — not parallel to Panel or Telegram, and not a Device.
• Xtrape Exposure (the product) is distinct from Controlled Exposure (the platform-wide authorization/visibility governance mechanism — see Controlled Execution). Both use the word "exposure"; they are different layers.

4. Artifacts, Widgets, Services, Workers

Artifact is the umbrella term for reusable, creatable, referenceable, potentially distributable work products. Current types: Widget, Skill, Component, Script, Snippet, Source Code. Being an Artifact implies neither runnability nor publication nor deployment.

Widget is the deployable/runnable Artifact type: it defines a complete runnable tool and the information required to start and govern it. Review, signing, publication, and admission are lifecycle states applied to a Widget — not part of the type.

Service is what a Widget becomes when started or deployed: a running, configured, governed capability. A Worker is the execution unit a Service uses to perform work.

Widget --start/deploy--> Service --has/uses--> Worker

The model is exactly three layers — Widget, Service, Worker. There is no fourth "role" or "actor" object: the user-visible execution role is the Service. The two viewpoints differ and both are correct — to a user a Service presents as the execution unit; to the system it is a logical grouping and task entry point, and its Workers do the executing. Replica is the technical-domain synonym for Worker (a deployment descriptor's replicas: 3 reads naturally), never a second object.

How a Service comes into existence. The Platform issues a registration token; a Worker starts and connects with it; the first Worker to complete registration causes the Platform to create the Service; every later Worker presenting the same token joins that same Service. So a Service is a set of Workers sharing one registration token, and a Worker exists before its Service does. The arrow above is therefore a lifecycle outcome, not an ordering: starting a Widget results in a Service, but no Service object is created first and then starts Workers. Service Instance is not an object between the two — the registered running instance is the Worker.

Connector is a core platform component that bridges an external runtime, environment, or system into Xtrape — alongside Panel and Exposure it is part of the platform's own component set, not an entry in the Artifact classification. A Connector is not an AI agent, not a Service peer, and not automatically runnable by itself.

The Artifact Repository stores, organizes, versions, discovers, and distributes Artifacts. It may reference or index material living in external code hosts, package registries, or image registries — it does not replace them. Repository membership implies neither authorship, ownership, installation, runtime state, mandatory review, nor payment.

Artifact navigation uses three views: Repository (discoverable), Mine (obtained or manageable by the current account), and Created (authored; a subset of Mine). "Installed" is deliberately not a concept: obtained maps to Mine, authored to Created, running to Service.

5. Capability, Action, Command, Event

Service
  `-- Capability            semantic grouping
        +-- Action          concrete named operation / affordance
        `-- Action

Command --requests--> Action     (intent)
Event   --records--> fact        (what occurred)

• Capability — exactly the grouping of Actions a Service provides, and nothing more: Service → Capability → Action. It is a semantic grouping boundary, not an independent runtime object — it is not invoked, has no lifecycle of its own, and is not a second name for Service. Anything that executes is an Action reached through a Checkpoint and performed by a Worker.
• Action — a concrete named operation under a Capability; the granularity at which authorization applies.
• Command — a concrete request expressing intent to execute an Action.
• Event — a fact or state change recorded after something occurred. Command expresses intent; Event records fact.
• Checkpoint — the governed, versioned execution boundary through which an Action's externally governed execution is exposed. Published Checkpoint versions are immutable.

6. Frozen vs open

Frozen in the 0.8.0 concept baseline: the Platform as top-level shared governance concept; the Interaction Layer with Panel/Exposure/Telegram as parallel products; MCP under Exposure; the Controlled-Exposure/Xtrape-Exposure distinction; Artifact as umbrella with the six current types; Connector as a core platform component (not an Artifact type); Widget → Service → Worker, exactly three layers, with the Service as the user-visible execution role and one registration token shared by a Service's Workers; Service Instance not being an independent entity; Worker and Replica as two registers of one thing; Capability as exactly the Action grouping; Capability/Action/Command/Event semantics; the topology cardinality in section 2.1; Repository/Mine/Created views; and the removal of Installed, Agent (as a top-level object), Asset (as work-product umbrella), Store, and Runner.

Deliberately open (not to be inferred from this site): Connector's exact placement in the platform component topology (Connector is a core platform component; it is not an Artifact type); the Participant taxonomy and authorization hierarchy; the complete Panel information architecture; Workflow placement; package/manifest wire representation; Checkpoint migration details; scheduler, cluster, and deployment topology — including how many Workers run, where, and under what placement policy, and the process/cluster dimension of Platform deployment (the section 2.1 cardinality is logical only); the Chinese rendering of Worker; and physical repository/package rename mechanics.

Closed since the 0.8.0 freeze, recorded so that no reader reopens them by citing an older revision:

Decision	Was	Now
Runner vs Worker as execution unit	frozen on Runner	frozen on Worker; Runner retired
Service vs Service Instance	open	Service Instance is not an entity; it is the Worker
Worker vs Replica	open	two registers of one thing; Worker is the formal name
Capability's status	open	exactly the Action grouping; not a runtime object

See the Glossary for per-term definitions including retired vocabulary.