---
type: Reference
title: "PMOS-STE term map — one term per concept"
description: The register of PMOS terms that have drifted into two names for one thing, with the evidence for each and a recommended canonical term. Level 3 sub-file of the technical-writing-ste skill, implementing ASD-STE100 rules 1.11 and 9.4 — the one rule that binds in every register, including argumentative text.
tags: [ste, writing, terminology, skills, house-standard]
timestamp: 2026-08-07
---

# PMOS-STE term map — one term per concept

Level 3 sub-file of `technical-writing-ste.skill`. Read it when you name a concept in any register, or when you notice a second name for something that already has one.

Rules 1.11 and 9.4 say it in one line: **do not use different terms for the same item, and keep terminology consistent.** This is the only STE rule that binds in Class C as well as A and B, because two names for one concept costs a reader the same whether the text instructs, describes, or argues.

**If you are reading this in your own repo, the method is what transfers, not the entries.** The register below holds PMOS's own drift, kept as worked examples of what an entry looks like and how strong its evidence has to be. Start your own register empty and add to it from *Adding an entry* at the end. The one portable finding is the question in step 2 of that procedure: **ask which reader is mechanical.** It settles most collisions without anyone ruling on anything.

## Status — proposed, not ruled

**Every canonical choice below is a recommendation with its evidence, not a decision.** Naming rulings on a live repo are the PM's: each one implies future edits to text that already exists, and the profile's own rule is that it binds new and modified text only. Until the PM rules, this file is a register of *known* drift — which is useful on its own, because you cannot avoid a collision you have not seen.

Where the recommendation is strong the entry says so, and says what makes it strong. Where two terms may be genuinely distinct, the entry says that instead of forcing a merge.

## The register — PMOS's own

### 1. `lane` vs `type`, for an initiative's work-type — **strong recommendation: `lane`**

The evidence is one-sided:

| Source | Says |
|---|---|
| `planning/initiatives/*.md` | **211 records** carry `lane:`. **Zero** carry `type:` with a lane value. |
| `scripts/workflow-state.js` | Reads `fm.lane`, defaulting to `feature`. It never reads a lane from `type`. |
| `pmos-router.skill` | Instructs `type: prototype`, `type: feature`, `type: discovery`. |
| `discovery.skill` | Instructs `type: discovery`, and states "file mode: `type: discovery` in the initiative frontmatter". |
| [`spike-brief-template`](/okf/core/templates/spike-brief-template.md) | Instructs `- type: discovery`. |

`type` is already taken. D63 makes `type` the repo-wide frontmatter key whose value comes from `scripts/frontmatter_registry.txt`, and an initiative record's correct value there is `Initiative`. So the three authoring sources tell you to overwrite a required field with a value its registry does not contain.

**How it fails, stated precisely:** loudly, not silently. An author who follows those instructions literally writes `type: discovery`, and the Frontmatter Gate rejects it because `discovery` is not in the registry. The cost is a confused author and a wasted CI round, not a corrupt record. It is worth fixing because the instruction is simply wrong, not because the repo is at risk.

The MCP argument name `type` is a separate question. That interface is a different surface with its own compatibility story, and this entry does not reach it.

### 2. `pre_run_contract` vs "sprint contract" — **recommendation: split the roles, keep both**

CLAUDE.md's own glossary lists them together, as one entry: *"pre_run_contract / sprint contract."* That is the defect stated in the source of truth. Counts across the harness docs, skills and scripts: `pre_run_contract` **20**, "sprint contract" **10**.

They are not quite synonyms in practice. `pre_run_contract` is the **field** on a run record. "Sprint contract" is the **section heading** in a rubric where the criteria are written. The honest fix is not to delete one but to say which is which, once, and then hold it: **`pre_run_contract` for the field and the concept; "sprint contract" only as the rubric's section heading, never as a synonym for the concept in prose.**

### 3. "health budget" vs "health anchor" — **watch item, no recommendation**

Counts: "health budget" **21**, "health anchor" **3**. The registry file is [`health-budgets.md`](/planning/okrs/health-budgets.md) and the concept file is [`health-anchors`](/okf/core/concepts/health-anchors.md).

These may be genuinely distinct: a *budget* is the allocation, and *anchoring* is what an initiative does to it. Forcing them together would lose a real difference. Recorded here so the next author checks the distinction rather than picking whichever came to mind — not to be merged.

## Not drift — do not "fix" these

A term map that flags near-misses trains people to ignore it. These pairs look like drift and are not:

- **"specimen test" vs "sharpness test."** Two different checks in the router's Step 0 — sharpness is 0.1 (*can the PM state the question?*), the specimen test is 0.3 (*can the PM judge it from a description?*). Both names are correct.
- **"explainer" vs "surface explainer."** `explain-surface` and `explain-run` produce different artifacts at different ends of the loop. The qualifier carries meaning.

## Adding an entry

1. Find a second name for something already named. Count both, and record the two counts.
2. Name what reads the term mechanically — a gate, a script, a field. That reader usually settles the question.
3. Write the recommendation, or write "watch item" when the two terms may be distinct.
4. Do not rewrite existing text. The profile binds new and modified text only.

**Done when:** the entry carries counts, a mechanical reader (or a statement that none exists), and either a recommendation or a stated reason to leave both.