TEC-005
Hard constraint
layer: section
Prerequisites before steps
IF a task requires permissions, state, tools, knowledge, inputs, or safety conditions, THEN list them before step 1 ELSE state that none are required only when useful.
Why the rule exists
A task can fail before it starts when preconditions are hidden.
Condition
The rule fires when this evaluates true. Paths marked below must be present in the fact base; the engine reports the rest rather than guessing them.
- section.topic_type eq "task"
Facts this rule reads
| Path | Source |
|---|---|
section.topic_type |
You supply it |
Then
- move — target
section.prerequisites - complete — target
section.prerequisites
Else
- retain — target
current_text, No triggering condition is present.
Test cases
TST-014 · [object Object]
- Before
1. Open Settings. Requirement: You need administrator access.- After
Prerequisite: Administrator access. 1. Open Settings.- Reason
- The prerequisite precedes execution.
LAKA
- Smallest sufficient intervention
- Yes
- Primary axes
Sources
-
DITA 1.3 Technical Content Specification — OASIS
link
Topic-based concept, task, reference, troubleshooting, and reuse architecture. -
Technical Writing Process — Kieran Morgan
A repeatable process for planning and producing documentation. -
Developing Quality Technical Information — Michelle Carey; Moira Lanyi; Deirdre Longo; et al.
Quality dimensions for usable technical information.
The raw rule record
Verbatim from 15-technical-writing-rules.json. Also available at /v1/rules/TEC-005.
{
"id": "TEC-005",
"name": "Prerequisites before steps",
"domain": "technical_writing",
"layer": "section",
"strength": "hard_constraint",
"human_logic": "IF a task requires permissions, state, tools, knowledge, inputs, or safety conditions, THEN list them before step 1 ELSE state that none are required only when useful.",
"when": {
"path": "section.topic_type",
"operator": "eq",
"value": "task"
},
"then": [
{
"action": "move",
"target": "section.prerequisites",
"destination": "before_steps"
},
{
"action": "complete",
"target": "section.prerequisites",
"fields": [
"permissions",
"state",
"tools",
"knowledge",
"inputs",
"safety"
]
}
],
"else": [
{
"action": "retain",
"target": "current_text",
"reason": "No triggering condition is present."
}
],
"unless": [],
"because": "A task can fail before it starts when preconditions are hidden.",
"diagnostics": [],
"examples": {},
"source_ids": [
"WEB-008",
"BK-021",
"BK-024"
],
"laka": {
"smallest_sufficient_intervention": true,
"primary_axes": [
"scope",
"depth",
"magnitude",
"reversibility"
]
}
}
Other technical writing rules
- TEC-001 Choose an information type IF a technical topic is being created, THEN classify it as concept, task, reference, troubleshooting, glossary, or mixed with explicit boundaries ELSE do not draft a generic blob. Hard constraint
- TEC-002 Concept answers what and why IF the reader asks what something is or why it matters, THEN use a concept topic with definition, model, relationship, boundary, and example ELSE select another type. Context default
- TEC-003 Task answers how to achieve a goal IF the reader wants to achieve an outcome, THEN use a task topic with goal, prerequisites, steps, results, recovery, and verification ELSE select another type. Context default
- TEC-004 Reference supports lookup IF the reader needs facts about an entity or interface, THEN use stable repeated fields, valid values, defaults, constraints, examples, and links ELSE select another type. Context default
- TEC-006 Imperative starts the step IF the reader performs a procedural action, THEN start with a specific imperative verb and name the object ELSE name the actual actor. Context default
- TEC-007 Expected result follows uncertain action IF a step’s success is not self-evident, THEN state the observable result immediately after it ELSE retain. Context default
- TEC-008 Recovery follows known failure IF a step has a common or consequential failure mode, THEN provide symptom, cause or check, corrective action, and verification ELSE retain. Context default
- TEC-009 Troubleshooting begins with observable symptom IF troubleshooting advice begins with an assumed cause, THEN reframe from the user-observable symptom and branch by tests ELSE retain. Hard constraint