By default, Kotar stores your models locally in your browser, on your device.

Kotar uses browser-based storage and an in-browser model repository (Flexo) to manage your models. Model editing, parsing, validation, and other local modeling operations take place directly in your browser.

Your models are not automatically stored in a central Kotar server or cloud database.

You can explicitly choose to store or synchronize your models elsewhere, including:

• Local file system: Save or synchronize model files to a directory on your computer.
• Git repository: Commit and push model files to a remote GitLab repository.
• Remote Flexo repository: Connect to a remote model repository to share or manage model data.

Important: Browser storage is not a permanent backup. Clearing browser data or deleting the browser profile can remove locally stored models. Save or synchronize important work regularly.

Kotar processes and stores your models locally by default. Other websites and ordinary browser applications generally cannot directly access Kotar's browser storage because modern browsers enforce the same-origin policy, which isolates data belonging to different websites.

However, browser-local storage should not be considered a security boundary against all software running on your device.

• Other websites: Normally cannot directly read Kotar's browser storage.
• Browser extensions: Extensions with sufficiently broad permissions may be able to inspect page content, access model data exposed in the page, or intercept user interactions.
• Other applications on your computer: Depending on their operating-system permissions, local applications or malware may be able to access browser profile data or local model files.
• Other WebAssembly modules: Modules operating inside the same Kotar application runtime are not necessarily isolated from one another by separate security boundaries.

Kotar's browser-based architecture reduces the need to transmit model data to external servers, but local storage does not provide complete protection against malicious browser extensions, compromised devices, or unauthorized local access.

For sensitive models, use a trusted browser environment, restrict unnecessary extensions, keep your browser and operating system updated, and apply appropriate device and organizational security controls.

Kotar performs its core modeling operations locally in the browser. Once the application is loaded, editing, parsing, validation, and local repository operations do not inherently require communication with a remote modeling server.

However, some activities require network connectivity:

• Initial application loading: The browser must retrieve the Kotar application from its hosting server unless it is already available locally through a supported caching mechanism.
• Authentication: The authenticated server edition requires communication with the configured OIDC identity provider for login and relevant authentication flows.
• GitLab integration: Cloning, fetching, pulling, and pushing repositories require network connectivity.
• Remote Flexo repositories: Accessing or synchronizing remote models requires connectivity to the repository.
• Other remote services: Any explicitly configured cloud-based integrations require network access.

Kotar Community (static) has fewer network dependencies than Kotar Enterprise (authenticated server).

In summary: Kotar's local modeling engine does not require continuous network communication, but this does not guarantee that every deployment can be used completely offline. Offline operation depends on how Kotar was deployed, loaded, and configured.

Kotar does not automatically upload your model to a centralized Kotar model repository as part of normal local editing.

However, the browser and the deployed application may exchange different categories of data depending on the deployment and enabled integrations.

For Kotar Enterprise deployments, Git requests pass through Kotar's server-side Git proxy, which forwards them to the configured GitLab instance.

The server can also produce authentication-related logs and, when configured, send authentication telemetry.

The key distinction: Local model operations do not inherently transmit model data. Network transfers occur when delivering the application, authenticating users, accessing remote repositories, or using configured external services.

Kotar provides several ways to make locally managed models available to other applications, tools, and users.

1. Export or synchronize files to your computer

Save or synchronize model files to a local directory. These files can then be accessed using other applications, command-line tools, or external modeling utilities.

2. Use GitLab

With Kotar Enterprise (the authenticated server edition), connect Kotar to GitLab and commit and push your model files.

Other users and applications with appropriate repository access can then retrieve the files through standard Git workflows.

3. Use a remote Flexo repository

Where supported and configured, connect Kotar to a remote Flexo repository to make model information available through shared repository services and APIs.

4. Use Flexo APIs and OpenMBEE libraries

Kotar includes an in-browser Flexo model repository. In the browser-based Community and Enterprise editions, it can be accessed programmatically through supported interfaces inside Kotar, but it is not directly accessible to external applications. The downloadable desktop edition can support direct access from local tools through its available model interfaces.

OpenMBEE provides open-source libraries for working with model data and compatible repository APIs.

