A shared catalogue is the reason to evaluate iii
iii asks teams to describe capabilities as workers, functions, and triggers. A worker registers with the engine; a function is a named unit of work such as orders::validate; a trigger describes what invokes it. The pinned README lists direct calls, HTTP endpoints, cron schedules, queue subscriptions, state changes, and stream events as trigger examples.
According to that README, workers join a live catalogue, other workers receive notifications, and applications and agents use the same function calls. This is a useful model to evaluate when several teams need a common way to expose capabilities. Claims that it removes integration work remain the project's claims. Our run did not measure integration effort, development time, or savings.
The engine is written in Rust, and the README lists SDKs for Node.js, Python, Rust, and Go. It distinguishes engine-owned workers from standalone Compose workers: HTTP, cron, queue, state, pubsub, and bridge belong to the latter group. Describing all of these as built into the engine would obscure what an operator must assemble.
What our recorded run established
Our stored run is dated 2026-10-10 at commit 5c000f86745ce81db5336b13b54f1cc724f3e79f. No new execution was performed for this correction. The recorded configuration specifies 3 CPUs, 8 GB of memory, and the image label lab-node:22. The command output identifies the actual Node runtime as v20.20.2 and pnpm as 10.19.0.
Dependency installation exited 0 after 13.676 seconds, rounded to 14 seconds in the summary. The parser records 926 packages and 1,250 MB of dependency storage; pnpm reports 925 packages added. Neither figure establishes unique dependency coverage, installed engine availability, or passing tests.
The build command exited 1 after 2.743 seconds, rounded to 3 seconds. Its explicit error was docs:build: sh: 1: mint: not found. Turbo reported 0 successful tasks out of 6. Other workspace lifecycle failures in that tail do not establish six independent product defects.
The test command exited 1 after 2.473 seconds, rounded to 2 seconds, while running build prerequisites. It encountered the same missing mint executable. The supplied output contains no individual test results, so whether iii's tests pass remains unestablished by this run.
The website also warned that it requires Node >=22.12.0. That mismatch needs attention when reproducing the workspace commands, but the log does not establish that it caused the missing-executable error. Installing dependencies successfully did not complete the development environment.
The repository scan records 3,457 files, approximately 403,488 source lines, 161.7 MB of checkout storage, and 29 CI workflow files. It detected workspaces but no Dockerfile, Compose file, or top-level tests directory. These are scan observations, not exhaustive statements about supported deployment methods or test locations. There is no supplied installed-binary check, engine build result, measured application workload, or audit result.
Keep the checkout, release, and documentation scopes separate
The supplied release page documents iii 0.22.1. Its change list includes queue configuration restoration at boot, PATH-first binary resolution, RabbitMQ dead-letter inspection channel isolation, sandbox fixes, and observability trace startup fixes. These are release-note statements, not fixes we independently exercised.
That release is not the identity of our measured October checkout. The raw build output includes SDK package version 0.24.6-rc.3, while the supplied documentation landing page displays 0.25.x. Neither establishes the installed engine version because our run contains no installed-engine version check. Advice drawn from these sources must therefore retain its source scope.
The existing example iii worker add should not be treated as the pinned README's current worker-addition instruction. That README instead shows iii trigger -n dev compose::add worker=queue for a running Compose daemon. Before following setup instructions, use documentation that matches the engine and workers you intend to run.
The console described in the pinned README inspects workers, functions, triggers, queues, traces, logs, and live state. We did not start it or verify those views. Likewise, the README describes agents adding workers and discovering functions at runtime; our run did not exercise agent behavior.
Licensing and recovery need separate decisions
The pinned README assigns Elastic License 2.0 to the engine runtime and Apache License 2.0 to the SDKs, CLI, console, documentation, and website. An Apache-licensed SDK does not establish that the engine meets an organization's licensing policy. Review the engine terms for your intended use before committing to the architecture.
The supplied open-issues extract lists reports about RabbitMQ consumer recovery (#1958), an invocation remaining unacknowledged without a dispatch timeout (#1927), and a subscriber-lag warning feeding itself and filling disk (#2072). It also lists trigger-registration and reconnect reports. These are reported behaviors with potentially different version and environment scopes. The issue listing alone does not establish their reproducibility, root causes, or applicability to the measured commit.
Use those reports to choose evaluation cases: disconnect a worker during an invocation, exercise the queue recovery behavior your application needs, and observe logs during subscriber lag. These are proposed next steps, not tests we performed. The issue requesting a private vulnerability-reporting channel does not itself establish a security vulnerability.
Choose by the capability you need
Dapr's supplied README describes a sidecar exposing capabilities through HTTP and gRPC, including service invocation, state management, messaging, and workflows. Evaluate it when that sidecar API model fits your applications. Temporal's supplied README describes resilient workflow execution with automatic handling of intermittent failures and retries. Evaluate it when durable workflows are the central requirement. Neither alternative was benchmarked in our run.
For iii, the useful next step is a small evaluation with a pinned engine and selected workers. First satisfy the documented environment requirements and verify the installed binary. Then exercise one real function and trigger path, followed by the relevant recovery cases. A monorepo dependency install cannot answer those deployment questions.
How to read the scores
Scores describe the supplied evidence, not a certification of product quality. On this five-point rubric, 1 means little usable support for the criterion, 2 means limited support with major verification gaps, 3 means a documented basis for evaluation, 4 requires broader corroboration, and 5 requires extensive verified evidence. Unknown adoption or compatibility does not earn a high score.
Setup receives 2 because dependencies installed but workspace commands stopped before a complete build or test result. Documentation receives 3 because the supplied material explains the model, SDKs, worker split, and licensing, while the setup path was not validated. Community receives 2 because release contributions and issue activity are visible, but adoption and support responsiveness were not measured. Maturity receives 2 because release history is supplied, while our evidence does not establish deployed reliability.