The eleven categories
The eleven categories every policy maps into, including subjects and relationships, and how a real policy passage lands in each.
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, 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, 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 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: the parts of a pack.
- Draft a pack: how the assistant does this mapping with you.