However, the in-browser Flexo instance is not automatically exposed as a network-accessible server. External applications require an explicitly supported integration mechanism, such as exported files, a remote repository, or an exposed API bridge.

In summary: Kotar keeps the working model local by default, while supporting explicit export, synchronization, and integration with external engineering tools and repositories.

Kotar's core modeling environment runs locally in your browser in both Kotar Community and Kotar Enterprise.

Model processing and normal file operations happen locally rather than on a central model-processing backend. Kotar Community is served as static web content; Kotar Enterprise additionally uses server-side services for OIDC authentication and GitLab operations.

The following diagram shows the deployment architecture. Components inside the Kotar boundary execute locally. Connections to enterprise services such as a remote Flexo repository are optional.

Kotar also supports direct access to files on your machine through the browser's File System Access capabilities.

This is different from web applications where the browser primarily acts as a front end and sends your content to a remote server for processing.

Kotar performs model editing, parsing, validation, visualization, and local model repository operations directly in the browser.

There are two deployment modes:

• Kotar Community (static edition): The application is delivered as static web content. Model processing and workspace operations run locally in the browser without requiring a Kotar application backend.
• Kotar Enterprise (authenticated server edition): Adds an authentication and Git integration service. User authentication is handled through OpenID Connect (OIDC), while GitLab repository operations are routed through a server-side Git proxy.

The authenticated server does not replace Kotar's browser-based model-processing architecture. However, authentication and Git operations involve network communication with the configured services.

Model data is not automatically uploaded to a centralized Kotar model-processing backend. When users explicitly perform Git operations or connect to remote engineering services, the relevant data is exchanged with those services.

Both editions support local, browser-based modeling without requiring a separately deployed Flexo repository.

See the User Manual for more information.

It is pronounced KOH-tar.

KOH sounds like the "ko" in Kodak, tar rhymes with "car" or "jar".

Kotar supports the browser's File System Access capabilities, allowing you to open and work directly with files stored on your local machine.

You can open a local workspace and work with its files directly from Kotar. The files remain normal files on your machine and are not uploaded to any external server.

To open a local workspace:

Open local folder > Allow Edits > Edit the Model > File/Save > Open from your local file system

Yes.

Files opened through local File System Access are normal files on your machine and can also be edited using other applications and development tools.

Changes made outside Kotar are supported, allowing Kotar to participate in normal local development workflows with tools such as:

• Git clients
• Other text editors and IDEs
• Scripts
• Command-line utilities

From a file-access perspective, Kotar therefore behaves much like a locally installed application: both Kotar and your other local tools can work with the same files.

No.

Granting Kotar access to a local file or directory allows the browser application to work with that file on your machine. It does not, by itself, upload the file to a remote Kotar service.

Remote communication only occurs when you explicitly use functionality configured to communicate with a remote service.

For normal file-based workflows, very little.

Kotar can access an explicitly opened local workspace through the browser's File System Access capabilities, and files can be modified both inside and outside Kotar.

The main difference is access to other local services. Because Kotar runs within the browser's security environment, connecting directly to arbitrary local services may require those services to be exposed appropriately.

Support for accessing local services through file:///-based configuration can also be added where required.

Kotar is designed so that modeling can be performed entirely locally, without sending model data to a WebIDE backend.

Kotar Community delivers the application as static web content. Kotar Enterprise additionally includes server-side authentication and GitLab integration. In both editions, the modeling environment, workspace, and local Flexo instance run in the browser. A desktop-installable version is also available.

However, technical data locality should not be confused with formal authorization to handle export-controlled or company-proprietary information.

Whether Kotar is approved for EAR-controlled data, proprietary information, or a particular security classification depends on the applicable organizational IT, cybersecurity, export-control, and deployment requirements.

For environments with specific security requirements, the desktop/local deployment can be evaluated and approved through the applicable organizational security process.

Yes.

Kotar includes a local, in-browser Flexo instance. This Flexo instance is private to the individual user and does not require a separately deployed Flexo server.

For enterprise collaboration, the Enterprise Edition can optionally connect to a remote, shared Flexo instance. This enables workflows such as:

