A business tool should explain what it can do, who can do it, and what happens when something goes wrong. Here is the current product boundary.
The public demo is a simulation. It uses fictional Aster Studio data and browser-only calculations. It has no database credentials, model calls, Python execution, or customer information. Its temporary state resets on reload.
Access belongs to an organization.
Application data lives in Convex. Backend operations check active organization membership and role. Knowing a resource ID or selecting an organization does not grant access.
Viewers inspect authorized workspace information.
Editors can work with datasets and refresh approved calculations.
Administrators manage source configuration, pairing, business context, and exact calculation approval.
Roles describe capabilities within an organization. They are not a promise that every workspace activity is visible to everyone: analysis request histories are private to their initiator.
Your source credentials stay on your site.
The customer-side bridge uses locally configured credentials. An administrator pairs it to an approved connection with an expiring, revocable token. The bridge sends validated snapshots into the workspace; importing data is an explicit transfer to the application.
PostgreSQL, MySQL, SQLite, and folders have runnable bridge adapters. Other entries in the connection catalog are planning interfaces. Intended-use labels are context, not a separate access-control system after import.
A refresh must earn its place on the dashboard.
Dataset bytes and calculation definitions have immutable versions and fingerprints. An administrator approves the exact calculation version before it can run. A refresh pins its inputs, uses a bounded background workflow, and validates the result before publication.
Invalid results leave the last successful KPI intact. Cancellation and changed approvals prevent late work from publishing. This protects result publication; cancelling a workflow does not imply that an already running external process has instantly stopped.
Evidence over invisible activity.
Calculation history shows its dataset and definition versions, outcome, failure category, and available execution provenance. Authorized detail views can include business results. Metadata export excludes raw datasets, calculation code, model prompts, tool payloads, and credentials.
Reported model tokens are operational information, not an invoice or billing ledger. Stored evidence can show which inputs and code produced a value; it does not prove that a business definition is the right one.
Deployment is part of the security boundary.
Analysis needs a configured model and an independently deployed Python executor. Production isolation requires a tested runtime with filesystem, network, resource, and tenant boundaries. Local Docker checks do not certify a customer’s deployment.
The public demo needs none of these services. This page describes repository behavior and boundaries, not an independent security certification, uptime agreement, or compliance claim.
Autonomy is a future responsibility.
Self-improving skills, autonomous recovery, external outreach, billing, and license provisioning are not enabled. Future agents need explicit capabilities, immutable versions, evaluations, human approvals, and revocation. A planned capability cannot grant itself permission.
Conversation generation remains request-bound. Background calculation refreshes have a separate, implemented workflow lifecycle; they do not make every conversation resumable.