---
title: Extensions
description: Understand Basalt's lightweight extension registry, Vertical Intelligence Packs, Product Experience Packs, and Product Runtime boundary.
slug: extensions
path: /extensions
section: Platform
availability: mixed
nav_order: 9
canonical_url: https://developers.basaltnotes.com/extensions
markdown_url: https://developers.basaltnotes.com/extensions.md
mirror_url: https://basaltnotes.com/developers/extensions
---
# Extensions

Basalt has several extension layers with different trust and compatibility contracts. They should not be marketed as one unrestricted plugin system.

## Lightweight Extension SDK

The current client exposes a narrow global registry:

```js
BasaltExtensions.registerCommand(pluginId, command)
BasaltExtensions.registerImporter(pluginId, importer)
BasaltExtensions.registerQuarryView(pluginId, view)
```

The registry stores only registered command/importer/view capabilities. Extensions are not handed raw Basalt database, authentication, filesystem, or network objects through this registry.

### Commands

A command registration requires a plugin ID, command ID, and runnable command function.

### Importers

An importer registration requires a plugin ID, importer ID, and import function.

### Quarry views

A Quarry view requires a plugin ID, view ID, and render function.

### Security wording

The narrow registry is a capability boundary, but it should not be described as a hardened arbitrary-code sandbox unless the complete loader/execution path proves that property. Public documentation should describe what capabilities Basalt supplies, not promise that arbitrary JavaScript is safe merely because the registry itself is narrow.

## Vertical Intelligence Packs

Vertical Intelligence Packs define how a domain reasons over Basalt's shared intelligence core. They can define domain entities, relationships, governing constraints, source-authority semantics, deterministic evaluators, Decision Signals, readiness concepts, and domain-specific handoffs into Pulse/Strata/Forge.

They do **not** create a second decision engine, action engine, trust model, or canonical storage system.

Current authoring should be treated as **first-party / approved partner preview**, not unrestricted public arbitrary-code installation.

## Product Experience Packs

Product Experience Packs define how a product presents Basalt capabilities:

- branding;
- terminology;
- navigation;
- onboarding intent;
- home surfaces;
- capability visibility;
- safe presentation presets.

A Product Experience cannot change data authority, domain truth, entitlement, or governance merely by hiding/showing a capability.

Product Experience authoring is currently a **first-party / approved partner preview** surface.

## Product Runtime

If you are building a separate application over Basalt rather than extending the Basalt UI, use Product Runtime instead of deep-importing internal UI/storage modules.

## Which extension path should I use?

| Goal | Extension path |
|---|---|
| Add a narrow command/importer/Quarry renderer inside Basalt | Lightweight Extension SDK |
| Add a new professional/domain reasoning model | Vertical Intelligence Pack |
| Create a different Basalt product UX | Product Experience Pack |
| Build a separate application over Basalt | Product Runtime |

## Governance

None of these extension layers may bypass Strata decision authority, Forge mutation/action boundaries, Context Scope audience rules, plan entitlements, logical-vault grants, or permanent-memory trust/review requirements.