> ## Documentation Index > Fetch the complete documentation index at: https://docs.starfort.io/llms.txt > Use this file to discover all available pages before exploring further. # Module Instances > Starfort v1.4 generalizes a project's resources into module instances — Project Type and module axes, entitlements, and Kill Switch scope (Starfort v1.4 docs) v1.4 generalizes the old resource model — "the Project Guardian(s) inside a project" — into the **Module Instance** concept. It's the foundation that lets [Stratum](/en/v1.4/concepts/stratum) sit on top of the existing platform, and the groundwork for modules to come. ## Two orthogonal axes — Project Type × module Platform resources are expressed along two independent axes: | Axis | Definition | Values | Character | | ---------------- | ------------------------------------------- | --------------------------------------- | ------------------------------------ | | **Project Type** | How traffic comes in (the integration form) | API · Desktop Agent | Fixed at project creation, immutable | | **Module** | What gets inspected (the capability) | Guardian (text input) · Stratum (files) | Created and deleted inside a project | Because the axes are independent, a combination like "a Desktop Agent project running both Guardian and Stratum" is expressed naturally within one project. ## Modules and module instances A **module** is a type-level concept naming a kind of inspection — Guardian governs text input, Stratum governs files. A **module instance** is a concrete instance of a module created inside a project; individually they keep their established names, **Project Guardian** and **Project Stratum**. Project Guardian was the first case; Project Stratum is the second. A project can hold multiple module instances. Modules are registered as module types in `/aim` (System), and projects instantiate them from there — the same two-layer structure as System Guardian registration → Project Guardian creation, reused as-is. ## Routing by input type Which module handles which input type (text vs. file) follows from which module instances the project has. A Control Profile can be assigned **one instance per module** (one Guardian and one Stratum — both or either), and the gateway branches to the responsible module by input type. Results are never cross-combined across modules. | Module configuration | Text input | File input | | -------------------- | --------------------- | ----------------------------------------- | | Guardian + Stratum | Guardian (guardrails) | Stratum (grade classification) | | Guardian only | Guardian | Guardian (guardrails) — existing behavior | | Stratum only | (no inspection) | Stratum (grade classification) | ## Entitlements — the purchase and licensing layer The right to use a module is governed by **entitlements** — a separate layer from operating module instances: | Layer | Who controls it | What it means | | ---------------------------------------------------- | ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Entitlement** (purchase · license) | The System Admin (platform operator) in `/aim` | "Is this customer entitled to this module?" — granted by sales agreement, as a standalone purchase or a bundle. Customers can't change it from the console | | **Module instance creation · deletion** (operations) | The customer's console (Admin) | Creating and deleting module instances in projects, within the granted entitlements — genuine resource creation and deletion, not a mere on/off toggle | Entitlements are granted per module (Guardian only, Stratum only, or both). A Stratum entitlement plus an instance is enough to run file grade classification without purchasing Guardian — so selling a module standalone works. ## Instance creation/deletion vs. the Kill Switch The two means of controlling a module mean different things: * **Creating and deleting instances** — normal operations. A planned stop is expressed by removing the instance; running without classification is expressed by leaving no policy pinned. * **The [Kill Switch](/en/v1.4/admin/kill-switch)** — emergencies only. v1.4 adds the module instance (Project Guardian · Project Stratum) to the Kill Switch tiers, so it can fire at the **Organization / Project / module instance** level. You can emergency-stop one module without stopping the whole project. Module instances have no everyday enable/disable toggle — the Kill Switch is strictly for emergencies, just as Guardian instances have never had such a toggle. ## Learn more The module that governs text input — inspects content and decides PASS / MASK / BLOCK. The module that governs files — classifies documents by grade and governs external transfer. Company › Organization › Project, and where module instances live. Emergency stops at the Organization / Project / module instance level.