• Cloning models from a shared repository
• Pulling model changes
• Pushing model changes
• Collaborating through a shared model repository

Using a remote Flexo instance is optional.

Kotar includes a local, in-browser Flexo instance. Its model repository is local to the user's environment and is not a shared remote repository.

The local Flexo instance provides model persistence and identity management while allowing Kotar to operate without a separately deployed Flexo server.

Note: The exact browser persistence/storage mechanism is an implementation detail and may change. Applications should interact with the model through the provided interfaces rather than depending on the underlying storage representation.

No.

Git can be used for source-based model management without Flexo.

However, Flexo provides additional model repository capabilities, including persistence of model identities and graph-based model information.

Kotar therefore supports a hybrid configuration-management approach in which Git and Flexo work together.

Every valid model can be automatically committed during editing, providing fine-grained ("micro-commit") model history while Flexo maintains the repository-level model representation.

Potentially.

The architecture is designed around standard SysML v2 APIs rather than requiring Kotar itself to depend on a specific repository implementation.

A different repository implementation could therefore potentially be integrated if it provides the required compatible APIs and semantics.

Flexo is the currently integrated model repository and provides functionality beyond basic Git-based storage.

Potentially, but this is not currently a supported integration.

Kotar is designed around SysML v2 APIs and repository interfaces. If Teamwork Cloud, or an integration layer in front of it, exposes compatible APIs and the required model semantics, an integration could potentially be developed.

The currently integrated solution uses Flexo/OpenMBEE together with Git.

Flexo persists model identities, including UUIDs, as part of the repository representation.

The textual SysML v2 representation currently does not contain all of the information necessary to independently preserve UUID identity through arbitrary text operations.

For this reason, Kotar combines textual model management with repository-level identity management rather than relying exclusively on text files for model identity.

Currently, UUIDs are not directly tracked in the SysML v2 textual representation.

Git therefore primarily versions the textual model, while Flexo maintains repository-level model identities.

Kotar combines the two mechanisms so that Git can provide familiar source configuration management while Flexo provides model-aware persistence.

Kotar uses a hybrid Git + Flexo configuration-management approach.

Git provides fine-grained version history of the textual SysML v2 model. Valid model states can be automatically committed while editing, providing a micro-commit history.

Because a purely textual diff is not always sufficient to understand semantic model changes, model-aware diff capabilities are also being developed.

Kotar has an initial model diff capability, and integration with LieberLieber LemonTree is being investigated/developed for more advanced model comparison.

Kotar lets you develop and test queries directly from files in your workspace. This can be more convenient for developing and experimenting with queries than using the web service's stored-query functionality.

The query type is determined by the file extension:

To workshop a query, create a file with the appropriate extension in your workspace, enter the query, and execute it from Kotar.

For example, create a .json or .jsonc file to develop a JSON-based model query:

Similarly:

• Use .rq files for SPARQL queries against MMS
• Use .sql files for SQL queries against the relational database
• Use .kq files for KerML queries against the live, in-memory model

The RDF graph uses a minified storage representation of the SysML v2 model.

To reduce database size and avoid storing redundant information, flexo-sysml does not persist properties that are implied by the model or can be re-derived from other information.

This does not mean that these properties are lost. When accessing the model through the SysML v2 service endpoints, the service reconstructs the omitted properties and returns the expected SysML v2 representation.

As a result, there is an important distinction between:

• SysML v2 API queries — return the reconstructed SysML v2 model, including properties that can be derived from the stored representation.
• Direct SPARQL queries against the RDF graph — currently operate on the lower-level, minified RDF storage representation and may therefore not expose all properties that would appear in the SysML v2 API representation.

A future capability is planned to provide a SysML v2 view of the RDF graph for SPARQL queries. This may use a rule engine or "magic property" layer to derive omitted properties dynamically, allowing SPARQL queries to operate against a logically fully materialized SysML v2 representation without requiring all derived information to be physically stored in the graph.

Note: This SysML v2 SPARQL view has not yet been implemented. When writing .rq queries today, be aware that you are querying the minified RDF storage representation directly.

Kotar includes an in-house diagram generator.

