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 reference 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 immutable versioned copies live under /api/v0.1.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, choosing one canonical term for one concept means that writers, readers, and agents no longer have to guess whether start, begin, initialize, and launch describe different state 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 over variation

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

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

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, 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.