> ## 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.
# Manage Stratum policies
> Define Stratum Taxonomies and Rule Packages as project policies, then apply them to a Project Stratum via versioning and pinning (Starfort v1.4 docs)
[Stratum](/en/v1.4/concepts/stratum)'s grade classification is defined by two policy artifacts — the **Taxonomy**, which holds the grading scheme, and the **Rule Package**, which holds the classification rules themselves. Both are **project-level policies on equal footing with** Guardian's [Guard Policy](/en/v1.4/concepts/guard-policy), defined and owned by each project — because grading schemes and classification criteria differ by customer. The [two ingress paths](/en/v1.4/api/batch/overview) — inline synchronous and asynchronous batch — share the same Taxonomy and Rule Package.
Stratum's policies are not shared with Guardian's Guard Policies. Each module keeps its own policies and detection definitions; Guard Policies (PII/TOPIC) stay exactly as they are, untouched by Stratum.
## Two policy artifacts
| Artifact | What it holds |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------- |
| **Taxonomy** | The grading scheme — the grade set, each grade's rank, its verdict method, and thresholds |
| **Rule Package** | The classification rules themselves — a three-layer structure of detector definitions · classification rules · label policy |
The two artifacts are **versioned independently**, and a Rule Package references a specific Taxonomy version (referential integrity). Grading schemes are relatively stable, so one Taxonomy version being reused by several Rule Package versions is the common shape.
### Taxonomy — the grading scheme
As of v1.4 there are three grades:
| Grade | Rank | Verdict method |
| ---------------- | ------- | ----------------------------------------------------------------------------------------------- |
| **Confidential** | Highest | Score-based — signals are aggregated into a score and compared to a threshold |
| **Internal** | Middle | Score-based |
| **General** | Lowest | Clearance gate — passes only when "no suspicious signals, and classification ran to completion" |
When one document produces signals for multiple grades, it's finalized at the highest grade (highest-rank), and a manually assigned grade is never silently overwritten by automatic classification. Because the grading scheme lives in its own Taxonomy artifact, classification rules reference grades abstractly — the same rule structure works for customers with different grade counts, names, and criteria. For what the grades mean and how the classification pipeline works, see [Stratum concepts](/en/v1.4/concepts/stratum).
### Rule Package — the three-layer structure
A Rule Package separates detection (what) from verdicts (how) across three layers:
| Layer | Role |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Layer A — detector definitions** | What to detect — the detectors for each stage of the L1–L4 classification pipeline. Each detector carries a grade attribution: which grade it contributes to |
| **Layer B — classification rules** | Combine detector signals to emit grade candidates — with priorities, terminal (confirm), suppression, and negative conditions |
| **Layer C — label policy** | Resolves grade conflicts (highest rank wins) and decides external-transfer routing (auto-finalized / gray zone / blocked) |
For what to fill in first and how, see [Write a Rule Package](/en/v1.4/admin/how-to/write-stratum-rule-package). Layer A's fingerprint detectors reference the project's registered [fingerprint templates](/en/v1.4/admin/fingerprint-templates).
## The same management discipline as Guard Policies
Taxonomies and Rule Packages follow the same management discipline as [Guard Policies](/en/v1.4/admin/author-guard-policy) — the existing policy workflow, reused as-is:
| Discipline | What it means |
| --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| **Versioning** | Semantic Versioning — every edit publishes a new version |
| **Save ≠ apply** | Saving a new version, by itself, changes nothing |
| **Pin** | Fix a specific version on a module instance (Project Stratum) — the same way a Guard Policy version is pinned to a Project Guardian |
| **Separate versions + reference** | Taxonomies and Rule Packages are versioned independently, with the Rule Package referencing a specific Taxonomy version |
A Project Stratum with no Rule Package pinned **performs no classification and passes files straight through**. This is a planned state — the same as Guardian passing traffic uninspected with no policy assigned — and unpinning returns to it. Pin a Rule Package to start classifying.
## Start from the /aim template; the project defines the rest
`/aim` (System) provides Stratum's **policy type templates**. Each project takes the template as its standard starting point and defines its own Taxonomy and Rule Package — just as projects define Guard Policies against `/aim`'s Policy Type Catalog (the supported set). In short: `/aim` owns the templates (standard starting points); projects own the actual definitions, versions, and pins.
Taxonomies and Rule Packages follow a fixed schema rather than free-form documents, and the schema is the basis for input validation and versioning. The policy type templates support both JSON and YAML (interconvertible), and the policy model is defined in YAML.
## Where things are managed
| Item | Managed in |
| ------------------------------------------------------------------------ | ----------------------------------------------------- |
| Module type registration · policy type templates · entitlements | The `/aim` System standard — tenants can't edit these |
| Taxonomy · Rule Package definitions · versions · pins · threshold tuning | The project (tenant) console |
## Permissions
Viewing requires Project Member or above; defining and editing Taxonomies and Rule Packages, and approving secondary reviews, require Project Admin or above. The author/approver/activator role separation (author ≠ approver) follows the existing policy lifecycle's role model, and changes are recorded in the [Audit Log](/en/v1.4/admin/audit-log).
## Next steps
The hands-on guide to filling in Layer A detectors, Layer B classification rules, and the Layer C label policy.
Registering, revising, and re-viewing the structured forms (blank templates) fingerprint detectors reference.