# Rule 1.5 — You Can Use Words That You Can Include in a Technical Noun Category

> **Source:** Adapted from ASD-STE100 Issue 9
> **Source:** [master.md#sec1-rule1.5](ste-code/grouped/), Rule 1.5

## Original Rule

**Rule 1.5** You can use words that you can include in a technical noun category.

A technical noun is a noun term that refers to a specified concept and is applicable to a subject field.

The dictionary does not include technical nouns because there are too many, and each subject field uses different technical nouns for their texts.

You can find many of these technical nouns in your company glossary or terminology database.

STE gives you a list of categories, with examples, to help you:
- Select technical nouns to put in your company glossary or terminology database.
- Use technical nouns correctly.

You can use technical nouns in procedural and descriptive writing if you can include them in one or more of these twenty-two categories.

[The original specification lists 22 categories. Category titles include: Official parts information; Vehicles or machines, and locations on them; Tools and support equipment, their parts, and locations on them; Materials, consumables, and unwanted material; Facilities, infrastructure, and logistic procedures; Systems, components and circuits, their functions, configurations, and parts; Mathematical, scientific, engineering terms, and formulas; Navigation and geographic terms; Numbers, units of measurement and time (and their symbols); Quoted text; Professional roles, individuals, groups, organizations, and geopolitical entities; Parts of the body; Common personal effects, food, and beverages; Medical terms; Official documents, parts of documentation, standards, and guidelines; Environmental and operational conditions; Colors; Damage terms; Computer science, information and communication technology; Civil and military operations; Law and regulations; Animals, plants, and other life forms.]

## STE-Code Adaptation

**Rule 1.5** You can use words that you can include in a code-domain technical noun category.

A code-domain technical noun is a noun term that refers to a specified concept in software development and is applicable to a subject field.

The controlled terminology does not include all code-domain technical nouns because there are too many, and each project or subject field uses different technical nouns.

You can find many of these code-domain technical nouns in your project glossary or terminology database.

STE-Code gives you a list of categories, with examples, to help you:
- Select code-domain technical nouns to put in your project glossary or terminology database.
- Use code-domain technical nouns correctly.

You can use code-domain technical nouns in procedural and descriptive writing if you can include them in one or more of these nineteen categories.

1. **Code components, modules, and libraries**
   Terms that refer to software parts, packages, and reusable units of code.
   class, controller, helper, hook, middleware, mixin, module, package, plugin, provider, repository, service, utility

2. **Computing devices and their components**
   Terms that refer to hardware, devices, and physical computing resources.
   CPU, disk, GPU, keyboard, laptop, memory, monitor, mouse, printer, screen, server, smartphone, tablet, terminal

3. **Development tools, environments, and support equipment**
   Terms that refer to software development tools, IDEs, build systems, and testing frameworks.
   CLI, compiler, debugger, Docker, editor, IDE, Git, Jest, linter, loader, Prettier, terminal, test runner, TypeScript, webpack

4. **Data structures, types, and formats**
   Terms that refer to data representation, storage structures, and file formats.
   array, boolean, buffer, CSV, enum, hash map, integer, JSON, linked list, object, queue, stack, string, struct, tree, tuple, XML, YAML

5. **Infrastructure, deployment, and platforms**
   Terms that refer to hosting, deployment, containerization, and runtime platforms.
   AWS, CI/CD, container, deployment, Heroku, Kubernetes, load balancer, Node.js, pipeline, pod, production, staging, Vercel

6. **Systems, subsystems, and architectural components**
   Terms that refer to system design, architecture patterns, and their parts.
   API gateway, authentication layer, caching layer, client, database layer, message broker, microservice, proxy, rate limiter, REST API, routing layer, server, WebSocket

7. **Mathematical, algorithmic, and scientific terms**
   Terms that refer to algorithms, computational concepts, and mathematical formulas.
   Big O notation, binary search, coefficient, complexity, exponent, hash function, iteration, logarithm, matrix, recursion, regex, sorting algorithm, time complexity, traversal

8. **Interface elements and navigation**
   Terms that refer to UI components, navigation controls, and layout elements.
   button, checkbox, dialog, dropdown, footer, header, menu, modal, navigation bar, radio button, scrollbar, sidebar, tab, text field, toggle, tooltip

9. **Numbers, units of measurement, and time**
   Terms that refer to quantitative data, measurements, and time-related information.
   byte, gigabyte (GB), hertz (Hz), hour (h), kilobyte (KB), megabyte (MB), millisecond (ms), minute, nanosecond (ns), second (s), terabyte (TB)

10. **Quoted text**
    Terms that refer to texts that you cannot change in code documentation. For example, error messages, code snippets, UI labels, and log output.
    `Cannot read properties of undefined`, `ENOENT: no such file or directory`, `Submit` button, `404 Not Found`, `connection refused`

11. **Professional roles, teams, and organizations**
    Terms that refer to roles, individuals, organizations, and teams related to software development.
    administrator, backend developer, contributor, DevOps engineer, frontend developer, Google, maintainer, Microsoft, product owner, QA engineer, reviewer, scrum master, user

12. **Official documents, API references, and standards**
    Terms that refer to documentation types, standards, specifications, and their structural parts.
    API reference, changelog, code of conduct, contributing guide, diagram, figure, Getting Started guide, HTTP specification, note, paragraph, README, release notes, RFC, section, table, warning

13. **Runtime environments and operational conditions**
    Terms that refer to execution contexts, environment variables, and operating parameters.
    development, environment variable, garbage collection, heap, hot reload, live reload, memory leak, production, sandbox, stack trace, staging, test, thread, timeout, virtual machine

14. **Colors**
    Terms that refer to colors that identify color-related properties in code (for example, CSS, terminal output, syntax highlighting).
    black, blue, cyan, gray, green, magenta, orange, red, white, yellow
    Colors are adjectives, but STE-Code identifies them as code-domain technical nouns. Comparative and superlative forms of colors (for example, blacker, the reddest) are not permitted in STE-Code.

15. **Defects, errors, and fault terminology**
    Terms that refer to types of software defects, errors, and malfunctions.
    assertion failure, bug, crash, deadlock, defect, exception, hang, infinite loop, memory leak, null pointer, race condition, regression, stack overflow, timeout, type error

16. **Computer science, information, and communication technology**
    Terms that refer to concepts, technologies, and architectures in computing and communication.
    AI, algorithm, authentication, authorization, blockchain, containerization, cryptography, database, encoding, encryption, firewall, hashing, internet, machine learning, metadata, neural network, protocol, query, sandbox, schema, token, virtualization

17. **Legal and licensing terms**
    Terms that refer to software licenses, legal documents, and compliance terminology.
    Apache 2.0, BSD license, compliance, copyright, GPL, license, MIT license, open source, proprietary, terms of service, third-party, trademark, warranty

18. **Database and storage terminology**
    Terms that refer to database concepts, storage systems, and data persistence.
    connection pool, cursor, foreign key, index, migration, NoSQL, ORM, PostgreSQL, primary key, query, Redis, relation, row, schema, seed, SQL, SQLite, stored procedure, table, transaction, view

19. **Network and protocol terminology**
    Terms that refer to networking concepts, protocols, and communication.
    DNS, endpoint, HTTP, HTTPS, IP address, localhost, middleware, packet, port, request, response, route, socket, SSH, TCP, TLS, UDP, URL, VPN, WebSocket

The code-domain technical nouns in their related categories are only examples. Rule 1.5 does not give a full list of all possible code-domain technical nouns.

### Examples

> **Non-STE:** The developer used the thing to get data from the storage layer and put it on the screen.
>
> **STE:** The frontend developer used the API client to get data from the database and show it on the UI.

> *Adapted from spec concept: technical nouns give precision to documentation. Just as STE uses categories like "Vehicles or machines" and "Tools and support equipment" to classify aerospace nouns, STE-Code uses categories like "Professional roles" (frontend developer), "Computer science" (API client, database), and "Interface elements" (UI) to classify code-domain nouns. The non-STE version uses imprecise words ("thing," "storage layer," "screen") that are not clearly identified as technical nouns.*

## Code-Domain Explanation

This rule is the primary mechanism for introducing domain-specific vocabulary into STE-Code documentation. The nineteen categories define the boundaries within which you may use technical nouns that are not in the approved STE-Code dictionary. Without this rule, all code-domain terminology would be forbidden, and documentation would become unusable.

### Application by Documentation Type

**README files.** A README introduces a project and describes its purpose, installation, and usage. Use technical nouns from categories 1 (code components), 3 (development tools), 5 (infrastructure), and 17 (legal terms). For example, "This package provides a middleware for Express" uses three code-domain technical nouns — package (category 1), middleware (category 1), and Express (category 5). Each noun names a precise concept that no STE-Code approved word can replace.

**API documentation.** API docs describe endpoints, parameters, return types, and error codes. Use technical nouns from categories 6 (systems), 18 (database), and 19 (network). An API endpoint description such as "The GET /users/:id route returns a JSON object with a user struct" uses route (category 19), JSON (category 4), and struct (category 4). These terms are the subject of the documentation and must appear verbatim.

**Docstrings and inline comments.** Docstrings explain what a function, class, or module does. Use technical nouns from categories 4 (data types), 7 (algorithms), and 15 (defects). A Python docstring such as "Traverse the binary search tree in-order and return a sorted array" uses binary search tree (category 7), in-order (category 7), and array (category 4). The nouns are essential to describe the algorithm correctly.

**Commit messages.** Commit messages record what changed and why. Use technical nouns from categories 1 (code components), 15 (defects), and 18 (database). A commit message such as "Fix race condition in the connection pool that caused a deadlock on PostgreSQL" uses race condition (category 15), connection pool (category 18), deadlock (category 15), and PostgreSQL (category 18). These nouns identify the exact change.

**Error messages.** Error messages report failures to users and developers. Use technical nouns from categories 13 (runtime), 15 (defects), and 19 (network). An error message such as "Connection refused: the TCP socket on port 5432 timed out after 30 seconds" uses TCP (category 19), socket (category 19), port (category 19), and seconds (category 9). These nouns give the user actionable information.

### Distinction from Rule 1.1 (Approved Words)

Rule 1.1 requires the use of approved words from the STE-Code dictionary for all common vocabulary. Rule 1.5 is the complement: it permits words outside the dictionary when they name a technical concept. The two rules work together. Use an approved word whenever one exists. Use a code-domain technical noun when no approved word names the concept.

### Distinction from Rule 1.6 (Non-Approved Words Only as Technical Nouns)

Rule 1.6 prohibits all non-approved words except those permitted under Rule 1.5. Rule 1.5 defines what qualifies. Together, Rules 1.5 and 1.6 form a gate: a non-approved word must belong to at least one of the nineteen categories to appear in STE-Code documentation. If the word is neither an approved word (Rule 1.1) nor a code-domain technical noun (Rule 1.5), Rule 1.6 forbids it.

### Requirement: Glossary Registration

ASD-STE100 requires that every technical noun a project uses be registered in the company glossary. STE-Code inherits this requirement. Before you use a code-domain technical noun in documentation, add it to the project glossary or terminology database. The glossary entry must specify:

- The noun term.
- The STE-Code category (or categories) it belongs to.
- The approved meaning in the project context.
- An example sentence that uses the noun correctly.

A project that does not maintain a glossary risks ambiguity: the same noun may mean different things to different readers, which violates P11 (one term per concept).

## Paradigm-Specific Guidance

### Object-Oriented Paradigm (Java, C++, C#, Python classes)

In OOP documentation, use technical nouns from categories 1 (code components), 4 (data types), and 6 (systems). Class names, method names, interface names, and design pattern names are code-domain technical nouns. They do not require translation to approved words.

Acceptable: "The `UserRepository` class extends the `BaseRepository` abstract class and implements the `IAuditable` interface."
Explanation: `UserRepository`, `BaseRepository`, and `IAuditable` are code components (category 1). `abstract class` and `interface` are computer science terms (category 16).

Acceptable: "The factory method pattern decouples the object creation logic from the client."
Explanation: `factory method pattern` is a design pattern (category 6). `object` is a data structure (category 4). `client` is a system component (category 6).

Not acceptable: "The repo leverages the base to retrieve user data." (Uses non-approved "leverage" — use "use". Uses informal abbreviation "repo" — use full technical noun "repository".)

### Functional Paradigm (Haskell, Elixir, Clojure, Rust)

In functional programming documentation, use technical nouns from categories 7 (algorithms), 4 (data types), and 16 (computer science). Terms such as monad, functor, closure, currying, pattern matching, recursion, and immutability are code-domain technical nouns.

Acceptable: "The function returns an `Option` monad. Use pattern matching to extract the value."
Explanation: `Option` is a data type (category 4). `monad` is a computer science concept (category 16). `pattern matching` is an algorithmic term (category 7).

Acceptable: "The `fold` function applies a binary operation to each element of the list and accumulates the result."
Explanation: `fold` is an algorithmic term (category 7). `binary operation` is a mathematical term (category 7). `list` is a data structure (category 4).

Not acceptable: "The combinator stuff chains stuff together to make new stuff." (No recognized technical nouns. Replace with specific terms: parser combinator, function, pipeline.)

### Procedural Paradigm (C, Go, Bash)

In procedural code documentation, use technical nouns from categories 4 (data types), 13 (runtime), and 19 (network). Terms such as pointer, struct, mutex, goroutine, channel, file descriptor, and signal are code-domain technical nouns.

Acceptable: "The C function accepts a pointer to a `FILE` struct and returns an integer status code."
Explanation: `pointer` is a data type (category 4). `FILE` is a code component (category 1). `struct` is a data structure (category 4). `integer` is a data type (category 4).

Acceptable: "The Go goroutine reads from the channel. The mutex prevents a race condition."
Explanation: `goroutine` is a runtime term (category 13). `channel` is a data structure (category 4). `mutex` is a computer science term (category 16). `race condition` is a defect term (category 15).

Not acceptable: "The script fires off a subprocess to crunch the numbers." (Uses non-approved "fires off" — use "starts". "crunch" is jargon — use "process".)

### Declarative Paradigm (SQL, Terraform, Kubernetes YAML)

In declarative documentation, use technical nouns from categories 18 (database), 5 (infrastructure), and 12 (official documents). Terms such as SELECT, JOIN, resource, module, provider, pod, deployment, and namespace are code-domain technical nouns. YAML keys and SQL keywords are quoted text (category 10) when referenced verbatim.

Acceptable: "The `SELECT` statement uses an `INNER JOIN` on the `users` and `orders` tables. The query returns a result set."
Explanation: `SELECT` and `INNER JOIN` are quoted text (category 10). `users` and `orders` are database terms (category 18). `result set` is a database term (category 18).

Acceptable: "The Terraform `resource` block declares an AWS EC2 instance. The `provider` block configures the AWS region."
Explanation: `resource` and `provider` are infrastructure terms (category 5). `AWS`, `EC2`, and `region` are infrastructure terms (category 5).

Not acceptable: "K8s spins up a bunch of pods inside the thing." (Uses informal "K8s" — use "Kubernetes". Uses non-approved "spins up" — use "starts". Uses imprecise "thing" — use "namespace".)

### Systems Programming (Rust ownership, C memory management)

In systems documentation, use technical nouns from categories 13 (runtime), 4 (data types), and 15 (defects). Terms such as ownership, borrow, lifetime, stack, heap, allocation, deallocation, undefined behavior, and segmentation fault are code-domain technical nouns.

Acceptable: "The Rust compiler enforces the ownership rules. The borrow checker prevents dangling pointers at compile time."
Explanation: `ownership` and `borrow checker` are computer science terms (category 16). `dangling pointers` is a defect term (category 15). `compile time` is a runtime term (category 13).

Acceptable: "The `malloc` function allocates memory on the heap. The caller must call `free` to prevent a memory leak."
Explanation: `malloc` and `free` are code components (category 1). `heap` is a runtime term (category 13). `memory leak` is a defect term (category 15).

Not acceptable: "Rust's thingy stops you from shooting yourself in the foot with memory stuff." (Uses informal "thingy" and "stuff" — replace with "ownership system" and "memory errors". Uses idiom "shooting yourself in the foot" — forbidden by P10.)

## Extended Examples

### Example Group 1: API Documentation

> **Non-STE:** The endpoint leverages the middleware to authenticate the request and then kicks off a background job to crunch the data.
>
> **STE:** The endpoint uses the authentication middleware to check the request. The endpoint then starts a background job to process the data.

- **Principle applied:** P1 (use approved words: "use" instead of "leverage", "check" instead of "authenticate", "start" instead of "kicks off", "process" instead of "crunch")
- **Category mapping:** authentication middleware (category 16), background job (category 13), endpoint (category 19)
- **Explanation:** The non-STE version uses "leverage" (not approved), "kicks off" (jargon), and "crunch" (jargon). The STE version replaces these with approved verbs and keeps the code-domain technical nouns.

### Example Group 2: README Installation Instructions

> **Non-STE:** First, snag the repo and then cd into it. After that, fire up the dev server.
>
> **STE:** First, clone the repository. Then, change to the repository directory. After that, start the development server.

- **Principle applied:** P1 (use approved words: "clone" is a technical verb per P12, "change" instead of "cd", "start" instead of "fire up"), P10 (no slang: "snag" is informal)
- **Category mapping:** repository (category 1), development server (category 5)
- **Explanation:** The non-STE version uses slang ("snag"), a shell command as a verb ("cd into"), and jargon ("fire up"). The STE version uses the technical verb "clone" (permitted by P12) and approved verbs.

### Example Group 3: Commit Message

> **Non-STE:** Bumped deps and fixed the wonky timeout thing that was breaking prod.
>
> **STE:** Update dependencies. Fix a timeout defect in the connection pool that caused a crash in production.

- **Principle applied:** P1 (use approved words: "update" instead of "bumped"), P10 (no jargon: "wonky" is informal, "prod" is informal), P11 (one term per concept: "defect" instead of "thing")
- **Category mapping:** dependencies (category 1), timeout (category 13), connection pool (category 18), crash (category 15), production (category 13)
- **Explanation:** The non-STE version uses informal language ("bumped", "wonky", "thing", "prod"). The STE version identifies each problem with a precise code-domain technical noun.

### Example Group 4: Error Message

> **Non-STE:** Oops! Something went sideways when the DB tried to do its thing.
>
> **STE:** Error: The PostgreSQL connection pool could not get a connection. The TCP socket timed out after 30 seconds.

- **Principle applied:** P1 (use approved words), P10 (no slang: "went sideways", "do its thing"), P11 (one term per concept: name the specific component)
- **Category mapping:** PostgreSQL (category 18), connection pool (category 18), TCP socket (category 19), 30 seconds (category 9)
- **Explanation:** The non-STE version is vague and unprofessional. The STE version names the exact system, the exact component, and the exact timeout value. Users can act on this information.

### Example Group 5: Docstring for a Function

> **Non-STE:** This guy walks the tree and yanks out all the nodes that match the predicate.
>
> **STE:** Traverse the binary search tree. Return a list of nodes that match the predicate function.

- **Principle applied:** P1 (use approved words: "return" instead of "yanks out"), P10 (no slang: "this guy", "walks", "yanks out"), P11 (one term per concept: "traverse" is the standard term for tree navigation)
- **Category mapping:** binary search tree (category 7), nodes (category 4), list (category 4), predicate function (category 7)
- **Explanation:** The non-STE version uses anthropomorphic and informal language. The STE version uses standard algorithmic terminology.

### Example Group 6: Configuration File Comment

> **Non-STE:** Tweak this knob if you want the thing to go faster but be careful not to blow up the memory.
>
> **STE:** Increase this value to reduce the response time. WARNING: Large values can cause a memory leak.

- **Principle applied:** P1 (use approved words: "increase" instead of "tweak"), P10 (no slang: "knob", "blow up"), P11 (one term per concept: "response time" instead of "go faster")
- **Category mapping:** response time (category 7), memory leak (category 15)
- **Explanation:** The non-STE version uses metaphors ("knob", "blow up") that do not convey technical meaning. The STE version states the effect precisely and adds a warning about the defect.

## Edge Cases

### Edge Case 1: Framework Names That Are Also Common Words

Some frameworks use common English words as names (for example, React, Vue, Swift, Go, Rust, Elm, Next, Nest). When the framework name also exists as an approved word, context decides the reading. In STE-Code, the framework name is a code-domain technical noun (category 3 or 5) and does not need to follow the approved meaning.

Acceptable: "Use the React framework to build the user interface."
Explanation: `React` is a development tool (category 3). It is not the verb "react" from the dictionary.

Acceptable: "The Go compiler builds the binary."
Explanation: `Go` is a development tool (category 3). It is not the verb "go".

When a sentence is ambiguous without capitalization (for example, "use swift to process the data"), always capitalize framework names or use the full term ("the Swift language", "the Rust compiler") to distinguish them from approved words.

### Edge Case 2: Code Keywords Inside Documentation

Code keywords (`if`, `else`, `for`, `while`, `return`, `class`, `def`, `fn`, `let`, `const`, `var`, `async`, `await`) are quoted text (category 10) when they appear in documentation. They do not need to be technical nouns because they are part of the quoted text category. However, when you use them as English words in a sentence, they must follow approved meanings.

Acceptable: "The `if` statement checks the condition."
Explanation: `if` is quoted text (category 10). The surrounding sentence uses approved words.

Not acceptable: "If the request fails, return a 500." (Missing backticks around `500` — `500` is an HTTP status code, which is quoted text or a number.)

Acceptable: "If the request fails, return `500 Internal Server Error`."
Explanation: The status code is quoted text (category 10).

### Edge Case 3: Abbreviations and Acronyms

Code-domain technical nouns often appear as abbreviations or acronyms (API, JSON, SQL, HTML, CSS, HTTP, TCP, TLS, DNS, URL). These are permissible under Rule 1.5 as technical nouns in categories 16, 18, or 19. However, you must define each abbreviation at its first use in a document, unless the abbreviation is universally understood by the target audience.

Acceptable (first use): "The application programming interface (API) uses Hypertext Transfer Protocol Secure (HTTPS)."
Acceptable (subsequent use): "The API returns a JSON response over HTTPS."

Not acceptable: "The API leverages HTTPS to transmit the payload." (Uses non-approved "leverage" — use "use". Non-approved "transmit" — use "send". Non-approved "payload" — use "data" or define as a technical noun.)

### Edge Case 4: Generated Code and Auto-Generated Documentation

Generated code (for example, OpenAPI specs, protobuf stubs, database migration files) and auto-generated documentation (for example, JSDoc output, Sphinx output) are not required to follow STE-Code rules because a machine, not a human, produces them. However, any human-written comments, descriptions, or annotations inside generated files must follow STE-Code.

Acceptable (generated): `// @ts-expect-error TS1234 — The generated type is incompatible with the runtime type.`
Explanation: The human-written comment follows STE-Code. The generated code itself is exempt.

Not acceptable (human-written comment in generated file): `// this hack works around a funky TS bug`
Explanation: The comment uses non-approved "hack" (use "workaround"), jargon "funky" (use "known defect"), and informal abbreviation "TS" (use "TypeScript").

### Edge Case 5: Project-Specific Internal Names

Projects often name internal components with made-up words, code names, or branded terms (for example, "Project Nightfall", "Hammerhead subsystem", "PhoenixCache"). These are permissible as code-domain technical nouns under category 1 (code components) or category 6 (systems) if they appear in the project glossary. Without glossary registration, such names are non-approved words and violate Rule 1.6.

Acceptable (with glossary): "The PhoenixCache layer stores frequently accessed data in memory."
Explanation: `PhoenixCache` is registered in the project glossary under category 6 (systems).

Not acceptable (without glossary): "The PhoenixCache layer stores frequently accessed data in memory."
Explanation: `PhoenixCache` is not in the glossary. Readers cannot know what it means. Add it to the glossary first.

## Grammar Notes

### Technical Nouns and Articles

In ASD-STE100, technical nouns follow the same article rules as approved nouns. Use "the" for specific instances, "a" or "an" for indefinite instances, and no article for plural general references. This rule applies identically in STE-Code.

Acceptable: "The `UserController` handles a request. The controller returns a response."
Explanation: `UserController` is a specific code component (category 1). `request` and `response` are network terms (category 19).

Acceptable: "Kubernetes pods run in a namespace."
Explanation: `Kubernetes` is a platform (category 5). `pods` is a plural general reference (category 5). `namespace` is an infrastructure term (category 5).

### Technical Nouns as Modifiers

In ASD-STE100, a technical noun can modify another noun to form a compound technical noun phrase. This is common in code documentation. When two technical nouns form a compound, the first noun functions as a modifier and the second as the head noun. Both must belong to a recognized category.

Acceptable: "The Redis cache server stores the session data."
Explanation: `Redis` (category 18) modifies `cache server` (category 6). `session data` is a compound where `session` (category 13) modifies `data` (category 4).

Acceptable: "The PostgreSQL connection pool uses a round-robin scheduler."
Explanation: `PostgreSQL` (category 18) modifies `connection pool` (category 18). `round-robin` (category 7) modifies `scheduler` (category 6).

Not acceptable: "The thing layer processes the stuff queue." (Neither "thing" nor "stuff" is a recognized technical noun.)

### Technical Nouns and the Possessive Form

ASD-STE100 permits the possessive form (`'s`) only for professional roles, organizations, and geopolitical entities (category 11 in STE-Code). Do not use the possessive form with other categories of technical nouns. Use "of" constructions or noun-as-modifier constructions instead.

Acceptable: "The user's session data is encrypted." (Category 11 permits possessive.)
Acceptable: "The configuration of the Docker container is stored in a YAML file." (Category 5, use "of" construction.)
Not acceptable: "The Docker container's configuration is stored in a YAML file." (Category 5 does not permit possessive.)

### Technical Nouns and Pluralization

Technical nouns follow standard English pluralization rules. Acronyms and initialisms form plurals by adding a lowercase "s" without an apostrophe.

Acceptable: "The system uses two APIs and three SQL queries."
Explanation: `APIs` is the plural of `API` (category 19). `queries` is the plural of `query` (category 18).

Not acceptable: "The system uses two API's and three SQL's."
Explanation: The apostrophe in `API's` and `SQL's` incorrectly suggests possession. Use `APIs` and `SQL queries`.

### Technical Nouns and Capitalization

Code-domain technical nouns that are proper nouns (for example, programming language names, company names, product names) keep their original capitalization. Common technical nouns (for example, controller, endpoint, middleware) use lowercase unless they appear as the first word in a sentence.

Acceptable: "The TypeScript compiler checks the types. The controller handles the request."
Explanation: `TypeScript` is a proper noun (category 3). `controller` is a common technical noun (category 1).

Not acceptable: "The typescript compiler checks the Types. The Controller handles the request."
Explanation: `typescript` should be `TypeScript`. `Types` and `Controller` should be lowercase (not first word, not proper nouns).

## Cross-References

- **Rule 1.1 (Approved Words):** Rule 1.1 lists the approved words you must use for all common vocabulary. Rule 1.5 describes the exception: you may use non-approved words if they are code-domain technical nouns. See Rule 1.1 for the complete approved-word dictionary.
- **Rule 1.2 (Part of Speech):** Code-domain technical nouns must be used only as nouns (or noun modifiers). Do not use a technical noun as a verb. See Rule 1.2 for the full restriction on parts of speech.
- **Rule 1.3 (Approved Meanings):** Code-domain technical nouns have the meaning registered in your project glossary. Do not use them with alternative meanings. See Rule 1.3 for the full restriction on approved meanings.
- **Rule 1.4 (Verb and Adjective Forms):** Technical nouns do not have verb forms. If a word that is a technical noun also has a verb form in the dictionary, use the approved verb form for actions and the technical noun form for naming concepts. See Rule 1.4.
- **Rule 1.6 (Non-Approved Words):** Rule 1.6 forbids all non-approved words that are not code-domain technical nouns. Rule 1.5 defines which words qualify. Read Rules 1.5 and 1.6 together.
- **Rule 1.7 (Technical Nouns as Verbs):** A word that is a code-domain technical noun cannot be used as a verb. For example, "host" is a technical noun (category 5); the approved verb is "make available" or "run". See Rule 1.7.
- **Rule 1.8 (Standard Technical Nouns):** Use well-known, widely accepted technical nouns. Do not invent new terms when a standard term exists. See Rule 1.8.
- **Rule 1.9 (Short Technical Nouns):** Prefer short, clear technical nouns over long, obscure ones. See Rule 1.9.
- **Rule 1.11 (One Term per Concept):** Each code-domain technical noun must refer to exactly one concept in your project. Do not use the same noun for two different concepts. See Rule 1.11.
- **Rule 1.12 (Technical Verbs):** Technical verbs (build, deploy, test, lint, compile, debug) are permitted. They are not technical nouns. Do not confuse the two categories. See Rule 1.12.

## Summary

Rule 1.5 is the gateway for all domain-specific vocabulary in STE-Code documentation. It permits you to use words outside the approved dictionary when those words name a precise concept in one of the nineteen code-domain categories. The rule requires discipline: register every technical noun in your project glossary, use each noun only with its registered meaning, and do not use technical nouns as verbs. When you follow Rule 1.5 together with Rules 1.1 and 1.6, your documentation uses only two kinds of words: approved STE-Code words for common vocabulary, and code-domain technical nouns for domain-specific concepts. There is no third category.
