Implementation Status Matrix

This document provides a comprehensive overview of which protocols from @objectstack/spec have been implemented in the ObjectStack packages.

Status Legend

---

Core Infrastructure (Kernel)

Runtime & Kernel

Notes:

• Core package provides complete microkernel implementation
• Plugin system supports the init/start/destroy lifecycle, dependency resolution, and service injection — the onInstall/onEnable-style hook family was retired in v17 as never-implemented (#4212)
• Event bus enables inter-plugin communication; IPluginLifecycleEvents registers the 14 lifecycle events that actually fire, and LifecycleEventName soft-types hook/trigger (#4241)
• ObjectQL serves as the example kernel — a reference implementation that will be modularized into plugins

Data Infrastructure

Notes:

• ObjectQL implements complete IDataEngine interface
• Memory driver is the reference implementation: filters, sorting, pagination, aggregations, snapshot transactions, streaming and syncSchema() are on; joins, window functions, subqueries, full-text and vector search are off (InMemoryDriver.supports)
• Advanced query features (joins, window functions, subqueries) require production drivers
• Memory driver supports aggregations (groupBy, count, sum, avg, min, max)

Metadata Framework

• Metadata API (list types, list items, get item) is fully functional
• Metadata is loaded from config files or dist/objectstack.json at startup and held in memory
• MetadataPlugin auto-provisions the sys_metadata / sys_metadata_history storage objects (plus the ADR-0067 commit log and the metadata audit trail) by default, so PUT /api/v1/meta/{type}/{name} always has somewhere to write. Per-project (cloud) kernels opt out with registerSystemObjects: false, because there the control plane owns those tables
• MetadataPlugin does not auto-bridge ObjectQL to a DatabaseLoader — there is no automatic runtime project-DB bridge, and nothing in the packages calls the bridge during boot. Database-backed metadata is an explicit MetadataManager opt-in (setDataEngine() / setDatabaseDriver(), or a datasource + driver pair on the manager config), and even then it is control-plane only: both methods return early whenever an environmentId is supplied, so a per-project kernel never gets a database-backed metadata loader
• The artifact source is artifactSource: { mode: 'local-file', path } — a compiled artifact read from a filesystem path or fetched from an http(s) URL (the control plane's public /pub/v1/environments/:id/artifact[?commit=…] route serves exactly such URLs), honored by all three bootstrap modes (eager / lazy / artifact-only). A second artifact-api mode (a Bearer-authenticated control-plane pull) this page once called "Future / reserved" was removed while resolving #4246: it had zero consumers in any repo — the cloud runtime uses its own ArtifactApiClient, and package installs into a running OSS instance go through @objectstack/cloud-connection — and a still-configured artifact-api source now fails loudly at start() instead of lingering half-declared
• Future: durable local artifact cache — remote artifact URLs re-fetch on every boot

System Services

---

Data Layer (ObjectQL)

Core Data Modeling

Field Type Support:

Query Engine

Notes:

• Full query protocol is defined and implemented in ObjectQL engine
• Actual query capability depends on driver implementation
• Memory driver covers filters, sorting, pagination and aggregations; joins, window functions and subqueries are off
• Client SDK provides query builder utilities (QueryBuilder / FilterBuilder, createQuery / createFilter)

---

API Layer (Transport)

HTTP & REST

The data (/api/v1/data), metadata (/api/v1/meta), discovery (/api/v1/discovery), and batch endpoints are implemented in @objectstack/rest (rest-server.ts — registerDiscoveryEndpoints); @objectstack/runtime re-exports RestServer from that package and provides the underlying HTTP server/dispatcher.

REST Endpoints Implemented:

Every route carries the /api/v1 prefix. When project scoping is enabled each row is additionally mirrored under /api/v1/environments/{environmentId}. The full audited route list lives in packages/rest/src/rest-route-ledger.ts.

Advanced Protocols

---

UI Layer (ObjectUI)

View System

Notes:

• All UI protocols are fully defined in spec
• Metadata API can retrieve UI definitions (views, apps, pages, dashboards, reports, actions)
• Active Studio/ObjectUI source lives in the sibling ../objectui repo and is bundled into packages/console via the objectui refresh workflow
• Metadata-admin curated forms now merge server-only fields back into the save payload, so a Studio form that exposes only part of a metadata type should not strip newer protocol properties
• The 2026-05-08 → 2026-06-08 ObjectUI scan covered 910 non-merge frontend commits. The largest functional clusters were metadata-admin/Studio, master-detail forms, reports/dashboards, record detail/related lists, action transport, flow designer, developer/API pages, AI draft publishing, and i18n.
• React SDK provides data hooks; the cross-surface renderer is still being completed in ObjectUI rather than in this backend repo

---

Automation Layer

Notes:

• Hook system is implemented in ObjectQL (beforeFind, afterInsert, etc.) — this is data-layer eventing, not workflow automation
• The flow/workflow engine ships in @objectstack/service-automation (engine.ts, builtin nodes, plugin.ts); approvals, webhooks, and triggers ship as @objectstack/plugin-approvals, @objectstack/plugin-webhooks, @objectstack/trigger-api, @objectstack/trigger-record-change, and @objectstack/trigger-schedule
• ETL and Sync protocols are defined but not yet implemented as plugins
• Discovery API reports automation service as unavailable until a plugin is registered

---

Security Layer

Auth Service (plugin-auth)

CoreServiceName names a single auth service — there is no permission entry in that enum. Authentication/identity is what @objectstack/plugin-auth registers under that name. Authorization is registered outside CoreServiceName: @objectstack/plugin-security registers security (plus security.permissions, security.rls, security.fieldMasker) and @objectstack/plugin-sharing registers sharing, sharingRules, and shareLinks.

Notes:

• Security is delivered by three cooperating plugins, not one: plugin-auth (identity, auth + tenancy services), plugin-security (permissions, FLS, RLS, tenant wall), and plugin-sharing (OWD, sharing rules, per-record shares, share links)
• Client SDK supports bearer token header — but token validation requires the auth plugin
• Auth route (/auth/*) only appears in Discovery when the auth plugin is registered
• Fine-grained authorization (RLS, sharing) lives in plugin-security / plugin-sharing, not in the auth plugin. Territory-style access is expressed as an RLS dynamic-membership set (ExecutionContext.rlsMembership, e.g. id in current_user.territory_account_ids) rather than as a dedicated territory module
• Phase-1 RBAC enforcement is live end-to-end: REST → ObjectQL → SecurityPlugin middleware now receives a populated ExecutionContext (userId, tenantId, positions, permissions). Tenant isolation is enforced as a Layer 0 tenant wall (plugin-security/tenant-layer.ts, ADR-0095 D1) that AND-composes organization_id == current_user.organization_id ahead of and independently of business RLS — the earlier wildcard tenant_isolation RLS policy on member_default was retired (an OR-merged business policy could widen it). The default member_default set still ships per-object overrides sys_organization_self (id == current_user.organization_id) and sys_user_self (id == current_user.id) for the global tables that lack an organization_id column. The earlier tenantField indirection (RLS expressions written against an abstract tenant_id column then rewritten to the configured physical column at compile time) was removed — the placeholder, the column name, and RLSUserContext.organization_id are now the same name end-to-end. The legacy objectql.registerTenantMiddleware (hardcoded where.tenant_id injection that pre-dated SecurityPlugin) has been removed; SecurityPlugin is the sole authority for tenant isolation. Analytics now uses the same reusable read scope via security.getReadFilter, so dataset-bound dashboards/reports do not bypass RLS. Verified cross-organization isolation on pnpm dev:crm across sys_organization, sys_member, sys_user, sys_user_permission_set, sys_position_permission_set. Anonymous traffic is always denied (ADR-0056 D2). The deployment-wide opt-out is gone: api.requireAuth was retired in @objectstack/spec 17 (#3963) and is now a tombstoned key that fails validation rather than reopening the data plane. The single decision lives in @objectstack/core (security/anonymous-deny.ts, 401 UNAUTHENTICATED), and every surface that legitimately serves a session-less caller derives its own narrow authorization from a declaration instead: control-plane paths via the auth-gate allowlist, public forms via publicFormGrant (ADR-0056 Option A), share links via a capability token validated then read as SYSTEM, book.audience: 'public' reads via the audience gate, and MCP via an OAuth token or API key.
• OWD / sharing-model enforcement is live and proven end-to-end (ADR-0056): private, public_read, public_read_write, and controlled_by_parent are enforced through plugin-sharing + plugin-security and verified by dogfood proofs over the real HTTP stack. object.sharingModel accepts the canonical OWD vocabulary only (private / public_read / public_read_write / controlled_by_parent) — the legacy read / read_write / full aliases were removed from the enum (ADR-0090 D4), and an unset sharingModel on a custom object resolves to private (ADR-0090 D1). RLS owner policies resolve current_user.email in addition to id / organization_id / positions (#2054). Permission sets may declare isDefault: true as the install-time suggestion to bind the set to the built-in everyone position (ADR-0090 D5, superseding the ADR-0056 D7 fallback-profile mechanism). A sharing rule must state its criteria (#3896): all three write paths reject a match-all shape, a stored criteria-less rule matches nothing, and its materialised grants are revoked on the next reconcile.

---

AI Layer

Notes:

• The @objectstack/spec/ai surface is deliberately narrow — Agent, Skill, Tool, Conversation, Model Registry, Embedding, Usage, MCP, plus the knowledge-source / knowledge-document and solution-blueprint schemas. Application-level protocols (DevOps agents, predictive pipelines, AIOps, orchestration plans, NLQ services, RAG-pipeline DSLs, budget enforcement) were removed in v1 and have no schema today — see the scope note in packages/spec/src/ai/index.ts
• The ObjectOS runtime ships agents, model registry, conversation, tools, skills, and an eval harness
• RAG/embedding is provided by @objectstack/service-knowledge plus the knowledge-memory, knowledge-ragflow, and embedder-openai plugins (all open)
• Token/cost accounting has a schema (ai/usage.zod.ts) but no shipping enforcement; the predictive and DevOps-agent protocols are not defined in spec at all

---

Integration Layer

---

QA & Testing

Features Implemented:

• TestSuite, TestScenario, TestStep schemas ✅
• HTTP adapter for testing ✅ (packages/core/src/qa/http-adapter.ts)
• QA runner in core ✅ (packages/core/src/qa/runner.ts)
• Conformance/dogfood harnesses in @objectstack/verify and packages/qa (dogfood, downstream-contract, http-conformance) ✅

There is no MSW package in this repo — browser API mocking is a devDependency of the sibling objectui frontend, and @objectstack/driver-memory is what backs those in-browser fixtures.

---

Implementation Roadmap

Phase 1: Core Infrastructure ✅ COMPLETE

• Microkernel & Plugin System
• Logging System
• Service Registry
• Event Bus
• API Registry

Phase 2: Data Layer ✅ COMPLETE

• ObjectQL Engine
• Schema Registry
• Protocol Implementation
• Basic Query Support
• CRUD Operations
• Hook System

Phase 3: API Layer ✅ COMPLETE

• REST Server
• HTTP Server (Hono)
• Endpoint Generation
• Discovery API
• Metadata API
• Batch Operations
• HTTP Caching

Phase 4: Client SDKs ✅ COMPLETE

• TypeScript Client
• React Hooks
• Query Builder
• Error Handling

Phase 5: Developer Tools ✅ COMPLETE

• CLI Tools
• Config Validation
• Development Server
• Metadata Management

Phase 6: Advanced Features 🚧 IN PROGRESS

• Production Database Drivers — @objectstack/driver-sql (PostgreSQL/MySQL dialects), @objectstack/driver-mongodb, and @objectstack/driver-sqlite-wasm ship; additional dialect coverage ongoing
• OData Support
• Realtime Subscriptions
• WebSocket Support

Phase 7: UI Layer 🟡 IN PROGRESS

• UI Renderer
• Studio metadata-admin engine — generic metadata list/detail/edit surfaces, live preview, draft/publish/rollback, create-mode forms, server-side diagnostics, package scoping, and skew-safe curated inspectors
• Form conditional rules — ObjectUI supports visibleWhen, readonlyWhen, requiredWhen, row-scoped inline-grid rules, and required-on-submit enforcement
• Master-detail forms — inline subforms, spreadsheet-style line items, atomic batch create/edit, lookup auto-fill, line ordering, duplicate/reorder, and subtotal/tax/total stack
• Record detail + related lists — derived related lists, record-page assignment, action slots, system/audit sections, and opt-in reference rail
• Dashboard renderer/editor — widget layout persistence, drill-downs, pivot/funnel/table/list widgets, type-aware cells, and per-widget dataset binding authoring (dataset, dimensions, values)
• Report renderer/editor — spec-native summary/matrix/joined reports, chart/KPI blocks, drill-downs, dataset-bound reports, and i18n labels
• Flow/page designers — typed flow node config panels, simulator/debug runner, page block canvas, slotted record pages, and schema-driven block inspectors
• Action transport — row/global/header actions, modal parameter collection, visible CEL, popup-safe open actions, and nested action runner sharing
• Developer/admin console surfaces — Integrations & APIs, public forms, flow runs, approvals inbox, settings, marketplace/package management, AI draft review/publish
• List View Renderer full protocol parity
• Cross-surface UI Renderer full protocol parity
• Theme Engine

Phase 8: Automation (Plugin) 🟡 IN PROGRESS

• Flow Engine Plugin
• Approval Node Plugin
• Trigger Registry Plugins — @objectstack/trigger-api, @objectstack/trigger-record-change, @objectstack/trigger-schedule (including the time-relative trigger)
• ETL Pipeline Plugin
• Sync Plugin

Phase 9: Security (Plugin) 🟡 PHASE-1 LANDED

• Authentication Plugin (@objectstack/plugin-auth, better-auth)
• Authorization Plugin — @objectstack/plugin-security enforces CRUD/FLS/RLS in the ObjectQL middleware chain; REST → ObjectQL now propagates ExecutionContext end-to-end (Phase-1)
• Row-Level Security — tenant isolation is a Layer 0 tenant wall (plugin-security/tenant-layer.ts, ADR-0095 D1) that AND-composes organization_id == current_user.organization_id independently of business RLS (the earlier wildcard tenant_isolation policy on member_default was retired); member_default still applies per-object overrides sys_organization_self / sys_user_self. The earlier tenantField rewrite indirection was removed: RLS column, placeholder, and RLSUserContext.organization_id use the same canonical name end-to-end. Policy enabled: false is enforced at the compiler choke point — a disabled policy no longer contributes its OR-branch grant (#3980) — and the void rowLevelSecurity[].priority key was removed in @objectstack/spec 17.0.0 (#3896 security audit)
• Analytics RLS bridge — @objectstack/service-analytics auto-bridges to security.getReadFilter(object, context) and fails closed when read-scope resolution cannot be safely applied
• Multi-tenancy — verified cross-organization isolation on pnpm dev:crm (Alice@OrgAlpha vs. Bob@OrgBeta only see their own records across sys_organization, sys_member, sys_user, and sys_*_permission_set link tables)
• Legacy objectql.registerTenantMiddleware removed — SecurityPlugin is now the sole tenant-isolation authority
• Organization-Wide Defaults / sharing model — private, public_read, public_read_write, and controlled_by_parent enforced via plugin-sharing + plugin-security, proven by dogfood over the real HTTP stack (ADR-0056). Canonical vocabulary only — legacy aliases removed from the enum (ADR-0090 D4); unset custom-object OWD resolves to private (ADR-0090 D1)
• Sharing Rule evaluator — criteria rules re-evaluated on afterInsert / afterUpdate (plugin-sharing/rule-hooks.ts); every authorable recipient maps 1:1 onto an enforced expandRecipient branch (plugin-sharing/sharing-rule-service.ts) — user, team, position, business_unit, and unit_and_subordinates (business-unit-subtree widening, ADR-0057 D5 / ADR-0090 D3). Under ADR-0078 enforce-or-remove, criteria is now the only rule type (owner-type rules were removed from the authoring surface because the static materialiser cannot track live membership), the group recipient was renamed to team, guest was removed, and queue stays reserved in the runtime contract but deliberately non-authorable
• Everyone-baseline suggestion — a permission set may set isDefault: true as the install-time suggestion to bind it to the built-in everyone position; resolved per-request as an additive baseline, no fallback cliff (ADR-0090 D5)
• Default-deny for anonymous traffic — the global default-deny landed (ADR-0056 D2) and the api.requireAuth opt-out was then removed in @objectstack/spec 17 (#3963): the key is tombstoned and rejected at parse time, the deny decision is centralised in @objectstack/core security/anonymous-deny.ts, and public forms self-authorize via publicFormGrant (Option A)
• Studio RLS visual editor
• Per-user×org permission cache
• Audit UI / denied-access logging

Phase 10: AI Integration 🟡 IN PROGRESS

• RAG Pipeline — @objectstack/service-knowledge plus the knowledge-memory, knowledge-ragflow, and embedder-openai plugins ship in this repo
• MCP surface — @objectstack/mcp exposes the platform to any BYO-AI client
• Agent Framework (ObjectOS runtime; not in the open-source framework)
• NLQ Engine (ObjectOS runtime)
• Model Registry (ObjectOS runtime)

---

Summary Statistics

Overall Implementation Status

Implementation Coverage

Implementation spans every layer of the platform. Core infrastructure, data modeling, the REST API, client SDKs, security (Phase-1), automation, AI, and integration all have shipping implementations. Remaining gaps are concentrated in specific protocols (OData, cross-surface UI renderer parity, ETL/Sync, the mapping/document/external-lookup data protocols, and a handful of governance and AI-cost services) rather than entire layers. Refer to the per-layer tables above for protocol-level status.

Core Functionality Status

---

Package Feature Matrix

The REST server, endpoint generation, and data/meta/batch endpoints are implemented in the @objectstack/rest package (not shown as a column above); @objectstack/runtime re-exports RestServer from it.

---

Next Steps