Tom Sawyer can also be used as an option for diagram generation where its automatic layout capabilities are desired.

User control over automatic source-change detection has been identified as a desired capability.

If this option is not present in the current release, it is planned to be added.

Yes. Kotar can be used without a separately deployed enterprise Flexo model repository.

Available deployment approaches include:

• Kotar Community (static): Standalone browser-based IDE without built-in server-side authentication or Git network integration.
• Kotar Enterprise (authenticated server): Browser-based IDE with OIDC authentication, group-based authorization, and GitLab integration. It includes an application server, but does not require a separate enterprise Flexo repository.
• Desktop installation: Installable locally for environments where a browser-hosted deployment is not appropriate.

Both container editions are available as Docker images, and Kubernetes deployments are supported through the Kotar Helm chart. A shared Flexo repository is optional and is needed only for additional shared model-repository capabilities.

See Kotar Community on Docker Hub and Kotar Enterprise on Docker Hub for deployment instructions.

No.

Flexo is included as a local, in-browser service and does not require a separately deployed backend.

If GitLab is your existing collaboration and source-control platform, you can initially use GitLab as the remote Git backend without deploying an enterprise Flexo instance.

A remote Flexo instance can be added later if you want shared model-repository features such as persistent model identities, model queries, clone/push/pull of graph-based model revisions, or other collaborative Flexo capabilities.

Yes. Kotar Enterprise (the authenticated server edition) supports GitLab.com and self-hosted GitLab instances, including internal GitLab deployments.

GitLab integration supports:

• Connecting to GitLab using OAuth or personal access tokens
• Opening repositories using Open from GitLab
• Cloning Git repositories
• Fetching, pulling, committing, and pushing changes
• Using Git commands from Kotar's integrated terminal

Git operations are routed through Kotar's built-in Git proxy.

A separately deployed Flexo server is not required for GitLab-based source management.

Kotar Community (the static edition) does not support remote Git operations.

Kotar Enterprise includes a built-in Git proxy, so there is no need to deploy a separate Git proxy.

The administrator configures one or more permitted GitLab instances using GITLAB_PROVIDERS.

For example:

GITLAB_PROVIDERS=[{"origin":"https://gitlab.example.com","label":"Company GitLab"}]

Users can then authenticate to the configured GitLab instance using a personal access token.

Alternatively, administrators can register a GitLab OAuth application to enable Sign in to GitLab.

After connecting, users can select Open from GitLab to browse available repositories and open a workspace.

For internal GitLab instances, the administrator may need to enable allowPrivateNetwork and configure the appropriate CA certificates.

See the Kotar Enterprise Docker Hub deployment guide for details.

No. Kotar Enterprise includes a built-in Git proxy that handles Git smart-HTTP operations, including clone, fetch, pull, and push.

Git requests are routed through the same origin as the Kotar application, using paths under /git-proxy/.

The server relays requests to configured and permitted GitLab instances and attaches the user's GitLab credentials.

Administrators therefore do not need to implement their own Git proxy for standard deployments.

GitLab instances must be directly reachable from the Kotar server.

Yes.

With the authenticated server edition, GitLab credentials are held in an HttpOnly cookie and used by the server-side Git proxy.

The proxy attaches the credentials when forwarding Git requests to GitLab. Browser-side application scripts cannot directly read the HttpOnly cookie.

Users can authenticate through GitLab OAuth or provide a personal access token.

Yes.

The authenticated server supports the GIT_PROXY_URL configuration variable.

By default, Git operations use Kotar's built-in same-origin /git-proxy endpoint.

Administrators can configure an alternative Git endpoint using an HTTPS URL or absolute path.

For standard GitLab deployments, the built-in proxy is recommended.

GitLab is the supported Git integration for authenticated repository workflows.

GitHub authentication and the GitLab-style repository selection workflow are not supported for GitHub.

Administrators can optionally allow public Git clones from additional hosts, such as github.com, through GIT_PUBLIC_HOSTS.

Private GitHub authentication is not supported.

Yes. Kotar Enterprise includes native OpenID Connect (OIDC) authentication and group-based authorization. It can integrate with compatible organizational identity providers, including Keycloak, Authentik, Microsoft Entra ID, and GitLab.

