> ## 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. # Glossary > Definitions for the Starfort terms used throughout this documentation. | Term | Definition | | --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Starfort** | AIM Intelligence's AI governance ("intelligence control") platform. | | **Skeleton / Core** | The platform's two structural halves: the **Skeleton** framework (Admin Section + Bastion Section) and the **Core** execution engine (Guardian + AI Model Pool). | | **Admin Section / Bastion Section** | The **control plane** (Web Console + Admin Server) vs. the **data plane** (Integration Layer + Bastion Guardian + Guardian Layer). | | **Bastion Guardian** | The data-plane component that receives live traffic, normalizes it, and routes it to the Core (Guardian). | | **Guardian** | The engine that inspects content against Guard Policies and returns an action. See [Guardian](/en/v1.2/concepts/guardian). | | **System Guardian** | The master Guardian definition/preset (e.g. `VLM-OCR`) registered on the platform. Its capability spec is **immutable after registration**. | | **Project Guardian** | A project's own configurable instance of a System Guardian — it copies the spec at creation and owns it independently (no retroactive propagation). | | **AI Model Pool** | The set of models (SLM / VLM / OCR, …) a Guardian uses to analyze each Input Type. | | **Guardian Fail-Closed** | A Guardian's rule that a request it cannot fully analyze is returned as an HTTP error, never as an empty-detection success. | | **Guard Policy** | The PII or Topic rules a Guardian enforces. See [Guard Policy](/en/v1.2/concepts/guard-policy). | | **PII policy** | A Guard Policy made of NER / regex / keyword rules that mask or block personal data. | | **Topic policy** | A Guard Policy that classifies content against topics (`safe` → PASS / `controversial` → CHECK / `unsafe` → BLOCK). | | **Policy Type / Guard Policy Type Catalog** | The category of a Guard Policy. The catalog is the fixed set `{ PII, TOPIC }`; a System Guardian declares a subset and a Project Guardian inherits it. | | **Policy Name** | An individual Guard Policy's name — unique per project; the identifier in Guardian output and Opticon tags. | | **Pin** | A Project Guardian fixing a specific Guard Policy version; saving a new version does not auto-apply (save ≠ apply). | | **Input Type** | A kind of content a Guardian can inspect: Text, Image, Audio, Video, Document, Archive. | | **Process type** | The stage being evaluated — a free-form, case-insensitive label per Guardian, commonly `input` (to the model) and `output` (from the model). A process type with zero compatible Policy Types is *Policy-not-required*. | | **Action** | The result of an evaluation. **PII** uses `PASS` / `MASK` / `BLOCK`; **Topic** uses `PASS` / `CHECK` / `BLOCK`. Overall priority: `BLOCK > MASK > CHECK > PASS`. See [Actions](/en/v1.2/concepts/actions-pass-mask-block). | | **CHECK** | A Topic-only action for `controversial` content (review-needed). On Desktop Agent / Proxy Server it is enforced as PASS (logged to the trace only); API callers receive it directly. | | **Mask word / token** | The placeholder a masked value is replaced with, e.g. `[PHONE_NUMBER_1]` — numbered per category, value-stable. | | **Guard API** | The HTTP endpoint developers call to guard content (`POST /v1/guard/api`). See [API quickstart](/en/v1.2/api/quickstart). | | **API key** | A `sf_`-prefixed credential that authorizes Guard API calls for a Guardian. Its state is `Active` / `Inactive` / `Revoked`, orthogonal to the Kill Switch. | | **Account** | The authenticating subject that logs into the console (distinct from Agent User / API End User). | | **Multi-Company** | The model in which one Account belongs to several Companies; permissions resolve in the `(Account, Company)` context. | | **Proxy Server** | An Integration-Layer entry point that routes server-side AI calls from an external service through Starfort. | | **Desktop Agent** | The Windows application that transparently enforces policy on employees' AI usage. | | **Control Profile** | A company-level definition of an AI service the Desktop Agent governs (capture targets, whitelist, blacklist). See [Control Profiles](/en/v1.2/admin/control-profiles). | | **Company Access Key** | The key a Desktop Agent uses to register to a company. | | **Agent User** | An employee registered to run the Desktop Agent. | | **Global / Company / Organization / Project** | The four-tier resource hierarchy (Global is the system-wide root). See [Organization hierarchy](/en/v1.2/concepts/organization-hierarchy). | | **Kill Switch** | An emergency toggle at three tiers — Organization / Project / Project Guardian — that halts all Project Guardians beneath it (preserving their state). A Company has no Kill Switch of its own. | | **Opticon** | The monitoring app that records a trace for every Guard evaluation. See [Monitor traces](/en/v1.2/admin/monitoring-opticon). | | **Trace** | One recorded request/response evaluation in Opticon (a runtime record — separate from the Audit Log). | | **Audit Log** | The immutable record of **governance changes only** (two tiers: Company + `/aim` System) — excludes runtime traces, automatic system events, reads, and denied attempts. |