Manage Stratum policies

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, defined and owned by each project — because grading schemes and classification criteria differ by customer. The two ingress paths — 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

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: 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.

​

Rule Package — the three-layer structure

A Rule Package separates detection (what) from verdicts (how) across three layers: For what to fill in first and how, see Write a Rule Package. Layer A’s fingerprint detectors reference the project’s registered fingerprint templates.

​

The same management discipline as Guard Policies

Taxonomies and Rule Packages follow the same management discipline as Guard Policies — the existing policy workflow, reused as-is:

​

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

​

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.

​

Next steps