Glossary - Starfort

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 + the gateways (Bastion Guardian · Bastion Stratum) + Guardian Layer).
Bastion Guardian	The Guardian side of the data-plane gateways — receives traffic bound for Guardian, normalizes it, and routes it to the Core (Guardian). Traffic bound for Stratum goes to Bastion Stratum.
Bastion Stratum	The Stratum side of the data-plane gateways — the intake and query surface for Stratum-bound traffic, handling authentication, Kill Switch evaluation, and routing; classification and verdicts are Stratum’s responsibility (parallel to Bastion Guardian — only the module served differs).
Guardian	The engine that inspects content against Guard Policies and returns an action. See 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).
Module	A type-level concept naming a kind of inspection — Guardian (text input) · Stratum (files). Orthogonal to Project Type. See Module Instances.
Module Instance	A concrete instance of a module created inside a project — individually, a Project Guardian / Project Stratum. Created and deleted within the granted entitlements; the lowest Kill Switch tier.
Stratum	The file-governing module introduced in v1.4 — classifies files (documents) as Confidential / Internal / General, produces masked copies, and governs external transfer. See Stratum.
Project Stratum	The Stratum module instance created inside a project — a peer of Project Guardian; pins Taxonomy and Rule Package versions.
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.
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 / `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 module instance fixing a specific version of a policy artifact (Project Guardian → Guard Policy, Project Stratum → Rule Package); saving a new version does not auto-apply (save ≠ apply).
Policy artifact	The collective name for a project-level policy’s deployable unit — Guardian = Guard Policy, Stratum = Rule Package. Peer project policies under the same management discipline (versioning · save ≠ apply · Pin).
Rule Package	Stratum’s policy artifact — defines the grading policy in three layers: detector definitions (Layer A) / classification rules (Layer B) / label policy (Layer C), and references a specific Taxonomy version. See Manage Taxonomies & Rule Packages.
Taxonomy	Stratum’s grading-scheme artifact — defines the grade set, each grade’s rank, its verdict method, and thresholds. Versioned separately from Rule Packages, which reference it.
Detector	The smallest unit that detects a specific signal — fingerprint · exact match · pattern · keyword · semantic classification · clause-based judgment. Each detector carries a grade attribution: which grade it contributes to.
Classification rules	The Rule Package layer (Layer B) that combines detector signals into grade candidates — with priorities, terminal (confirm), suppression, and negative conditions.
Label policy	The Rule Package layer (Layer C) that resolves grade conflicts (highest rank wins) and decides external-transfer routing (auto-finalized / gray zone / blocked).
Fingerprint template	The structured form (blank template) that fingerprint classification matches against — a project-owned asset never shared across projects; the classification engine keeps only the matching fingerprint while the original is preserved on the audit plane. See Fingerprint templates.
Evidence	The basis of a Stratum verdict — detection layer · detector · contributing grade · confidence · masked preview (never the raw text) · a per-detection maskable flag (`maskable`).
Masked document	The document Stratum produces by masking detected items — the input to re-grading, preserved on the audit plane, and returned via the API.
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 is 2-state: `PASS` / `BLOCK`. Overall priority: `BLOCK > MASK > PASS`. See Actions.
Mask word / token	The placeholder a masked value is replaced with, e.g. `[PHONE_NUMBER_1]` — numbered per category, value-stable.
Processed content (`processed_content`)	What Guardian produces by parsing and normalizing an input (with OCR or decoding where needed) and rebuilding it — the egress payload delivered instead of the caller’s original on verdicts that forward content (PASS · MASK); inputs it can’t be built from are never delivered (`null`). See Actions.
Guard API	The HTTP endpoint developers call to guard content (`POST /v1/guard/api`). See 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.
S3 de-identification batch	The bucket-reference asynchronous processing path — instead of a request body, it takes a source address (`src_s3_url`) and a target address (`tgt_s3_url`); Starfort reads the original from the bucket, detects and de-identifies it through Guardian, and writes the output to tgt. See Batch overview.
Batch job	The unit of work in the S3 de-identification batch (1 job = 1 object) — four states, `PENDING` / `PROCESSING` / `COMPLETED` / `FAILED`, processed in intake order (FIFO); BLOCK is not a failure but `COMPLETED` + a verdict (`FAILED` = inspection not completed, no output written). See Batch jobs.
Storage Connection	A project-level S3 integration setting that lets Starfort access customer buckets — an endpoint, access keys (encrypted at rest, never re-exposed after registration), and allowed targets (bucket · prefix · READ/WRITE); requests outside the allowed scope are rejected at intake. See Storage Connection.
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.
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.
Kill Switch	An emergency toggle at three tiers — Organization / Project / module instance (Project Guardian · Project Stratum) — that halts all module instances 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.
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.