Kotar reads the configured group claim from the ID token or, when the claim is absent there, from the OIDC UserInfo endpoint. Access is granted only when a returned group matches ALLOWED_GROUPS.

The primary OIDC login callback is:

https://<your-host>/auth/callback

For GitLab used as the OIDC identity provider, configure OIDC_SCOPES=openid profile email because GitLab does not support the groups scope. Group memberships can be returned in the UserInfo groups claim.

GitLab repository authentication is separate from Kotar login. The optional GitLab OAuth integration uses https://<your-host>/auth/gitlab/callback and GitLab repository scopes (read_api, read_repository, write_repository). GitLab operations use Kotar Enterprise's built-in same-origin Git proxy.

Kotar Community does not provide built-in login or group-based authorization, although organizations may choose to place their static deployment behind separately managed authentication middleware.

The exact configuration depends on the organization's infrastructure. See the Kotar Enterprise deployment documentation.

This is an intended deployment workflow but is not yet fully implemented.

A user could, for example, select Open in Kotar from another engineering portal and launch Kotar with the appropriate project and Git remote already configured.

This would allow an organization to integrate Kotar into an existing engineering environment without requiring users to manually configure the repository each time.

Some of the packaging and deployment details for this workflow are still being developed. Until this workflow is available, Kotar Enterprise users can open repositories using Open from GitLab or clone them using the built-in terminal.

Kotar Community is available for free use but is not open source.

Kotar Enterprise provides additional capabilities for organizational deployment, including centralized authentication, access control, and GitLab integration. Its licensing terms are provided separately.

Kotar is built on components from the OpenMBEE ecosystem, including open-source SysML v2 tooling.

The underlying SysML v2 kernel and SDKs can be used independently of Kotar, subject to their respective open-source licenses.

See Kotar Community and Kotar Enterprise on Docker Hub for information about the available editions.

Yes.

The kernel is intended to be usable independently of Kotar, including through command-line tools and SDKs.

This allows applications, scripts, CI/CD pipelines, engineering tools, and other integrations to use the same SysML v2 parsing and model-processing capabilities without requiring Kotar itself.

Yes. Python support is planned as part of the SysML v2 SDK.

The goal is to allow developers to install and use the SysML v2 kernel directly from a Python environment, so Python-based engineering tools can parse, inspect, generate, and manipulate SysML v2 models without depending on Kotar.

Python SDK support is still under development.

The SysML v2 SDK is being developed for multiple programming environments, including:

• Python
• TypeScript
• C#

The intention is to make the kernel usable as a general-purpose SysML v2 library for applications, automation, CI/CD pipelines, and engineering-tool integrations.

That is the intended direction.

Kotar already uses strongly typed TypeScript interfaces for scripting and transformations. The longer-term goal is for the same capabilities to be available as a reusable SDK dependency outside Kotar.

Standalone SDK packaging and usage are still being finalized.

Yes.

Kotar supports scripting and model transformations directly in the workspace.

For example, tabular data such as CSV files can be loaded, filtered, and transformed into SysML v2 model elements using transformation scripts.

Kotar currently supports scripting with technologies including:

• TypeScript
• Python

Transformation scripts can work with workspace files, structured data, model elements, and other local data sources.

Yes, depending on the deployment and integration mechanism.

Kotar includes a local Flexo model repository that provides SysML v2 model APIs.

In the browser-based edition, the local Flexo instance executes inside the browser and is not directly exposed as a network-accessible service to external applications.

External tools can exchange model data through exported files, Git-based workflows, or compatible remote Flexo repositories.

The downloadable desktop edition can support direct integration with local engineering applications through its available model interfaces. This should not be confused with a network endpoint exposed by Kotar Community or Enterprise in a browser.

For browser-based deployments, direct access from external applications requires an explicitly supported integration mechanism.

This is an important intended integration pattern.

Because Kotar operates on a live SysML v2 model, external tools can potentially interact with model data through a suitably exposed SysML v2 API, such as a compatible remote Flexo repository or supported desktop integration. The browser-based local Flexo instance is not directly exposed to external applications.

