Module
A packaged vertical slice of IMOS — the workflows, capabilities and UI for one area of the business.
type: module · status: published · abstraction: entity
What it is
A Module is a working slice of IMOS packaged behind a single switch — like Production, Procurement, or Prepress. It bundles a coherent set of machinery by declaring a strict "surface": the Capabilities it uses, the Lists it defines, and the canonical Objects it references as dependencies. Packaged automations wire these pieces together but are strictly sandboxed to this declared surface. Because it does not own the foundational Objects, it remains completely safe and seamlessly portable across tenants.
Why it exists
The core architecture is built once and rarely touched. Modules are the expansion mechanism: new workflows arrive as bundled slices. By forcing Modules to explicitly declare their capabilities, lists, setup questions, and canonical Object dependencies, we allow suppliers to install complex workflows without wiring them by hand or risking their existing setup.
Relationships
Outgoing
- packages → Object (one-to-many) — Modules ship canonical Objects as part of their bundle.
- exposes → Capability (one-to-many) — Modules make their functionality available as Capabilities.
- depends on → Object (many-to-many) — Modules declare references to the foundational canonical Objects they need to interact with, without owning them.
Incoming
- is enabled by ← Workspace — Workspaces selectively enable Modules to expand a tenant's available feature set and object graph.
Neighbourhood
Stakeholder summaries
- Product — The unit of roadmap and packaging. Scope, price and release against Modules.
- Investor — The expansion engine. New verticals and segments are Module releases, not re-platforming projects.
- Marketing — Turn on only what you need today. Add Production, Quality or Maintenance whenever you are ready.
- Engineering — Declarative bundles of workflows, lists, views and Capabilities with explicit dependencies mapped to canonical Objects.