What our run establishes
Our run took place on September 27, 2026, at commit 5477f0e, using our lab-node:22 sandbox with 3 CPUs and 8 GB RAM. The attached harness records success flags, exit codes, elapsed time, timeout status and output tails for installation, build and tests. All three commands returned exit code zero without timing out.
The stored parser summaries report 391 passed, 0 failed and 0 skipped Vitest tests. These summaries do not establish exhaustive unique test coverage. The attached raw footer agrees with the stored passing count, but no new execution or complete-log reconciliation was performed for this correction.
The frontend test tail includes DOM-nesting and missing-i18next-instance warnings. Those warnings are not recorded test failures. Python tests were detected in the repository, but the supplied execution record establishes a Vitest run, not execution of the Python suite.
We did not test a model-backed analysis, database connector, desktop application, Python wheel installation or deployed service. The audit field is null, so dependency scan coverage is unknown. Command success provides grounds to continue evaluation; it does not verify chart accuracy or security.
The MrKeyoor testing methodology explains how command outcomes and parsed counts reach our reviews. That page provides provenance context; its current procedure does not establish which methodology version governed this older run.
Why branching matters for exploration
Data Threads let you branch from an earlier analysis step. The repository README describes explanations, tables and editable charts in one history, with results that can be refined or assembled into reports. This gives an analyst a practical reason to try the workspace: compare a new question with an earlier path without discarding that path.
That is a documented capability, not an outcome we exercised. For a useful next step, load a dataset whose totals you already know, ask a question you can verify independently, then inspect the resulting table and chart before branching into a second question. Treat that as your acceptance check, not as a reproduction of our build-and-test run.
Choose the deployment profile before sharing access
The development guide says to keep data connectors and custom models disabled for anonymous deployments. It explains that browser identities are client-provided and suitable for disposable demo workspaces, rather than durable credentials or sensitive server state. Its anonymous profile also uses ephemeral workspaces and hides configured API keys.
The documented authenticated profile uses verified identity and persistent storage. These are configuration instructions, not security properties verified by our run. Read the deployment guide against your hosting requirements before exposing the application to other users.
Generated Python introduces a separate isolation choice. The guide describes a local subprocess backend and a disposable Docker execution backend. It explicitly says the Docker sandbox is unsupported when the application itself runs inside a container. Running the application in Docker therefore does not establish that generated code uses the Docker execution backend.
Match the alternative to the work
LIDA provides an API for generating, executing, editing, explaining, evaluating and repairing visualization code. Choose LIDA when you need those operations inside an application you control. It also has an optional UI, so the distinction is its reusable API, not an absence of a browser interface. Its documentation warns that it generates and executes code.
Evidence creates reports in code using SQL and Markdown. Choose Evidence when the deliverable is a report maintained in code and published as a site. It can complement an exploratory workspace when you want to turn checked findings into a separate reporting artifact; that is a workflow choice, not a documented integration.
Apache Superset provides a SQL editor, a lightweight semantic layer, dashboards and configurable security roles. Evaluate Apache Superset when those BI capabilities define the requirement. Its documentation establishes their presence; it does not establish that Superset will fit your identity system or database configuration without evaluation.
Release scope and ratings
The supplied release page identifies 0.8b1 at commit 5477f0e as a beta. The README distinguishes the 0.8.0b1 preview package from stable 0.7. Our checkout results should not be presented as measurements of an unpinned stable-package installation.
The release notes include a change to gracefully degrade chart insights for text-only models. An older report of a generic chart-insight error is therefore insufficient evidence that the same behavior persists in the tested release. The supplied extracts also do not verify the current status of the earlier Ollama and semantic-layer issues, so this review does not use them as established limitations.
The retained ratings use a five-point editorial rubric: 1 means the evidence shows a blocking problem, 2 substantial obstacles, 3 a usable path with significant gaps, 4 a successful or well-documented path with material qualifications, and 5 strong evidence within the dimension's stated scope. Setup assesses the recorded developer setup; docs assesses coverage of setup and deployment instructions; community assesses visible contribution evidence, not adoption; maturity assesses release and test evidence, not production reliability. Unknown dimensions would remain unassessed. These ratings are judgments, not benchmarks or comparisons with the alternatives.