Writing for Notabenda

Describe the task, action or state the reader needs to understand. A heading such as “Export evidence” or “Storage cleanup after withdrawal” is more useful than a slogan about clarity or control.

Use complete sentences in explanations. Short labels are appropriate for buttons and headings; splitting one idea into several fragments rarely makes it easier to read. Avoid decorative claims such as “thoughtful,” “considered” or “seamless” unless the text explains a specific property.

Use the same terms for the same operations. Distinguish a draft choice, a saved browser preference, a received report and the permission state evaluated by the backend. Explain these differences beside the relevant control or record. Do not repeat a general legal disclaimer in every section.

State what an operation does, then explain limits that affect its use. Name the actual file, size, duration or action where possible. “The report accepts 32 selections” is more useful than “bounded, explicit and reviewable.” Keep warnings about private exports, unverified identity, uncertain delivery and incomplete observations where readers make those decisions.

Documentation should lead with how to use the current API. Put release history, implementation status and outstanding verification in their own sections. Avoid narrating how the feature was built.

Preserve quoted source titles, legal terminology, identifiers and historical evidence. Copy editing must not silently rewrite retained policy HTML or change the wording attached to an existing record. When an offer's wording changes, issue a new revision and preserve prior records.