Locking in your first portfolio artifact — a taxonomy, a policy, and the code that routes it
Day 10 of 60
Two weeks in, you've gone from "what could go wrong?" to "here is exactly what we do about it." This week produced your first real portfolio artifact: a multi-category safety taxonomy with precise definitions and severity tiers, a refusal policy that takes the helpful↔harmless tension seriously, and taxonomy.py that routes items and separates real violations from over-refusals. Today you finish it, make it defensible, and lock it in.
"Is this output harmful?" is meaningless until someone authors the categories, the tiers, and the edge rules. A safety policy is the contract every downstream filter, eval, and reviewer inherits — and authoring one that's decidable, balanced, and versioned is one of the highest-leverage things a safety practitioner does.
A taxonomy that only its author can apply isn't finished — it's a personal heuristic with extra steps. The bar for "shipped" is reusability: could a new reviewer pick up your document and apply it consistently, with no explanation from you? That's the same property — inter-rater agreement — you've been designing for all week, now stated as the acceptance test.
For each category and tier, you can say in one sentence why it exists, what it excludes, and why its severity is what it is. If you can't defend a tier, it's a guess — fix it or merge it.
The document states what to allow, what to refuse, and what to safe-complete — and acknowledges that over-refusal is a failure, not a safe default. A policy that only knows how to refuse hasn't taken the tension seriously.
taxonomy.py implements the tiers and routing your prose describes, and its over-refusal branch is real. Document and code drifting apart is how policies quietly rot — they should ship together.
Get the three pieces committed together: the taxonomy, the refusal policy, and taxonomy.py. This is the first checkpoint of your Part A portfolio. The honors move: draft a one-paragraph note on how you'd roll this out to a review team — onboarding, the changelog discipline from Day 9, and how disagreements feed back into the policy.
A practitioner ships a policy they can apply. An expert ships a policy someone else can apply — and packages it as taxonomy + policy + code together, with a changelog and a rollout plan, so it scales beyond their own judgment. The altitude jump is from having a good standard to operationalizing one: a document, code, and a process that make a whole team's decisions consistent and auditable.
Say this in an interview: "My bar for a finished policy is reusability — a new reviewer can apply it consistently with no explanation from me. So I ship the taxonomy, the refusal policy, and the routing code as one versioned artifact with a changelog, and I can defend every category and tier. That's the difference between a personal heuristic and a standard a team can run."