Writing rules
The writing rules are the checkable part of FTL. They are derived from ASD-STE100 and software engineering conventions, but they are written by Fenexity. A small set of high-value rules was chosen deliberately instead of adopting all 53 ASD-STE100 rules; for example, hard word-count limits and the semicolon prohibition were not adopted for software repositories.
These are Fenexity rules derived from ASD-STE100, software-engineering conventions, and normative requirements language (RFC 2119 / RFC 8174). They are Fenexity content, not a reproduction of the ASD-STE100 standard.
FTL-W01 — Use the preferred technical term
When a concept has an established preferred term, use it instead of an alternative that means the same thing.
Avoid
charger / charging device / charging pointPrefer
EVSE (when that is the intended concept)FTL-W02 — Do not introduce synonyms for variation
Technical documentation values semantic stability over prose variety. Do not alternate between equivalent words purely for style.
Avoid
start ... begin ... initiate ... launchPrefer
start (once established)FTL-W03 — Use explicit subjects
State who or what performs an action. Do not rely on implicit or ambiguous subjects.
Avoid
It should then be updated.Prefer
The charging service SHOULD update the charging plan.FTL-W04 — State the condition before the action
When a condition governs an action, state the condition first, then the action.
Avoid
Enforce the local site power limit when the cloud connection is unavailable.Prefer
If the cloud connection is unavailable, the edge controller MUST enforce the local site power limit.FTL-W05 — Use concrete verbs
Express actions as verbs. Avoid nominalization that obscures who does what.
Avoid
The execution of validation occurs after initialization.Prefer
The service validates the configuration after it initializes.FTL-W06 — Avoid vague referents
Review it, this, that, they, former, and latter when more than one referent is possible. Repeat the noun where needed.
Avoid
The EVSE and the vehicle are connected. It starts charging.Prefer
The EVSE and the vehicle are connected. The vehicle starts charging.FTL-W07 — Do not hide requirements in descriptive prose
Separate normative requirements from explanation. Do not bury MUST, SHOULD, or MAY statements in descriptive text.
FTL-W08 — Use measurable properties instead of vague adjectives
Avoid more robust, real-time, efficient, fast, reliable unless the relevant criterion is defined. State the measurable requirement.
Avoid
The system reports faults reliably.Prefer
The system MUST report a blocking charging fault within 10 s after detection.FTL-W09 — Keep units explicit
Do not use a bare number where the physical quantity or unit is necessary for interpretation.
Avoid
Set the limit to 50.Prefer
Set the site power limit to 50 kW.FTL-W10 — Distinguish measurements, derived quantities, and estimates
Do not present an estimate as a measurement or a derived quantity as a direct physical measurement. Label the semantic type when it matters.
Avoid
The battery is at 80%.Prefer
The estimated State of Charge is 80%.FTL-W11 — Preserve source modality
Do not transform can or could into SHOULD or MUST during rewriting or summarization. Keep the modality of the source.
Avoid
The service could retry. becomes The service MUST retry.Prefer
The service could retry. becomes The service MAY retry, if the meaning permits.FTL-W12 — Preserve intent separately from implementation
A requested mechanism is not automatically the underlying requirement. Record the intended outcome and the proposed mechanism separately when they differ.
FTL-W13 — Use RFC normative terms consistently
In normative Fenexity technical documents, use MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY with the meanings defined in RFC 2119 and RFC 8174.
FTL-W14 — Prefer established domain terminology
Use OCPP, IEC, VDV, or software-engineering terminology where it accurately expresses the concept. Invent company terms only when no established term fits.
Avoid
charger for EVSEPrefer
EVSEFTL-W15 — Flag ambiguity instead of silently guessing
If a term has multiple plausible technical meanings in the context, ask for clarification or explicitly state the interpretation you are using.
Avoid
The PLC must be configured.Prefer
The Programmable Logic Controller must be configured. (state the intended meaning)