Desirable Properties ChallengeDP Challenge
← How Version 1.0 gets made

Desirable Properties · Version 1.0

Style guide

Twenty-three workgroups write one book. This guide keeps it reading as one book: who we write for, the voice, how requirements are worded, and how to write a patch or insert that fits. Most rules record what the chapters already do; the rest settle where chapters disagree.

Version 1.0 · updated Oct 13

Who we write for

Community members, builders, designers and policymakers read the same chapter. Many are technical, many are not, and many read English as a second language. Write so each of them can follow the argument.

  1. Use plain words. When a technical term is the right word, define it the first time it appears in the chapter.

    Do:Sybil attacks – one person running many fake accounts – are cheap at web scale.

    Don’t:Sybil resistance is required.

  2. Spell out an abbreviation on first use in each chapter, then use the short form.

    Do:Reinforcement Learning and Adaptive Dynamic Programming (RLADP) …

  3. One idea per paragraph. Keep most sentences under 25 words; split any sentence over 35.

    Half the sentences in the book are 14 words or fewer. The long ones are where readers get lost.

  4. Give a concrete example for each abstract mechanism. Say when an example is hypothetical.

    Do:For example, a neighborhood forum could require proof of humanity to post but not to read.

Voice

The book speaks in one voice: calm, precise, third person, present tense. A reader should not be able to tell where one contributor’s text ends and another’s begins.

  1. Write in the third person. Do not use “I”, “we” or “you” in chapter text.

    Do:Participants can leave a zone and take their history with them.

    Don’t:We believe you should be able to leave and take your history with you.

  2. Say “participants” for people who use the Meta-Layer. Use “users” only when quoting or describing another system’s users.

    The book already says participants more than five times as often as users; the word signals agency.

  3. Use the present tense for what the Meta-Layer does or requires.

    Do:Authentication answers the question of who may enter.

    Don’t:Authentication will answer the question of who may enter.

  4. State limits honestly. Prefer a qualified claim to a confident one that overreaches.

    Do:Containment may be partial, contextual, and imperfect, but it must never be misrepresented as stronger than it is.

  5. No marketing language: avoid words such as revolutionary, seamless, game-changing, unprecedented and cutting-edge.

Requirements: MUST, SHOULD, MAY

Version 1.0 feeds the ML-REQs in December, so the book must make clear which sentences are requirements. The keywords follow RFC 2119 and RFC 8174.

  1. Use capital MUST, MUST NOT, SHOULD, SHOULD NOT and MAY only for requirements. Lowercase must, should and may are ordinary English.

    Today the book has 241 capital MUSTs and 652 lowercase ones, and readers cannot tell which are binding.

  2. Each requirement names who it applies to and can be checked. If it cannot be checked, make it guidance in lowercase.

    Do:A zone MUST publish its access rules before it admits participants.

    Don’t:Systems MUST be trustworthy.

  3. One requirement per sentence.

  4. Requirements belong in Primary Mechanisms and Structural Conditions and in Minimum DPn Alignment. A section marked “(Non-Normative)” contains no capital keywords.

    Twelve chapters use capital keywords 115 times inside sections headed “(Non-Normative)”, which contradicts the heading.

  5. Do not change a requirement’s strength (MUST to SHOULD, or the reverse) without saying so in the proposal’s rationale.

Chapter structure

