Skip to main content

Extensions

Most of what you see in Insight LM is delivered as an extension — a self-contained feature package that plugs into the workbench the way extensions plug into a modern code editor. The host application owns the shell, layout, and workspace; extensions contribute the features you work with: views, commands, file viewers, Assistant tools, agents, and workflows.

This matters to you as a user for three reasons:

  • You choose your surface. Extensions can be enabled or disabled in Settings, so a deployment carries the capabilities it needs and nothing else.
  • Features can't destabilize the core. Extensions integrate only through a public Extension API — they never reach into application internals. A misbehaving extension is a feature problem, not an application problem.
  • External systems stay optional. Extensions that connect to outside infrastructure (a triple store, a graph database, a modeling server) are always references, never dependencies. Core capabilities work with the built-in services alone; connectors add reach when you have the infrastructure.

Two kinds of extensions​

Bundled extensions ship inside the application and are present in every install — for example, the Systems Engineering workbench and the Ontology extension.

Installable extensions are published to a public extension feed and added per deployment — for example, the Jupyter notebook extension or the Insight Sheet spreadsheet.

The Extension Catalog lists what is available today and how mature each entry is.

For developers​

Extensions are how Insight LM is meant to grow — including, increasingly, by the Assistant itself under human review. If you want to build one, start with the developer guide.