Fenexity Technical Language

Fenexity Technical Language reduces unnecessary ambiguity in technical communication. It combines controlled technical English with consistent terminology so that humans and software agents can interpret technical information more reliably.

FTL is Fenexity’s public, versioned standard for two things:

1. How Fenexity writes technical English — the writing rules and principles on the Language pages.
2. What Fenexity means by important technical terms — the controlled terminology on the Terminology page.

This site is the canonical published representation. The machine-readable version lives at /api/latest/ftl.json and /api/latest/terms.json, and the immutable v1.0.0 release lives under /api/v1.0.0/.

Why Fenexity uses FTL

Software engineering removes ambiguity from almost everything except prose: type systems, schemas, state machines, linters, and RFC keywords such as MUST and SHOULD. Then ordinary prose quietly reintroduces it:

The service should probably retry appropriately if necessary.

FTL treats controlled technical language as a type system for prose. It cannot make prose formally unambiguous, but it can eliminate a large class of avoidable ambiguity. For example, when the same operation is called start in one place and begin in another, writers, readers, and agents have to guess whether two different state transitions are meant. Calling the same operation start, begin, and commence only for stylistic variation widens the space of plausible interpretations. Using initialize and start as separate terms, in contrast, is correct when initialization and execution are genuinely different system transitions.

The guiding principle:

Reduce accidental ambiguity while preserving meaning, intent, context, and necessary technical complexity.

The core commitment:

One concept, one canonical term. One canonical term, one defined meaning within a given context.

Relationship to ASD-STE100

FTL is informed by ASD-STE100 (Simplified Technical English, Issue 9). ASD-STE100 is an established external specification for controlled technical English, and several of its principles — one approved meaning per term, one term per concept, explicit sentence structure, preconditions before actions — map directly onto software documentation.

FTL is not a copy of ASD-STE100, does not reproduce its controlled dictionary, and does not imply ASD certification or endorsement. FTL selects the ASD-STE100 principles that are high-value for a software organization and combines them with software-engineering terminology, OCPP/IEC/VDV domain terminology, and RFC 2119/8174 normative language.

Precision without semantic loss

Technical documentation values semantic stability over prose variety. Where a concept has an established preferred term, FTL expects that term to be used consistently. Linguistic elegance is subordinate to deterministic interpretation.

FTL prohibits synonym variation only when the different words do not represent a real semantic distinction. Different words are permitted and required when they represent different concepts, states, actions, or transitions. For example, initialize and start must remain distinct terms if initialization and execution are separate system transitions.

This matters for humans. It matters more for AI agents, which evaluate probable interpretations rather than resolving language into one deterministic meaning. Needless synonyms, pronouns, implicit subjects, and unstated conditions all widen the space of plausible interpretations. FTL narrows that space deliberately while preserving every genuine semantic distinction.

FTL does not simplify away complexity

FTL does not attempt to make everything “simple English”. Where a concept is technically complex — for example a state machine, an estimate, or a safety condition — FTL preserves the complexity and instead removes avoidable ambiguity around it. If a term has multiple plausible meanings, FTL asks for context or states the interpretation explicitly rather than silently guessing.

What is published

• Language — principles, writing rules, normative language, general-language vocabulary, German/English policy.
• Terminology — controlled terms with definitions and “distinguish from” guidance.
• Examples — before/after rewrites of real Fenexity-style prose.
• Changelog — version history.
• Machine-readable JSON — the same standard in a form agents can consume.