Rig Bundles and Shareable Artifacts

A rig bundle is a packaged, shareable artifact that can instantiate an opinionated OpenRig topology and workflow. It may include:

• rig specs
• agent specs
• workflow specs
• startup files
• skills or skill references
• operating-mode declarations
• proof expectations
• supporting fragments

Shareable artifact is broader than bundle: specs, bundles, skills, workflows, and extensions can all be shared. A bundle is the packaged form for "load this topology and way of working."

Use this when

• Authoring a bundle from a proven lab pattern
• Installing a bundle (rig bundle install <path>)
• Inspecting a bundle before install (rig bundle inspect <path>)
• Reasoning about bundle vs extension boundary (bundle declares topology + workflow; extension adds behavior)
• Auditing a bundle for portability, does it work on a clean OpenRig environment, or only the author's machine?

Don't use this when

• The work is a one-off topology you won't reuse. Specs alone are sufficient.
• The intent is to add runtime behavior (commands, views, dashboards). Use extension-and-user-workspace, not bundles.
• You want to ship a workflow as a daemon feature. Bundle is the path before daemon promotion.

The bundle vs extension boundary (load-bearing)

Concept	Declares	Example
Bundle	Rig shape + workflow ("load this topology and way of working")	A Velocity Team bundle
Extension	Behavior added to user workspace/runtime	A custom command, view, or dashboard

Don't confuse them. A bundle is opinionated content; an extension is added behavior. Both can be shareable artifacts, but they're structurally distinct.

Failure modes (4)