This enables workflows where specialty engineering tools perform analyses or generate model changes and those changes are reflected back into the engineering environment.

The exact live synchronization and integration mechanisms for external tools are still being developed.

Yes.

A core design goal is to make SysML v2 the integration layer between systems models and discipline-specific engineering tools.

External tools can interact with the model through:

• SysML v2 APIs
• SDKs
• Scripts and transformation pipelines
• Git-based workflows
• Model queries

This makes it possible to integrate analysis, optimization, requirements, simulation, and other engineering tools into automated digital-engineering workflows.

Yes.

Automation and CI/CD are core design goals of Kotar and the surrounding SysML v2 tooling.

Git repositories can contain not only SysML v2 models, but also scripts, analysis code, transformations, and other supporting files.

These artifacts can then participate in normal Git-based CI/CD workflows for tasks such as:

• Model validation
• Model transformations
• Analysis execution
• Verification
• Documentation generation
• Integration with external engineering tools

Flexo can be used alongside Git when model-aware persistence and repository capabilities are required.

Yes.

Git can track the complete workspace, including:

• .sysml files
• Python scripts
• TypeScript scripts
• Configuration files
• Data files
• Other engineering artifacts

Kotar can use Git and Flexo together. Git provides conventional source-control history, while Flexo provides model-aware persistence and identity management.

When a Git commit is created, it can be associated with the corresponding Flexo model revision.

External editing is supported.

Users can clone a repository, edit the SysML v2 text using another editor, and push those changes through normal Git workflows.

Kotar and kernel can reconstruct model information from the changed textual notation when the files are loaded again.

However, preservation of persistent model identities across arbitrary text-only edits is currently a best-effort process. Model identity is more reliable when changes are made through tooling that integrates the SysML v2 kernel.

Document generation is under active development.

The planned approach is based on the OpenMBEE View Editor concept, where model information can be transcluded into model-based documents.

The SysML v2 implementation is intended to use:

• Views
• Viewpoints
• Queries
• Model-linked document content

This will support generation of documents that remain connected to the underlying SysML v2 model.

This is on the roadmap but is not yet implemented.

The goal is to allow SysML v2 Views and Viewpoints defined in textual notation to drive graphical and document-oriented representations inside Kotar.

The broader Starforge environment uses SysML v2 as a semantic backbone for AI-assisted engineering.

The general approach is to allow AI systems to interact with structured engineering models, rather than treating engineering information only as unstructured text.

This can enable AI-assisted workflows involving model queries, analysis, transformations, engineering automation, and interaction with other digital-engineering services.

More detailed AI integration capabilities are part of the broader Starforge platform rather than only the standalone Kotar.

In SysML v2, // creates a note, which the textual notation ignores. It is not a model element. /* ... */ creates a Comment, which is a real element in the model.

When you add a // note, the text of the file changes, so Kotar still records an automatic local Flexo commit. But the model itself hasn't changed. The Model Remotes panel compares model revisions, so it has nothing to show as Ahead and nothing to push.

To share a comment through the remote Flexo, write it as a model comment:

/* This comment is part of the model and will be pushed. */
// This note is ignored by the model and will not be pushed.

Note: // notes stay in the .sysml text, so they are still shared if you collaborate through Git. They are only left out of Flexo, which stores the model rather than the text.

Remote Flexo connections are saved locally, not to your account.

Settings such as remote Flexo connections are stored in your local browser environment, the same way the local Flexo repository is. They are not synced between machines, even when using Kotar Enterprise for authentication and GitLab access.

If you use Kotar on more than one machine, add the remote Flexo connection to the settings JSON on each one.

Both editions provide the same browser-based SysML v2 modeling environment, including local model processing and an in-browser Flexo repository.

Kotar Community (static Docker image) is intended for individual users who want a standalone modeling environment without server-side authentication or enterprise infrastructure.

Kotar Enterprise (authenticated server Docker image) adds centrally managed authentication, group-based access control, and GitLab repository integration.

Both editions store the working model locally in the browser by default.

A remote Flexo repository is optional and is not required for GitLab-based source management.

See the Kotar Community Docker image and Kotar Enterprise for installation and deployment instructions.