Every chapter follows the DP chapter template, so a reader who knows one chapter can find their way in any other.

  1. Keep the template’s order: Purpose of This Draft, Problem Statement, Threats and Failure Modes, Core Principle, Primary Mechanisms and Structural Conditions, then the optional and DP-specific sections, then the six closing sections.

  2. The six closing sections are required in every chapter: Relationship to Other Desirable Properties, Non-Goals and Explicit Boundaries, Minimum DPn Alignment, Open Questions and Future Work, Path Toward ML-RFC, and Closing Orientation.

  3. Under the title, keep a one-line italic tagline written for participants.

    Do:*The Conditions for Trust – strong, federated authentication and decentralized accountability are the foundations for real trust, safe interaction, and meaningful community.*

  4. Number every section (## 7.) and subsection (### 7.2). A new section takes the next number in its place and the sections after it are renumbered.

  5. Put new material where it belongs once. If an idea already appears elsewhere in the chapter, extend that passage instead of adding a second one.

    Synthesis, not stacking: restating a point in several places weakens the book.

Headings

Section headings use title case; subsection headings use sentence case, as most chapters already do.

  1. Section headings (##) in title case.

    Do:## 7. Sociotechnical Zones as Trust Contexts

  2. Subsection headings (###) in sentence case: capitalize the first word and proper nouns only.

    Do:### 7.5 Privacy-preserving community discovery

    Don’t:### 7.5 Privacy-Preserving Community Discovery

  3. Keep headings short and descriptive. No full stop at the end, and no question marks unless the section answers that question.

Terms and spelling

Use one spelling for each term across the book. American English.

  1. American spelling: behavior, organization, center, license (noun and verb).

  2. “the Meta-Layer” is a proper noun when it means the layer this book describes; “a meta-layer” is the general idea.

    Do:Data sovereignty in the Meta-Layer requires that …

    Don’t:Data sovereignty in the meta-layer requires that …

  3. Desirable Property, capitalized; spell it out with the number on first use in a chapter, then use the short form with no space.

    Do:Desirable Property 4 (DP4) … DP4 …

    Don’t:DP 4, Dp4, desirable property 4

  4. Fixed forms: AI; AI agent; human and AI agents; sociotechnical; decision-making; online; email; the web (lowercase); ML-Draft; ML-RFC; ML-REQ; Gov Hub; Canopi.

  5. Hyphenate compound terms only when they come before a noun.

    Do:Zones may require proof of humanity. A proof-of-humanity check …

Punctuation and formatting

Formatting should help a reader scan, not shout.

  1. Use a spaced en dash ( – ) for an aside or a break in a sentence. Not an em dash (—) or two hyphens (--).

    The book mixes the two about equally (91 en dashes, 103 em dashes). Titles and the site already use the en dash.

  2. Use the serial (Oxford) comma.

    Do:identity, accountability, and governance

  3. Bold a term where it is defined, or the one key claim of a section. At most one bold phrase per paragraph.

    The book has more than 2,100 bold phrases; when everything is bold, nothing stands out.

  4. Italics for the chapter tagline, section taglines and words used as words. Not for emphasis.

  5. Bulleted list items are parallel in form. Fragments take no full stop; full sentences do.

  6. Numbers: spell out one to nine; use numerals from 10. Dates as November 13, 2026.

Cross-references

Point to other passages instead of repeating them.

  1. Refer to a section in the same chapter as “Section 7.2”. Do not use §.

    Do:Anonymous participation remains subject to the zone boundaries in Sections 7 and 18.

  2. Refer to another chapter as “DP4, Section 5”, and summarize the point in a few words rather than restating it.

  3. When two DPs both cover an idea, it lives fully in one. The other chapter gives one or two sentences and the cross-reference.

Evidence and sources

A chapter mixes two kinds of claim: what the Meta-Layer should do (design), and what is true of the world (fact). Facts need sources.

  1. Support every factual claim about the world – a statistic, an incident, a law, a study – with a source.

    The chapters currently cite no sources; reviewers have asked where claims come from.

  2. Cite with an inline link on descriptive text. No bare URLs.

    Do:[EU AI Act, Article 50](https://…) requires providers to disclose …

    Don’t:See https://… for details.

  3. Design statements need no citation, but should say why. Mark an example as hypothetical when it is.

Writing a patch or insert

A proposal is read twice: by co-editors deciding on it, and later by readers who never see that it was a proposal. Write the text exactly as it should appear in the book.

  1. Match the voice and terms of the surrounding passage, so the result reads as one text.

  2. The proposed text stands on its own. Do not write “this patch adds”, “as suggested above” or “I propose”.

    Do:A zone MUST publish its access rules before it admits participants.

    Don’t:I propose adding that zones should publish their rules.

  3. Put the reasons, sources and context in the rationale field, not in the proposed text.

  4. One idea per proposal. Two unrelated changes are two proposals.

    Co-editors can then approve one and decline the other.

  5. Check the chapter first. If the idea is already there, patch that passage instead of inserting a new one.

  6. Keep a proposal in proportion to the passage it changes. A long insert into a short section usually belongs in its own subsection.

  7. If an AI tool drafted the wording, say so in the rationale. A person is still responsible for it.

    AI assists; people decide, and AI-drafted text is labelled.

For co-editors

The guide helps you decide; it is not a reason to turn down a good idea.

  1. Judge a proposal first on substance: is it right, does it belong in this DP, does it duplicate something?

  2. Do not decline a sound proposal for style alone. Fix the style when you integrate it, or ask the author to revise, and say which rule applies.

  3. When you decline, name the reason in a sentence the author can act on. Cite the rule by its section here when style is part of it.

    Do:Declined: this restates DP14, Section 6. A one-line cross-reference there would cover it (style guide: Cross-references).

Questions or a rule that does not work for your chapter? Raise it at the Monday session or in your workgroup chat; changes to this guide are agreed there and dated above.