Examples

These examples apply FTL to real Fenexity-style technical prose. Each one shows a “before” version and a controlled “after” version, and explains what changed.

Example A — vague adjective

Before

The edge solution is more robust.

Ambiguity to resolve

"more robust" does not identify the improved behavior. Does "robust" refer to
operation during loss of cloud connectivity, fault tolerance, recovery time,
availability, or another property?

After, only once the source establishes the intended property

If the cloud connection is unavailable, the edge controller continues to
enforce the site power limit.

What changed: the vague comparative “more robust” is not resolved by invention. The missing semantics are exposed first; the rewrite is valid only after the source defines the intended property (FTL-A08, FTL-T05).

Example B — ambiguous term

Before

The charger reports its status.

Ambiguity to resolve

"charger" is ambiguous: EVSE, charging station, connector, or power electronics?
"status" is also unspecified.

After, only once the intended concept is confirmed

The EVSE reports its operational status.

What changed: neither the concept nor the status type is guessed. The ambiguity is flagged; the rewrite is valid only if EVSE is genuinely the intended concept (FTL-T05).

Example C — modality

Example C shows how ordinary-language modality must not be converted into RFC 2119/8174 modality. See Normative language for the full model.

C1 — could stays could when the meaning is uncertain

Before

The service could retry.

Wrong

The service MAY retry.

Right

The service could retry.

What changed: could expresses uncertain possibility, not normative permission. Uppercase MAY would assert a permission the source does not grant (FTL-T01).

C2 — can stays can when it expresses capability

Before

The service can retry.

Wrong

The service MAY retry.

Right

The service can retry.

What changed: can here expresses capability, not permission. Converting it to MAY reinterprets capability as normative permission (FTL-T01).

C3 — MAY stays MAY when it is already normative

Before (source is already normative)

The service MAY retry.

Wrong

The service can retry.

Right

The service MAY retry.

What changed: uppercase MAY is normative permission in a document adopting RFC 2119/8174. Lowering it to can would lose the normative force (FTL-T01).

C4 — should is not automatically SHOULD

Before

The service should retry.

Wrong

The service SHOULD retry.

Right

The service should retry. (recommendation; upgrade to SHOULD only after confirming normative intent)

What changed: ordinary lowercase should can be a recommendation, expectation, or prediction. RFC uppercase SHOULD is a normative recommendation that requires the RFC convention (FTL-T01).

C5 — an explicit decision may introduce a requirement

Before (proposal)

Proposal: the service should retry after a transient failure.

Wrong (silent strengthening)

The service MUST retry.

Right (decision recorded)

Decision recorded: the service MUST retry after a transient failure.

What changed: a proposal becomes a requirement only when an authorized decision introduces it and that decision is recorded. The transformation must not supply the decision itself (FTL-T01, FTL-T05).

Example D — quantity

Before

The battery has a capacity of 400.

Ambiguity to resolve

"capacity" does not specify whether this is charge capacity or energy capacity.
The unit is also missing.

After, only once the missing information is obtained

The battery has a nominal energy capacity of 400 kWh.

What changed: neither the semantic type (energy capacity vs charge capacity) nor the unit is guessed. The missing semantics are exposed; the rewrite is valid only after the source establishes the quantity and unit (FTL-A09, FTL-T05).

Example E — intent

Before

The dispatcher needs a button to start charging manually.

Structured interpretation

Request:
Provide manual charging control.

Inferred intent:
Enable the dispatcher to recover charging operations when automatic control does not
produce the required operational state.

Status:
The inferred intent requires validation.

What changed: the mechanism (a button) is separated from the intent, which is marked as inferred (FTL-T03).

Example F — meeting summary

German source

Wir wollen eigentlich nur vermeiden, dass morgens irgendein Bus nicht rauskommt,
weil er nicht genug geladen ist.

Controlled summary

Customer intent:
Avoid missed morning departures caused by insufficient vehicle charge.

Open definition:
The required departure-readiness criteria are not yet defined.

What changed: the summary preserves intent and explicitly marks what is still undefined, instead of inventing a requirement.

Example G — noun cluster

Before

charging station site power limit update handling logic

After

logic that handles updates to the site power limit for the charging station

What changed: the ad hoc noun chain is restructured with prepositions and a clause so the relationships between the concepts are explicit (FTL-A15). Established terms such as State of Charge keep their conventional form.

Example H — one obligation per requirement

Before

The system MUST authenticate the user and MUST store the audit record and
MUST return a status code.

After

The system MUST authenticate the user.
The system MUST store the audit record.
The system MUST return a status code.

What changed: three unrelated obligations are split into separate requirements so each is testable and attributable on its own (FTL-A20, FTL-A11).