---
title: The eleven categories
description: The eleven categories every policy maps into, including subjects and relationships, and how a real policy passage lands in each.
sidebar:
  order: 6
---

Policies are written for people: paragraphs, bullet lists, exceptions in footnotes. To turn one into a pack, the drafting assistant first sorts every material passage into eleven shared categories. The same eleven work for any department: support triage, contract review, hiring, approved marketing claims, refunds, sales qualification.

Sorting a passage into a category organizes it for review. It doesn't by itself make Felspar enforce it. The categories show the reviewer that nothing in the policy was skipped, and an empty category is a question to ask, not proof it doesn't apply.

| Category | Ask of the policy | Becomes in the pack |
| --- | --- | --- |
| **Actors** | Who decides, acts, owns or receives this? | The accountable owner, review lanes, who a next step routes to |
| **Decision criteria** | What conditions select an outcome, including exceptions? | Rules and their order |
| **Source signals** | Which observations and sources does this job use? | Evidence kinds, "where to look" |
| **Needs and requirements** | What facts, definitions and prerequisites are required? | Questions, answers, inclusions, exclusions, examples |
| **Evidence and proof** | What supports a claim, and when is evidence eligible? | Accepted source classes, maximum evidence age |
| **Boundaries** | What must never happen, or needs approval? | Outcomes that stop or escalate, gate rules on actions |
| **Output contracts** | What must a produced result contain or exclude? | Outcomes and their next steps |
| **Routing jobs** | Which job and destination apply? | The job, next steps that name a team or lane |
| **Gaps** | What is unknown, contradictory or undecided? | "None of these" answers, policy-gap lanes, findings for the owner |
| **Evaluations** | Which checks and examples define acceptable behavior? | Test cases |
| **Subjects and relationships** | What is one case about, and which other records relate to it? | The job's [subject](/concepts/subjects-and-escalations), how its ID is written and matched, and its relationships |

A passage can belong to several categories. "The message must never guarantee returns" is both an output contract and a boundary.

The eleventh category, **subjects and relationships**, was added last. A mapping written before it has no entry for it and stays valid.

## Tagging what a passage actually says

- "For a trial, return the pilot offer" is **decision criteria** plus **output contracts**. Add **routing jobs** only when it names a job or destination.
- A definition, inclusion or exclusion is **needs and requirements**. "Synthetic excludes anonymized production records" defines a term; it doesn't ban anything. Add **boundaries** only for an explicit ban or approval condition.
- Evidence eligibility ("use records younger than 30 days") is **evidence and proof**, plus **source signals** when it names sources. It becomes an **evaluation** only with an expected behavior ("a 31-day-old record must come back as missing evidence").
- Missing authority, contradictory clauses and unclear owners are **gaps**. Name the conflict; don't rewrite the policy as if it said something else.
- "A ticket is one request a customer sends to the help desk" is **subjects and relationships**: it says what a case is. "Each contract is filed under one matter" is too: it names a relationship. Who reviews or approves is still **actors**, and the job itself is still **routing jobs**.
- "A held ticket goes to human review" is **routing jobs** plus **gaps**. In the pack it becomes a named [escalation](/concepts/subjects-and-escalations#escalations), such as `human-review`.

## The same categories in other work

| Category | Support triage | NDA review | Candidate screening |
| --- | --- | --- | --- |
| Subjects and relationships | A ticket, and the customer who sent it | A contract, its counterparty company and its matter | A candidate, and the requisition they applied to |
| Decision criteria | Which team a request type goes to | Which governing-law and term combinations can be signed | Which must-have qualifications advance a candidate |
| Evidence and proof | The ticket thread and the account record | The contract text and a sanctions registry entry | The resume and the application form |
| Boundaries | Never promise a refund date | Never sign with a sanctioned affiliate | Never screen on a protected characteristic |
| Gaps | A request type the policy doesn't list | A governing law the playbook doesn't mention | A qualification the posting doesn't define |

## A real policy, mapped

Here is how the fictional [Fernwood Payments ideal-customer policy](/concepts/fernwood-example) maps into the eleven categories.

| Category | Fernwood passage | In the pack |
| --- | --- | --- |
| Actors | "A person on the sales operations team reviews the page and decides within two business days." | The conflicting-signals review lane routes to sales operations |
| Decision criteria | "A payments API whose main user is software teams is a Platform Builder." | Rule `platform-builder`: `offering = payments_api` and `main_user = software_teams` gives `platform_builder` |
| Source signals | "Open the domain's root address and read the first screen and the footer." | Where to look for `page_kind`; evidence kinds `company-site` and `outside-source` |
| Needs and requirements | "Payments API. Building blocks for money movement that other companies put inside their own product. Counts: API, SDK, embed..." | Answer `payments_api` with its meaning, inclusions, exclusions and example |
| Evidence and proof | "Use evidence no older than 90 days: a web page counts from when it was read, a record from its last update." | Maximum evidence age of 90 days, and how `observedAt` is set |
| Boundaries | "Nobody contacts a prospect because of a classification alone." and "Record the reason and do not contact the company." | `not_a_fit` stops outreach; the pre-action gate allows an email draft only for fit outcomes |
| Output contracts | "Route to the platform sales team within one business day and offer a sandbox key." | The next step returned with `platform_builder` |
| Routing jobs | "Classify one prospect company, identified by its website domain, into exactly one outcome." | The job `classify-prospect`, one entity per domain |
| Gaps | "Another financial product... is a policy gap; send to the policy-gap review lane." | "None of these" answers route to `review_policy_gap` instead of a guess |
| Evaluations | "The address for 'Corvid Labs' shows a page for Corvid Roofing." | Test case `namesake` expects `review_wrong_site` |
| Subjects and relationships | "Classify one prospect company, identified by its website domain, into exactly one outcome." | Subject `company`, identified by its web domain and matched without case, so `Tidewell.example` and `tidewell.example` are one case |

Notice what the mapping does with uncertainty. The policy says what to do when a company sells "another financial product" or speaks to "other users": send it to a person. The pack keeps that as an outcome, so an agent never guesses its way past the edge of the policy.

## Related

- [Decision Packs](/concepts/decision-packs): the parts of a pack.
- [Draft a pack](/guides/draft-a-pack): how the assistant does this mapping with you.