Multi-User Collaboration and Social Interaction Design Guidelines

For designers and engineers: when two or more people work on the same thing, let each person know what the others are doing without being surveilled, keep one person's input from being silently swallowed by another's operation, and make sure "I undo" always undoes only the step I made.

What multi-user collaboration products do is make one thing belong to several people at once: a document, a canvas, a task, a space. The moment this happens, all the questions a single-user product never has to answer show up at once — is someone else here right now, what are they looking at, what are they editing; who can see this thing right now, and who will be able to see it a second from now; when two people change the same spot at the same time, whose change counts; when I press undo, does it undo my own last step or someone else's; who is responsible for this right now, and who becomes responsible once that person leaves; and, in a place everyone can see, do I still have somewhere to try something out first. These guidelines take effect from the moment a second person appears on the same object.

The most common design mistake in this domain is treating it as a feature checklist for real-time collaborative editing: build multi-cursor, avatar bars, comment bubbles, and edit history one by one, and consider collaboration done. These are mechanisms, not promises. Where real harm actually happens is not on the mechanism checklist — it is when "who has viewed this document" becomes a default feature that no one can turn off, when someone changes the sharing scope from three people to anyone with the link while the three people already inside have no idea, when auto-merge stitches two people's changes into a result that took effect with the wrong meaning, when a new hire presses Ctrl+Z twice and rolls back ten minutes of a senior colleague's work, when the thirty tasks under a departed owner's name are neither transferred nor flagged an error — they just quietly go unwatched. None of these failures are missing features; they are missing rules about consequences.

These guidelines consist of six principles and 40 rules: principles state the design direction; rules specify the applicable situation, behavior requirements, and verification methods. Each rule belongs to exactly one principle, and the rule number is the principle number (C3-2 is the second rule under the third principle). The six principles are split by regulatory object: perceptual information about others during collaboration, the visible scope of content, the arbitration of concurrent edits, the effect and outcome of shared operations, the ownership and handoff of responsibility, and private state and participation choices.

Scope statementThese guidelines constrain the nature of the experiential promises a product makes to users about multi-user collaboration capability and the mechanisms that fulfill them; they do not presuppose a single technical architecture and do not specify a synchronization algorithm, data model, or permission model. They apply to documents, whiteboards, task boards, reviews, and discussions around a shared object, and do not require every product to provide every capability. Adopting these guidelines cannot substitute for the following dedicated assessments and compliance determinations: privacy and personal information protection (member activity records may involve processing of personal information and must be assessed against the target market and feature set), labor and employment monitoring compliance, enterprise information security and access-control technical audits, data retention and e-discovery requirements, and a complete accessibility conformance assessment; this document directly specifies accessibility requirements unique to the collaboration process. Three things explicitly out of scope for these guidelines: content moderation and recommendation ranking on open social platforms (this document only specifies participation, do-not-disturb, and help-seeking boundaries within a collaboration space); an organization's roles, reporting relationships, and performance-management system (these guidelines only govern how responsibility fields are expressed in the product, not how an organization divides labor); and the cryptographic implementation and key management of end-to-end encryption (this document requires that access control actually take effect; it does not specify a cryptographic scheme).

The main text starts with Chapter 0, the task and factual entry point, Chapter 1 the principles, Chapter 2 how to read and quick-reference the rules, Chapter 3 the rules in detail, and Chapter 4 terminology; the verification checklist and evidentiary notes are in Appendices A and B, combined scenarios and acceptance records are in Appendix C, the complete sources are in reference.md, and the configurable items are in Multi-User Collaboration and Social Interaction Design Token.

---

0. Starting from one collaboration task¶

First pick a real task, list the initiator, collaborators, arbiters, external members, and anyone who will be affected, then decide which capabilities are needed. A read-only share does not need to implement edit locks; an ordinary comment does not need to implement formal voting.

Status copy must have evidence. The following are operational facts, not configurable token values; "unknown" and "failed" are each presented as such, and a stale fact must not be used to paper over a missing one.

For every "already ..." on the interface, record the object, evidence source, observation time, and validity boundary separately. When this evidence cannot be provided, use expressions proportionate to the facts, such as "verifying now," "saved on this device only," or "handoff pending."

1. Six principles¶

The six principles split design responsibility by regulatory object: each principle governs the obligations on one category of object, and each rule belongs to the single principle whose regulatory object is its obligation's direct target. Because the objects differ, the principles do not substitute for one another — this is both the basis of the split and how the split is tested.

A single scenario can touch multiple principles at once — a member on a shared board changes a column's filter condition and, in passing, bulk-assigns three cards to the account of a colleague who just left, then presses undo: the product must simultaneously face whether this filter change is a personal or a shared view (C6-3), whether the bulk assignment stated its scope of effect and interruption consequences before execution (C4-4, C4-6), where responsibility goes when the assignee is no longer in the organization (C5-3), and whether this undo reverses only that person's three assignments or also swallows someone else's changes made in the interim (C4-1, C4-2). This is not a miscategorization: these rules constrain obligations on different regulatory objects — one is the default ownership of personal state, one is an operation's scope of effect, one is where responsibility goes, and one is the scope of an undo. Mutual exclusivity and exhaustiveness are claims this split accepts being tested against, not facts established by mere assertion: when a rule's addition, removal, or ownership is in doubt, verify it against the classification check in Appendix A. If the check fails, what gets changed is the principle's split.

The two boundaries in this split that most need ongoing scrutiny are stated here explicitly: C1 and C2 — C1 governs "who gets to see information about a person," C2 governs "the visible scope of content." "Who has viewed this document" touches both sides; it is assigned by the fact that its direct regulatory object is a piece of information about a person — a person's reading act — so it belongs to C1; whereas "who this document is currently visible to" has content's visible scope as its direct regulatory object, so it belongs to C2. C4 and C6 — C4 governs "what effect my operation produced on others," C6 governs "when my state starts being visible to others." The same "I changed it but haven't decided yet": if the question is whether this change has already taken effect and spilled over into someone else's work, it belongs to C4; if the question is that the product simply provides no path to try something without affecting others, forcing people to change shared state directly, it belongs to C6. If these two spots keep producing ownership disputes in practice, the principles should be adjusted rather than adding an intermediate layer.

Principles are for understanding the rules and their ownership; they are not themselves a separate judgment item. When a principle conflicts with the reading of a specific clause, the applicable clause governs, and the ambiguity needing clarification is recorded.

A rule's ownership being singular does not mean a mechanism cannot be reused. A single "change log" can be the basis for operation attribution (C4-3), evidence for conflict adjudication (C3-4), and a safeguard that history is not rewritten after a responsibility handoff (C5-4); a single "subject resolution" mechanism can determine whether visible scope can be ascertained (C2-1), who presence information is shown to (C1-4), and who content belongs to after someone leaves (C5-3). One mechanism serving multiple purposes is the norm; which rule it is written under depends on the direct regulatory object of the obligation.

2. How to read the rules¶

2.1 The structure of each rule¶

One sentence for the force of each part: the rule text states the requirement; Applies to and Boundary conditions together bound the requirement's scope of application; Design application, Verification examples, Counterexamples, and Basis and references add no separate obligation.

A rule states the nature of the behavior, not the implementation: after two people edit the same paragraph at the same time, both people's input still being there and each still being able to recognize which part is their own — that is product behavior; implementing it with operational transformation, conflict-free replicated data types, pessimistic locking, or a three-way merge is an engineering solution — the two must line up, but they are not the same deliverable. These guidelines therefore do not specify a synchronization protocol, data structure, or consistency model.

2.2 Normative terms¶

The rule text uses a three-tier system of normative terms:

• MUST: non-compliant if not satisfied. Without it, some promise made to the user would fail in a foreseeable situation — this is the sole basis for marking something MUST.
• MUST NOT: the negative counterpart at the same strength as MUST, naming behavior that must not occur; "must not" and "forbidden" in the main text are equivalent.
• SHOULD: followed by default; when there is real reason to deviate, record the reason and the alternative, and accept the same verification. Deviation needs no approval, but it needs to be recorded. "Should not" is the negative counterpart of "should."

Compliance is judged clause by clause, taking each independent obligation clause in the main text as the unit: a declarative sentence with no normative term carries the strength of the rule heading it sits under; a clause with an explicit normative term is judged at its own strength — a MUST NOT clause inside a SHOULD rule remains a hard constraint (C2-6, C3-6, C4-6, C5-5, and C6-5 contain such clauses), and strength annotations on rule headings or the quick-reference table do not replace clause-level binding force. "Cannot" in the main text is used only for statements of capability or fact, never to express an obligation.

Strength indicates binding force, not importance.

2.3 The two sides of a counterexample¶

Counterexamples come in two sides: "under-delivery" is missing this requirement; "over-delivery" is turning collaboration into an approval workflow in order to satisfy it. Multi-user collaboration gets built badly densely at both ends: at one end, every move everyone makes is broadcast to everyone in real time, turning the workspace into a surveillance room; at the other end, every change gets a review gate to protect everyone, so two people changing one sentence requires three rounds of notification. Letting people work together and keeping people from harming one another are two faces of the same thing; attending to only one face is not doing it right either way.

One place that is especially easy to over-deliver deserves a special note: more conflict prompts is not better. Treating any two people who touched the same file one after another as a conflict, and popping up a merge screen a dozen times a day, has the same effect as silently discarding input — either way, people stop looking at the prompts.

2.4 Rule quick reference: 40 rules¶

The table below is the one-sentence memorable version of every rule; click a rule's name to jump to its full text in Chapter 3. The quick reference does not substitute for each rule's applicability conditions and complete requirements; a few SHOULD rules contain a forbidding-level clause (C2-6, C3-6, C4-6, C5-5, C6-5) — the main text governs the determination (see 2.2).

C1 Perceiving others has boundaries

C2 Visibility is a property of content

C3 Concurrent edits do not swallow input

C4 A personal operation has an explicit scope of effect

C5 Responsibility has an owner and can be handed off

C6 There is private room within a shared space

3. Rules in detail¶

This chapter expands all 40 rules across the six principles. Each rule's structure and the binding force of each part are given in 2.1; the design applications, verification examples, and counterexamples within them are only explanatory material that helps implementation — they specify no single component and require no separate deliverable document.

3.1 C1 Perceiving others has boundaries¶

Collaboration needs to know what others are doing: knowing a colleague is already editing section three, I don't go edit section three; knowing no one has looked at the proposal, I send another nudge. This kind of information is a source of collaboration efficiency, and it is also the earliest place in this domain to be over-delivered — the same piece of information is collaboration at a coarser grain and surveillance at a finer one. This principle governs how information about other people is generated, at what granularity, to whom, and whether the person being perceived has any room to speak up. It does not govern the visible scope of the content itself — that is C2.

C1-1Presence status comes from a current determinationMUST¶

In one sentence: If the avatar is lit, it should really mean present; if unsure, say unsure.

Applies toproducts that present to a user whether other members are online, on the current object, or immediately reachable.

RuleThe presence status of others presented to a user MUST come from a currently valid determination (at least one of: connection, recent interaction, explicit setting), with the validity period of that determination stated. A valid heartbeat is evidence that belongs to the current connection generation, is sequentially valid, and has not been judged expired; a delayed-arrival buffered packet MUST NOT re-extend an old session's online claim after reconnection. The moment of receipt is used only for local timing on this end; it does not substitute for checking the source's identity and timeliness. Once a determination has expired, it MUST be presented as status unknown or offline — presenting the last-active time directly as current presence is forbidden (see collab.presence.freshness.ttl). A user's explicitly set presence status (busy, do not disturb, invisible) takes precedence over system-detected results; the system is forbidden to override or "correct" a user's explicit setting with a detection result. When presence status is unavailable, it MUST be presented as unknown, and MUST NOT be filled in with a default of online.

Boundary conditionsThis rule does not require real-time detection, nor does it forbid making detection user-triggered refresh; it constrains the consistency between what is presented and the actual determination. Viewing an avatar does not itself renew the period; current presence also does not prove that the specific person is currently paying attention.

Design applicationDesign "offline," "status unknown," and "last active at some time" as three distinguishable presentations, rather than drawing the latter two as the same gray dot. Give "currently on this object" and "in the product but not on this object" separate expressions, since the former's validity period is usually far shorter than the latter's.

Verification examples

• User side: have one member close the client or disconnect, and observe how long it takes for other members to see the status change, and whether they act on it by initiating contact that is now guaranteed to go unanswered.
• Implementation side: check the signal sources and validity-period configuration of the presence determination; verify that an expired status is not served from cache, and that a user's explicit setting is not overridden by a detection result.

CounterexamplesUnder-delivery — a colleague turned off their computer three hours ago, but their avatar's green dot is still lit in the collaborator list, and someone @s them in the document waiting for a reply; over-delivery — to be precise about status, a heartbeat is broadcast to all members every two seconds, turning presence into an activity livestream.

C1-2An account being present does not mean the person is presentMUST¶

In one sentence: The person behind that avatar might not be who you think.

Applies toproducts that use presence status as a basis for contact, assignment, approval, or permission decisions.

RuleThe system is forbidden to assert an account's presence status to other members as evidence that the person is present. Presence produced by shared devices, shared accounts, meeting-room terminals, proxy logins, and automated sessions MUST be distinguishable from personal presence (see collab.presence.identity.mode). An operation requiring the person's own confirmation is forbidden from using presence status alone as evidence of having been made known; activity produced by an Agent or automation acting on someone's behalf MUST be presented in a way that is identifiable as not the person's own operation.

Boundary conditionsThis rule does not require the product to implement identity verification, nor does it forbid using presence as a "worth trying" contact hint; what it forbids is treating presence as "this person already knows" or "this person has agreed."

Design applicationPresent a session on a shared terminal as a device rather than as a person; exclude a long-lived connection maintained by automation from personal presence determination — otherwise a server that never sleeps makes one person permanently online.

Verification examples

• User side: log in with someone's account on a shared meeting-room terminal, and observe whether other members see "someone is online" or "a device is online."
• Implementation side: check the source classification of presence signals; verify that automated sessions do not count toward personal presence.

CounterexamplesUnder-delivery — a colleague's account stays logged in on a shared office display, and the board shows them online all day, so every task gets assigned to them; over-delivery — to make sure it's really the person, every viewing of the collaborator list requires all members to re-verify their identity.

C1-3Perceptual granularity is only enough for collaborationMUST¶

In one sentence: Enough for me to know which part someone is editing — not how many keystrokes they made.

Applies toproducts that present other members' activity information to members.

RuleEvery category of perceptual information MUST be bound to the collaboration problem it is meant to solve, and its granularity MUST NOT exceed what solving that problem requires (see collab.presence.awareness.granularity). Presenting process data such as individual keystrokes, dwell duration, cursor idle time, window-switching behavior, or operation counts per unit time as routine perceptual information toward other members is forbidden. Scenarios that need finer granularity (such as synchronized presentations, paired operation, or incident troubleshooting) MUST be a one-off or time-bounded state explicitly enabled by the perceived party; it MUST NOT be the default. The presentation scope of perceptual information MUST match the parties relevant to that collaboration problem, and MUST NOT be broadcast to members unrelated to the object.

Boundary conditionsThis rule does not forbid presenting information localized to an object and a block, such as "someone is editing this paragraph" or "someone is in this document" — that is exactly the granularity collaboration needs. It also does not constrain data the perceived party sees about themself. Audit and security logs are handled under their own compliance requirements and are not the member-facing perceptual information this rule addresses, but their access is equally subject to the purpose constraint in C1-6.

Design applicationWrite out first "what specific trouble this piece of perceptual information saves someone else," and delete whatever you cannot write out. The same signal can have two granularities: show collaborators "currently on section three," show the person themself "you have been on this for forty minutes" — the latter is not sent out.

Verification examples

• User side: list every piece of activity information in the product that other members can see, and ask of each one, "what concrete problem would collaboration have without it."
• Implementation side: check whether the member-facing perceptual field list is mixed together with the internal instrumentation list; check for undeclared fine-grained activity being consumed by the front end.

CounterexamplesUnder-delivery — the collaboration sidebar shows in real time "Zhang San has been idle for 12 minutes" and "Li Si made 47 edits today"; over-delivery — to avoid any suspicion of surveillance, even "someone is editing this paragraph" is not shown, so two people keep overwriting each other's edits.

C1-4The perceived party can know and control itMUST¶

In one sentence: I should know who is watching my whereabouts, and be able to switch it off.

Applies toproducts that generate and present member activity information to others.

RuleEvery member MUST be able to find out which of their activity information is being presented to whom (see collab.presence.subject.view). The product MUST provide a tier that reduces one's own visibility (at least one tier that presents no real-time presence or location to other members), and adopting that tier is forbidden from causing core collaboration features to become unavailable or from producing a functional penalty (see collab.presence.visibility.self). When a member's activity information is presented to a subject not previously in scope (a new member joins, the scope expands, an export to an external party), the notification requirement of C2-2 MUST be followed.

Boundary conditionsNot presenting real-time presence and location does not mean anonymous collaboration: a member can still see the author of a shared contribution, the holder of a valid lock, and the current responsible party. An organizational policy may mandate controlled auditing, but it cannot cancel the real-time-perception reduction tier required by the main text, or mark using that tier as anomalous. This rule does not exempt the compliance obligation of the record itself: records needed for security auditing are not exempt from retention because a member reduced their visibility — they are simply not presented to other members.

Design applicationMake "who I can see" and "who can see me" two separately viewable lists — most products only build the former. The wording of the reduction tier should state the tradeoff ("others will not be able to see whether you are online, nor know that you are viewing this document"), so the choice is made with full knowledge.

Verification examples

• User side: have a member try to answer "who at the company can see which document I'm currently reading," and record how many steps it takes and whether a definite answer can be obtained.
• Implementation side: after enabling the reduction tier, check whether every interface facing other people indeed stops returning that member's real-time location and presence.

CounterexamplesUnder-delivery — reading records are visible by default to everyone with access, and the product has no entry point explaining this fact or a way to turn it off; over-delivery — visibility is made into a pop-up that must be chosen every time a document is opened, with a confirmation required after choosing.

C1-5"Who has viewed" and "who is online" are decided separatelyMUST¶

In one sentence: Being online is exposure in the moment; having viewed is retrospective exposure — one switch must not bundle them.

Applies toproducts that provide both real-time presence information and reading, viewing, or read-receipt records.

RuleReal-time presence information and retrospective viewing records MUST be managed as two separate categories of information: their on/off state, visible audience, and retention period MUST be independently decidable (see collab.presence.seen.mode, collab.record.retention.ttl). Using a single switch to decide both at once is forbidden, and reconstructing an equivalent conclusion from the other category when one is turned off is also forbidden (such as piecing together an equivalent read list from presence time and document open counts after read receipts are disabled). The retention period of viewing records MUST be explicit and queryable; once expired, they MUST NOT continue to be presented to other members. The mere existence of viewing records MUST be knowable before a member could first be recorded, not exist only in the terms of service.

Boundary conditionsThis rule does not forbid offering read receipts or viewing records — they do have value in many collaboration scenarios. What it requires is that these two kinds of exposure be decided separately. Statutory or contractually required proof of delivery (such as sign-off on a formal notice) is not subject to this rule's "can be turned off" requirement, but it must still comply with the knowability and retention-period requirements.

Design applicationWrite the difference between the two into the wording of the setting item itself — "others can see whether you are currently online" and "others can see when you viewed which content" are two different sentences; writing them together is the same as not writing them at all. The default audience for read records should usually be limited to the content's responsible party, not everyone with access.

Verification examples

• User side: after turning off viewing records, check whether other members can still infer equivalent information through side channels such as presence history, notification read status, or comment browsing position.
• Implementation side: check whether the switches, audience, and retention period of the two categories are independently configured; verify that expired records are no longer returned externally.

CounterexamplesUnder-delivery — a single "collaboration visibility" switch controls both online status and reading records, and turning it off also removes one's own online status, so nobody dares turn it off; over-delivery — every time a shared document is opened, a prompt first asks "allow this viewing to be recorded?"

C1-6Perceptual information is not used for evaluationMUST¶

In one sentence: Online duration, reading records, and edit counts must not be used to score people.

Applies toproducts that collect member presence, viewing, or operation information.

RuleInformation generated for collaborative perceptual purposes is forbidden to be used for a member's performance evaluation, competency scoring, task-assignment priority, ranking weight, admission determination, or differential pricing (see collab.presence.purpose.scope). Every category of perceptual information MUST be bound to an explicit purpose and downstream consumer, and modules not on that list MUST NOT read it; presenting it in the form of an aggregate, a ranking, or "team activity level" that produces an equivalent effect on an individual is forbidden. A scenario that uses collaborative activity data for a management purpose (such as work-hour statistics) MUST be supported by that scenario's own compliance basis and disclosed to those from whom data is collected; it MUST NOT be enabled by default merely because this product has a collaboration feature.

Boundary conditionsThis rule does not forbid self-facing statistics shown to the member themself, nor does it forbid capacity and performance metrics that do not point at an individual. It constrains turning perceptual information into a judgment about a person. An organization's log access for security or auditing purposes is handled under its own policy and is not the evaluative use this rule addresses, but that access must still have a basis and be recorded.

Design applicationWrite the downstream consumers of perceptual fields as an explicit list and check it regularly — this kind of overreach is usually not intentional design, it's some reporting module reading straight from the collaboration store. Set a hard constraint for "team dashboard" style features: they can show an object's progress, not a ranking of people's activity.

Verification examples

• User side: check whether the product contains any leaderboard of members ranked by activity level, edit count, or response speed.
• Implementation side: audit whether the list of downstream readers of presence and viewing records matches the declaration; check for any side-channel export to HR or performance systems.

CounterexamplesUnder-delivery — the collaboration platform gives managers a weekly report of "member online time and document edit count" and ranks by it; over-delivery — to avoid being used for evaluation, even object-level information like "this document has not been viewed by anyone in the last thirty days" is withheld, so stale content cannot be identified.

C1-7Collaboration changes can be perceived equallyMUST¶

In one sentence: Without seeing colors or using a mouse, one can still follow changes and complete the collaboration.

Applies toproducts that present presence, changes, comments, conflicts, or permission changes.

Rule

1. The system MUST provide a means of identification that does not depend on color, avatars, or transient animation; a name or accessible name, the object's location, the type of change, and the actionable entry point MUST be obtainable by assistive technology, and MUST NOT exceed the scope the member is currently authorized to view.
2. Comments, diffs, conflicts, and the handling entry point MUST be locatable and operable by keyboard; when related content is moved or deleted, the change of location MUST be announced, and focus MUST NOT be moved to unrelated content.
3. Remote edits MUST NOT snatch away the person's own input focus without notice. The product MUST provide a way to control announcements of non-critical activity, and MUST retain an entry point for actively querying changes; pausing announcements does not pause synchronization, nor does it turn off input protection.
4. When a follow-someone's-viewpoint feature is provided, it MUST be entered actively by the follower, the following state MUST be presented continuously, and exiting MUST be allowed at any time; the initiator cannot consent to being followed on someone else's behalf.

Related configuration: collab.presence.presentation.

Boundary conditionsThis rule requires that information and operations be reachable; it does not require every cursor movement to be announced, nor does it require a follow feature to be provided.

Verification examplesUsing a screen reader and keyboard, complete "locate a comment — read the content it refers to — reply — return to the original editing point"; when content is concurrently inserted, check that focus, selection, and input are preserved; after pausing activity announcements, critical conflicts can still be looked up.

CounterexamplesUnder-delivery — members are distinguished only by red/green cursors, and comments can only be viewed by hovering with a mouse. Over-delivery — every remote keystroke is read aloud one by one, so the user cannot finish their own sentence.

3.2 C2 Visibility is a property of content¶

Who can see what is a property the content itself carries: it travels with the content, travels with a copy when the content is copied, travels with the embedding relationship when the content is embedded, and determines whether export is possible. It is not a switch on the interface — hiding a menu item, graying out a button, or filtering it out of search results are none of them visibility; they are only its presentation. This principle governs how the scope of visibility itself is defined, how it can be ascertained, who has a right to know when it changes, and whether "cannot be seen" actually holds at the mechanism level. It does not govern perceptual information about people — that is C1.

C2-1Visible scope resolves to subjectsMUST¶

In one sentence: "Shared" is not the answer — "who" is.

Applies toproducts that provide content-sharing capability.

RuleAt any moment, the visible scope of any shared object MUST be resolvable, by a member authorized to view that scope, to specific subject categories: named individuals, an enumerable group, link holders, external guests, the entire organization (see collab.visibility.audience). Using only "shared," "public," or "team visible" as the complete statement of visible scope is forbidden without also providing its resolved result. When a group is the subject, its current members MUST be expandable, or at least its size and source MUST be knowable; a non-enumerable audience (such as link holders) MUST be explicitly labeled as non-enumerable (see C2-3). Visible scope and edit permission are two dimensions and MUST be expressed separately; a single level is forbidden from representing both at once.

Boundary conditionsThis rule does not require disclosing the complete visitor list to all members — the scope of who can view may itself be sensitive information; what it requires is that an authorized party gets a definite answer, and that an unauthorized party gets an explicit "you are not authorized to view this information" rather than a list that looks complete but has actually been filtered. "Visible to everyone" in a large organization does not require enumerating each person.

Design applicationChange the default answer of the sharing panel from a status word to a list of subjects. For nested structures (files within a folder, sub-pages within a page), be able to answer the actual scope of "this one," not just report the parent level's setting.

Verification examples

• User side: take ten shared objects at random and have the owner state each one's exact visible scope within thirty seconds; record the proportion unable to answer and the reasons why.
• Implementation side: check whether the scope presented on the interface matches the backend's actual authorization list, especially after group nesting and inheritance stack up.

CounterexamplesUnder-delivery — the sharing panel shows only "sharing enabled" and a copy-link button, with no way to find out who can open this document; over-delivery — every single access is turned into a request that the owner must approve individually, jamming up the team's routine collaboration.

C2-2Scope changes are told to those already insideMUST¶

In one sentence: If more people have entered the room, or the door has been opened, those already inside have a right to know.

Applies toproducts that allow the visible scope of content to be changed after creation.

RuleWhen the visible scope of a shared object expands, members already within that scope MUST be able to learn of this change (see collab.visibility.change.notice). Expansion includes: adding a named subject, adding a new group, converting from named sharing to link-visible, converting from internal to external, or being copied or embedded into an object with a larger scope. The notification MUST state the scope after the change, not merely "permissions have been updated"; the change record and the notification task MUST be generated no later than when the new subject gains access; online contributors MUST be shown the new-audience notice before they continue to submit, and offline members MUST check it before resuming submission. When visible scope shrinks, the removed subject MUST learn that their access has ended, or the product MUST ensure its interface no longer presents that object as accessible — an online interface is forbidden from continuing to display a submittable state; an offline interface MUST state that permission could not be verified, and reconnection MUST NOT allow submission on cached permission. A scope change MUST record the subject who made the change and the time, and MUST be queryable within the retention period (see collab.record.categories).

Boundary conditionsThis rule does not require an interruption on every single occurrence in real time: the notification task and the change record are generated at the moment permission takes effect, and their presentation may be aggregated or deferred until the member next enters that object — a member who is online and actively contributing should see it before continuing to input, and an offline member should see the new scope on next entry before continuing to contribute; when a product chooses deferred notification, that policy MUST be recorded. It does not require notifying every historical visitor to the content, only members still within scope at the time of the change. Emergency de-authorization in security-incident response may execute first and notify afterward, but the after-the-fact notification cannot be omitted. What this rule requires is a verifiable receipt of interface delivery or blocked new submission — it does not promise proof that anyone has psychologically become aware (see the evidence tiers in C5-2).

Design applicationSeparate "scope has expanded" from "permission has been adjusted" in the notification — the former changes who can see it, the latter may only be turning someone from can-comment to can-edit. Design a dedicated prompt for the step of "converting to link-visible," since it is the least reversible kind of scope change (see C2-3).

Verification examples

• User side: turn on link sharing on a document shared with three people and observe whether, when, and in what form the original three learn of it.
• Implementation side: check whether every category of expansion action triggers a notification; verify that the notification content includes the post-change scope rather than only "settings have changed."

CounterexamplesUnder-delivery — the document owner changes an internal document to "anyone with the link can edit," and the other collaborators have no idea and keep writing internal information into it; over-delivery — every time a new collaborator is added, an instant notification is pushed to all existing members, so a document with ten collaborators gets dozens a day.

C2-3The reach of a shared link is explicitMUST¶

In one sentence: A link can be forwarded — the audience can grow without limit and cannot be recalled.

Applies toproducts that provide sharing by way of a link as the access credential.

RuleWhen creating a share that uses a link as the credential, the product MUST state, at the point where the creation action occurs, that its audience is non-enumerable and forwardable, not merely state the current permission level (see collab.visibility.link.mode). Link sharing MUST provide a means of revocation, and MUST state the validity period and any additional access restrictions; restricting to a domain or requiring login cannot substitute for revocation. After revocation, already-established sessions and directly obtained resource addresses previously acquired MUST NOT continue to receive new server-side access (see C2-4, C2-7). A copy already downloaded to a device is not thereby remotely erased. The product is forbidden from setting link sharing as the default visible scope for newly created objects. The knowability of access records for a subject who has previously accessed via a link is handled per C1-5 and C2-1; implying the audience is controllable with wording such as "the link is private" is forbidden.

Boundary conditionsThis rule does not deny the value of link sharing — it is often the only viable way to collaborate with an external party. What it constrains is that the consequences of this choice are stated truthfully. For content that has already left the product's boundary (a copy someone else saved separately, a screenshot, an exported file), revoking the link does not constitute control over these copies; this limitation MUST be stated at the point of revocation, and users must not be left to assume revocation means recall.

Design applicationPut the sentence "anyone who knows the link" next to the toggle, not in a help document; give link sharing a non-permanent default validity period, so that inaction results in tightening rather than loosening.

Verification examples

• User side: after enabling link sharing, have the user answer "how many people can open it right now," and record how many give a specific number (which indicates the explanatory copy did not work).
• Implementation side: after revoking a link, retry access using a previously obtained direct resource address and an already-established session, and verify that access is in fact denied.

CounterexamplesUnder-delivery — one-click "copy link" defaults to generating an editable link accessible outside the organization, and the interface only says "link copied"; over-delivery — every access via a link requires the visitor to fill out an identity-and-purpose form, making external collaboration effectively unusable.

C2-4Permission takes effect at the mechanism levelMUST¶

In one sentence: A hidden button is not permission; being unable to retrieve it is.

Applies toproducts that present different content or different operating capability to different subjects.

RuleVisibility and operation permission MUST be enforced at the data and interface layer; hiding, graying out, or filtering on the interface is presentation only, and is forbidden as the sole means of enforcement. An unauthorized subject is forbidden from obtaining restricted content or fragments of it through interfaces, exports, search indexes, thumbnails, previews, notification digests, reference cards, or error messages. A partially visible object MUST make its partiality explicit: when what a person sees is a filtered list, a truncated history, or a view with some items hidden, this fact MUST be knowable (see collab.visibility.partial.disclosure); otherwise they will mistake the incomplete for the complete and decide accordingly.

Boundary conditionsThis rule does not require keeping the existence of an object itself secret — whether to hide an object's existence is a product decision, see the two values under C2-6. It does not require an independent authorization service for every content type, only that the actual retrieval paths are all bound by the same determination. When existence is sensitive, use the stable statement "showing only the scope you are authorized to access," without exposing the count or existence of hidden items.

Design applicationTreat "there are 3 more comments here you are not authorized to view" as a normal presentation rather than quietly erasing them — erasing them makes people mistakenly believe the discussion has ended. Build a dedicated over-privilege test case for the two most common leakage points: search and notifications.

Verification examples

• User side: as an unauthorized member, check whether fragments of restricted content appear in search results, notification digests, reference previews, or exported files.
• Implementation side: bypass the front end and call the list, detail, export, and index interfaces directly, and verify that the returned results are consistent with the permission determination.

CounterexamplesUnder-delivery — the comment section hides three discussions from an unauthorized member, but the notification digest pushes out the first two lines of one of them verbatim; over-delivery — for absolute isolation, even "this content exists but you are not authorized to access it" is not returned, and the user's link never opens and they never learn why (see C2-6).

C2-5Inheritance and exceptions are traceableMUST¶

In one sentence: Why he can see this one must be answerable.

Applies toproducts where visible scope involves hierarchical inheritance, group authorization, or rule derivation.

RuleWhen a subject's visibility into an object derives from inheritance, group membership, or rule derivation, that source MUST be ascertainable (see collab.visibility.inheritance.trace): which level it was inherited from, through which group, and loosened or tightened by which exception. Presenting only the final result with no way to trace its cause is forbidden. An exception set individually at one level MUST remain discoverable when the parent level changes, and MUST NOT silently expire or silently expand. The rule for how tightening and loosening stack MUST be explicitly defined and consistent with actual behavior (at least one of: most restrictive wins, most permissive wins, or level priority), and the product MUST NOT use different stacking results at different entry points.

Boundary conditionsThis rule does not require showing the complete authorization topology to every member; the right to ascertain it matches the permission of the viewing scope itself. It does not prescribe which stacking rule to adopt, only that the choice be written down and applied consistently.

Design applicationAdd a source line for each subject in the permission panel ("inherited from the parent folder via 'Product Team'") — this one line often prevents misconfiguration more than the entire permission model does. When moving an object to a new parent, present the resulting change in inheritance before the move.

Verification examples

• User side: for an object with a deep inheritance chain, have an administrator explain a member's source of access, and record whether it requires piecing information together across multiple interfaces.
• Implementation side: after modifying parent-level permissions, check whether child-level exceptions take effect according to the declared stacking rule; check whether the determination is consistent across different entry points (interface, API, export).

CounterexamplesUnder-delivery — someone can edit a financial document, and the permission panel shows only "can edit," with no one knowing this came from a group three levels up; over-delivery — the complete authorization derivation tree for every object is expanded by default in the sharing panel, turning routine sharing into a reading-comprehension exercise.

C2-6A normal path is given for unauthorized accessSHOULD¶

In one sentence: Let people know who to ask, instead of hitting a blank wall.

Applies toproducts where a member might access an object outside their own permissions.

RuleWhen a member accesses an unauthorized object, the product should give an actionable next step: state the nature of the access denial, point to the object or responsible party to request from, and provide a request entry point (see collab.visibility.request.mode). A request MUST have a clear recipient and a result receipt; having no status at all after it is sent out is forbidden. When the existence of the object is itself restricted information, the product may use a response that does not disclose existence; in that case, using an ambiguous response to mask an ordinary situation that could be authorized but has not been is forbidden — the applicable conditions for the two kinds of response MUST be predefined and must not be decided arbitrarily case by case at implementation time.

Boundary conditionsThis rule does not require every product to provide a request-for-access feature; if not provided, it should at least give a responsible party or contact path. Using a response that does not disclose existence is legitimate in security-sensitive scenarios, and its scope of applicability must be recorded.

Design applicationMake the choice between "you don't have access" and "this content does not exist" a policy at the object-category level, not a case-by-case decision. Pre-fill the object identifier in the request entry, so the recipient does not have to ask back "which one do you mean."

Verification examples

• User side: open a link forwarded by a colleague that you don't have access to, and record whether the user can find out who to ask without sending a separate message to inquire.
• Implementation side: check whether the applicable conditions for the two kinds of response follow the predefined policy; verify that after a request is submitted, there is a queryable status and result receipt.

CounterexamplesUnder-delivery — opening the link shows only "403," stating neither whose it is nor whether a request can be made; over-delivery — every unauthorized access uniformly returns "content does not exist," including an ordinary team document that could otherwise be requested with one click, leaving members repeatedly wondering whether the wrong link was sent.

C2-7De-authorization covers actions in flight and derived contentMUST¶

In one sentence: After the door closes, old pages and pending messages must not still get through.

Applies toproducts where permission may change while editing, queued notifications, or external integrations are running.

Rule

1. Once de-authorization takes effect, the server MUST reject new reads and new submissions from the affected subject; long-lived connections, old pages, background queues, and reconnection requests MUST re-verify permission. A stale authorization retained on the client MUST NOT serve as a credential for continued writes.
2. Search, thumbnails, comment excerpts, summaries, and pending notifications MUST be filtered by the current recipient's permission; being authorized at generation time does not mean still being authorized at send time.
3. The product MUST separately express that de-authorization has been accepted, that the mechanism has taken effect, and which external copies cannot be recalled. When completion cannot be confirmed, it MUST remain "in progress" or "unknown," and MUST block affected new actions; displaying "all recalled" prematurely is forbidden.
4. A rejected current input MUST be protected under the established save boundary; recovery, export, and handoff paths MUST NOT re-grant access that has already been lost.

Related configuration: collab.visibility.revocation.policy.

Boundary conditionsA copy already legitimately downloaded cannot be remotely erased; subsequent server-side access must still be blocked, and the actual control boundary of local caches and offline access must be made explicit.

Verification examplesRevoke B's permission while B is editing offline, while a summary pending delivery still exists; B's reconnection must not be able to submit, the summary delivery must not leak content, and A must be able to check whether the de-authorization has taken effect.

CounterexamplesUnder-delivery — the sharing panel already shows the member removed, but an old WebSocket still accepts their writes. Over-delivery — to recall a screenshot, the administrator is required to wait for confirmation from every offline device, so de-authorization takes a long time to take effect.

3.3 C3 Concurrent edits do not swallow input¶

Two people changing the same spot at the same time is not an exceptional branch in a multi-user product — it is routine. This principle governs the adjudication of this event when it happens: what the policy is, whether it can be seen before it happens, how far auto-merge goes, and who it is handed to when it cannot be merged. The two sides of a conflict each have their own intent, permission, and responsibility; adjudication must follow the pre-declared policy and preserve contributions — it cannot use a timestamp alone to mask lost input.

C3-1The concurrency strategy is declared in advance and consistent with behaviorMUST¶

In one sentence: What happens when two people edit at once is a design decision, not luck.

Applies toproducts where the same object may be modified simultaneously by two or more members.

RuleThe product MUST predefine a concurrency strategy for every category of co-editable object (at least one of: exclusive locking; first-submit-wins with the rejected input preserved; last-write-wins with the overwritten content preserved and disclosed; semantic auto-merge; or preserving both sides' input for adjudication), and MUST keep actual behavior consistent with what is declared (see collab.concurrency.policy). Silently discarding input from any member that the member has already confirmed is forbidden under any strategy: with first-submit-wins, the rejected side MUST retain their content and be able to reapply it; with last-write-wins, the overwritten side MUST be able to discover the difference and retrieve their original contribution; with auto-merge, the merged result is handled per C3-3. Strategy is permitted to vary by object type within the same product, but an unpredictable strategy switch on the same category of object is forbidden.

Boundary conditionsThis rule does not prescribe which strategy should be chosen — the correct answer differs by content type (structured forms and free text usually call for different strategies). It does not require every object to support simultaneous editing; choosing exclusive locking is a legitimate strategy, whose requirements are in C3-5.

Design applicationDecide the strategy by the content's semantics, not by technical convenience: additions to different paragraphs can usually be merged; the same numeric field, the same payee, or the combination of a delete with an edit usually cannot. Short content is not inherently safer than long content — two people changing one monetary amount at the same time is more dangerous than two people changing two thousand words at once.

Verification examples

• User side: have two members make changes to the same object at the same time, and observe whether the result matches the product's declared strategy and whether both can understand what happened.
• Implementation side: inject concurrent writes and clock skew, and verify no silent loss occurs; check the actual strategy against the declared list for each object type.

CounterexamplesUnder-delivery — two people save a form at the same time, the later save overwrites the earlier, and the earlier person doesn't know their edit is gone; over-delivery — for safety's sake, exclusive locking is applied to every object, so even two people editing different paragraphs have to queue up.

C3-2The part currently being edited is visible in advanceMUST¶

In one sentence: Don't wait until I've finished writing to tell me someone else is already on this part.

Applies toproducts that support multiple people editing the same object at the same time.

RuleOnce an occupation fact has been obtained that is valid and cleared for presentation, it MUST be perceivable by other members before they begin modifying that block (see collab.concurrency.editing.indicator). The indicator's positioning granularity must be fine enough to allow avoidance — locating to the object without locating to the block does not satisfy this rule on long content.

When the occupation fact is unknown, or cannot be shown due to privacy settings, presenting it as "no one editing" is forbidden; in this case the product must still protect input using the concurrency strategy declared per C3-1. A perceptual indicator does not constitute mutual exclusion: if a product promises "simultaneous editing will not occur," it MUST adopt genuine mutually exclusive admission (see C3-5), and mutual exclusion MUST NOT be inferred from the indicator alone. An anonymized occupation indicator must likewise be assessed for inferable identity exposure — in a two-person space, "someone is editing paragraph three" is effectively naming them. For objects under exclusive locking, the lock status and holder MUST be visible before an edit is attempted, and notifying that content has already been locked only after the user finishes their input is forbidden. This rule addresses the existence and location of editing activity being presented; its upper bound of granularity is constrained by C1-3.

Boundary conditionsThis rule does not require real-time precision down to character position; it requires that the indicator appear earlier than the conflict is produced. This rule does not require eliminating a propagation race: two people starting to edit almost simultaneously while the indicator has not yet propagated does not constitute a violation of this rule — that situation is handled by the concurrency strategy. When the network is interrupted, the counterparty's information is unavailable, or a member has reduced their own visibility per C1-4, the product should present this information as unknown rather than as no-one-editing (see C3-6); withholding the occupation fact under privacy restrictions is a legitimate boundary, but the product must truthfully present it as unknown and continue to protect input — it must not fail to provide an effective indicator while claiming "avoiding others' edits is guaranteed."

Design applicationPlace the indicator at the editing entry point rather than next to the content — people click before they type, and the indicator only has time to work if it appears where they click. For form-type objects, a field-level occupation indicator is far more useful than a whole-form collaborator list.

Verification examples

• User side: have one member edit the middle of a long document, and have another member scroll from the top of the document to that spot and start typing; record when the latter learns someone is already editing there.
• Implementation side: verify the propagation delay and timing of editing-activity information; check whether the positioning granularity reaches an avoidable level.

CounterexamplesUnder-delivery — two people each write a paragraph, and "conflict detected" only pops up at save time, by which point both paragraphs are already finished; over-delivery — the input box locks up the moment anyone's cursor lands within the same screen, and normal collaboration gets judged a conflict.

C3-3Auto-merge has boundaries and its result is identifiableMUST¶

In one sentence: Merging without conflict is not the same as merging correctly.

Applies toproducts that adopt an auto-merge strategy.

RuleThe applicable scope of auto-merge MUST be predefined by content semantics; treating "technically convergeable" directly as "mergeable in business terms" is forbidden (see collab.concurrency.merge.scope). For a change falling within the auto-merge scope, the merged result MUST be identifiable as a product of merging: each party to the merge MUST be able to see how the result differs from what they themselves submitted, and MUST be able to correct it (see C3-4). Auto-merge MUST define a business risk unit and detectable incompatible combinations: concurrent modification of the same atomic value, a delete combined with an edit that depends on that content, and a defined group of related fields are forbidden from being submitted directly as the authoritative result without an established adjudication. When free text cannot reliably determine semantic incompatibility, the product MUST preserve each party's original contribution, make the merge diff discoverable, and perform a proportionate check before formal release or submission according to its use; promising that "correctness is automatically guaranteed for all semantics" is forbidden.

"The final sentence was not written in its entirety by any single party" does not by itself constitute a violation — a new combination is often the normal product of multi-user collaboration; what this rule forbids is producing a new, harmful business meaning that becomes the authoritative result without adjudication. The occurrence of a merge MUST be recorded and traceable to each party's original contribution (see C4-3).

Boundary conditionsThis rule does not require presenting every merge to the user for confirmation — that would make real-time collaborative editing unusable. It requires that the merge result be identifiable and correctable after the fact, and that high-risk combinations be excluded from the automatic scope. What a convergence algorithm guarantees is that all copies end up eventually consistent; it does not guarantee that the consistent result is what any party wanted, and this distinction must not be blurred in product copy.

Design applicationWrite the auto-merge scope as an explicit list (mergeable: additions to different paragraphs, entries in different fields, two people separately supplementing different background facts that combine into a paragraph no one had written in full before; not auto-mergeable: concurrent modification of the same atomic value, a combination of a delete and an edit, a group of interdependent fields). The configuration record includes the object type, the risk unit, the detection basis, the permitted combinations, the handling path for anything outside the list, the point of formal effect, and the verification use cases. Give the merged product a reviewable diff view rather than only a "synced" message.

Verification examples

• User side: construct a scenario where two people each modify different parts of the same sentence, and check whether the result becomes a sentence neither of them wrote, and whether both can discover it.
• Implementation side: check the auto-merge scope list against actual merge behavior; verify that the merge record can restore each party's original contribution.

CounterexamplesUnder-delivery — two people separately change "launching next Wednesday" to "launching next Friday" and "launching this Wednesday," and the system merges it into "launching this Friday" and shows sync complete; over-delivery — any two people editing the same document one after another are routed to a manual merge screen, and real-time collaboration degrades into sequential approval.

C3-4Conflicts go to someone who can adjudicateMUST¶

In one sentence: A conflict should not be decided alone by whoever unluckily submits last.

Applies toproducts where conflicts may arise that require human adjudication.

RuleA conflict that cannot be auto-adjudicated MUST preserve each side's content and be handed to a subject who has both permission over and responsibility for that content (see collab.concurrency.arbiter). Defaulting the adjudication responsibility to whoever submitted last is forbidden, unless that person happens to be the responsible subject; when the adjudicator lacks the basis for a judgment (not knowing the other party's intent, not authorized to view the other party's content), the product MUST provide a contact or handoff path rather than requiring a choice between two options with no basis. The result of the adjudication MUST be knowable to all affected parties; letting a party whose contribution was rejected discover their content has vanished without notice is forbidden. While a conflict is pending adjudication, all sides' content MUST remain accessible; only one side being preserved is not permitted.

Boundary conditionsThis rule does not require the product to implement an approval workflow or assign an arbitrator; on an object with no clear responsible subject, handing adjudication to the initiator while notifying the other party is acceptable. What it forbids is disguising adjudication as an ordinary save-conflict prompt.

Design applicationBuild the adjudication interface as "both pieces of content side by side + each author + a way to contact them," not as two buttons "keep mine / keep theirs" — the latter is a meaningless choice when the adjudicator does not know the other party's intent. See C5-1 for resolving the responsible subject.

Verification examples

• User side: create a real conflict, and observe who the adjudication interface appears to, whether they have the information to make a choice, and how long it takes for the other party to learn the result.
• Implementation side: check whether the adjudicator-resolution rule matches the responsible-subject field; verify that both sides' content remains retrievable while adjudication is pending.

CounterexamplesUnder-delivery — an intern saves last, and the system pops up "keep your content or the server's," they choose their own, and the architect's two hours of edits vanish with no one notified; over-delivery — every conflict is forced through a round of cross-department confirmation, so a simple text conflict takes two days to resolve.

C3-5An exclusive lock has a holder and a time limitMUST¶

In one sentence: If the person who locked it has gone home, the file must not stay locked forever.

Applies toproducts that adopt exclusive locking or a check-out mechanism.

RuleEvery lock MUST have a visible holder, an acquisition time, and a validity period (see collab.concurrency.lock.ttl). A lock with no time limit and no release path is forbidden to exist: the product MUST provide at least one forced-release path, whose trigger conditions (timeout, holder offline, action by the responsible subject or an administrator) MUST be predefined and knowable to members. A forced release MUST NOT delete an already-persisted draft or actively clear the holder's local input. The product MUST state where the draft is saved, its retention boundary, and the conditions for retrieving it; input that exists only on an offline device MUST NOT be claimed as already backed up on the server. On reconnection, the holder first verifies current editing permission and the lock credential, then restores the original input as a pending draft — overwriting someone else's work with an expired lock is forbidden. Retrieval remains subject to current permission; after de-authorization, restoring a draft must not be used as a back door to re-read restricted source content. The acquisition and release of a lock MUST be recorded and traceable. When the account holding a lock is disabled or removed (see C5-3), the lock it holds MUST enter a releasable state.

Boundary conditionsThis rule does not require locks to have a short timeout — a long validity period is correct for some workflows; it requires that a time limit exist, be visible, and have a release path. It does not apply to millisecond-scale internal concurrency control, only to locking states visible to the user that would block someone else's work.

Design applicationPresent the four facts — who locked it, when, how much time remains, and how to contact them — together in one place. Show the impact before release; notify the holder if reachable, and retain a queryable event if they are offline. Retain a saved private draft within the bounds permission allows; do not claim to have retrieved content that exists only on an offline device.

Verification examples

• User side: have the holder power off while holding the lock, and observe how long it takes other members to resume work and what path is required.
• Implementation side: after a forced release, check that the original holder can retrieve their saved draft within the bounds permission allows; check that the limitation on unbacked-up offline-device input is stated; check the completeness of the lock record.

CounterexamplesUnder-delivery — a colleague checks out a design source file and then takes two weeks of vacation, forcing the team to start over on a new copy; over-delivery — a lock auto-releases after five minutes of no activity, and someone who was still thinking finds their content already changed by someone else the moment they look back.

C3-6The promise of convergence is stated separately from what others can seeSHOULD¶

In one sentence: "What I see is the latest" and "what I changed, others can see" are two different things.

Applies tomulti-user products with sync latency or an offline-editing capability.

RuleThe product should separately express two groups of state — inbound (whether what this person sees already includes others' latest changes) and outbound (whether this person's changes have been persisted, accepted by the server, and distributed to the target scope) — and should not let a single "synced" indicator carry both at once (see collab.concurrency.convergence.presentation). This person's submission being accepted does not prove this person has received others' concurrent or earlier changes — the two facts are supported by different evidence. Each dimension must have "unknown" and "failed" semantics; a counterparty's receipt can only prove that specific client received it — stating this as "everyone has seen it" on that basis is forbidden. Evidence of this person's own viewing is provided only per the records authorized under C1-5, and is not inferred from distribution receipts. The object snapshot, update time, receipts, and target member set of a given sync are operational facts, not written by configuration. When others' changes are unavailable (network interruption, counterparty offline), presenting this state as no-one-editing or as content-is-current is forbidden (see C3-2). How a modification made while offline is handled on reconnection must be consistent with the strategy declared per C3-1, and silently overwriting others' changes not seen while offline is forbidden.

Boundary conditionsThis rule does not require presenting both states for every keystroke; aggregating to block level or session level is acceptable. It does not require giving a specific numeric commitment for latency — that is measured and documented by the product according to its own architecture. "Convergence" is the technical property that all copies end up eventually consistent after executing the same set of operations, not a guarantee that anyone has actually read it; the two must not be conflated in product copy.

Design applicationDesign an explicit editing-state indicator for "not connected," rather than letting the interface look like everything is fine. After reconnecting, present "what others did while you were offline" as a reviewable moment, rather than simply merging the result in and calling it done.

Verification examples

• User side: keep editing after going offline, then reconnect, and record whether the user can say which changes are their own and which are someone else's from that period.
• Implementation side: verify that the editing-activity indicator while disconnected does not present as no-one-editing; check that the offline-change merge path is consistent with the declared strategy.

CounterexamplesUnder-delivery — reconnecting after two hours offline, the interface shows only "synced," and the user does not know they overwrote three of someone else's edits; over-delivery — a sync-status prompt pops up for every tiny delay, and the editing process is drowned in status bars.

3.4 C4 A personal operation has an explicit scope of effect¶

In a single-user product, the consequence of an operation lands only on the operator themself; in a shared space, the same action lands on someone else too. This principle governs the effect one person's single operation produces on a shared object, the boundary of that effect, and who it belongs to. The single easiest thing to get wrong in this domain is right here: in a single-user product, undo equals "go back to the previous state"; in a multi-user product, that equation no longer holds — the previous state contains someone else's work.

C4-1Undo undoes one's own stepMUST¶

In one sentence: Undo means "undo what I did," not "undo the last step."

Applies toproducts that offer undo capability on shared objects.

RuleUndo on a shared object MUST resolve to undoing the previous step (or a specified step) taken by the member who executes the undo, on that object; it is forbidden to implement it as reverting the object's global most-recent change (see collab.action.undo.scope). Undo MUST select the executing member's own contribution within the declared undo context, and is forbidden from selecting someone else's global most-recent change; the implementation is not prescribed — a per-member undo history, filtering by operation source, or an equivalent mechanism are all acceptable, and this rule does not prescribe a data structure or storage key. The product MUST predeclare the boundary of "this person" as an operation source: whether multiple tabs of the same member, an operation performed on someone's behalf, and a subsequent Agent rewrite each count. What an undo targets and its scope of effect MUST be resolvable before execution. When this person has no undoable operation, undo MUST have no effect and state this truthfully; falling back to undoing someone else's most-recent change is forbidden.

Boundary conditionsThis rule does not prescribe the depth of the undo stack, nor does it require undo to persist across sessions. It does not preclude the product separately offering an ability to "roll back to a historical snapshot" — that is history recovery, not undo, and the two are forbidden from sharing the same entry point and the same shortcut key. When this person's own step cannot be undone in isolation without affecting others, it is handled per C4-2.

Design applicationFirst write out clearly "what counts as this person's own step" — whether it is filtered by member, by session, or by operation source; this is the core of this rule's implementation, and which mechanism to use is up to the product. For structural operations (move, reorder, bulk assign), be able to answer "whose subsequent actions would undoing it carry along with it" — if you cannot answer, present the scope per C4-2 first.

Verification examples

• User side: member A makes an edit, member B then makes an edit on the same object, and A presses undo; check whether what gets undone is A's edit or B's edit.
• Implementation side: check whether the undo's selection rule targets the executor's own contribution and whether the context boundary has been declared; verify that when there is no self-undoable operation, the behavior is "no effect, stated truthfully." Also construct five situations — A and B editing interleaved, this person having no history, the same person in two tabs, an operation performed on someone's behalf, and a subsequent Agent rewrite — and check the retrieval result for each.

CounterexamplesUnder-delivery — a new hire presses undo twice on a shared whiteboard and undoes an entire flowchart a senior colleague just finished drawing, with no one knowing who did it; over-delivery — to absolutely avoid affecting others, any undo after someone else has made a subsequent operation is uniformly disabled, so a user cannot even undo their own just-mistyped character.

C4-2Undo does not silently roll back someone else's workMUST¶

In one sentence: To roll back someone else's changes along with mine, say so clearly first, then roll back.

Applies toproducts where undo on a shared object might affect someone else's subsequent changes.

RuleWhen one of this person's steps has a dependency relationship with someone else's subsequent changes, such that undoing that step necessarily affects the other person's changes, the product MUST state the scope of the impact before execution (which changes, from which members) and obtain the executor's confirmation; silently cascading the rollback is forbidden (see collab.action.undo.cascade). After a cascading rollback occurs, the affected member MUST be able to learn of this fact and retrieve their rolled-back content. If the product chooses not to support this kind of undo, it MUST truthfully state the reason for not supporting it and any feasible alternative path; appearing as undone while actually not taking effect is forbidden.

Boundary conditionsThe impact prompt is shown only when the undo target has a subsequent dependency from someone else, or that dependency cannot be ruled out; it is not permitted to block all undo merely because the object has ever been edited by someone else. Execute directly when there is no cascading impact. When the implementation cannot undo safely, it preserves the current result and provides a correction or retrieval path; it is not required to adopt any particular dependency-analysis algorithm.

Design applicationWrite the prompt as a consequence, not as jargon — "undoing this step will also remove the two comments Li Si added afterward," not "a dependency conflict exists." The retrieval entry for the rolled-back party should appear in their own change record, rather than requiring them to dig through a recycle bin.

Verification examples

• User side: construct a scenario where A's operation is depended on by B's subsequent operation, have A execute undo, and check whether the prompt states the scope of impact and whether B learns of it.
• Implementation side: verify that cascaded rollback content can be retrieved by the affected member; check that no extraneous confirmation is produced when there is no subsequent change from someone else.

CounterexamplesUnder-delivery — undoing a table-structure adjustment also clears twenty rows of data someone else filled into the new column, and the interface just shows "undone"; over-delivery — as long as the object has ever had any operation from someone else, every undo pops up a lengthy impact analysis requiring the user to check a box to confirm.

C4-3Every change has a resolvable authorMUST¶

In one sentence: Who wrote this line — a person or an Agent — must be traceable.

Applies toproducts where multiple members can modify the same object.

RuleEvery change on a shared object MUST be resolvable to an author subject, and MUST be queryable within the declared retention period (see collab.record.authorship, collab.record.retention.ttl). The author subject MUST distinguish at least three categories: a member's own operation, an operation performed on their behalf by someone else (delegation, impersonated login, admin-performed action), and an operation performed by automation or an Agent; the output of automation or an Agent MUST indicate its execution source, and an operation performed on someone's behalf MUST record both the actual executor and the party represented. Author-subject attribution is forbidden from being rewritten upon a responsibility handoff, a member's rename, or account deactivation (see C5-4). It is permissible for something to become unqueryable once the retention period expires, but that period MUST be predeclared and must not appear as "never recorded."

Boundary conditionsThis rule does not require showing the complete change history to every member — the permission to view history is determined per C2. It does not require recording every single keystroke: the recorded granularity should be proportionate to the undo unit and adjudication needs, and applies alongside the upper bound of perceptual granularity in C1-3 (the change record is for the content, not for evaluating the person; the purpose constraint is in C1-6).

Design applicationMake "so-and-so (via automation)" and "so-and-so (performed by an administrator on their behalf)" a presentation distinguishable from an ordinary signature, rather than all showing the same name — in a post-hoc investigation, this distinction is often the entire crux of the matter.

Verification examples

• User side: have an administrator perform a modification on behalf of a member, and check who other members see as the author and whether it is apparent this was performed on someone's behalf.
• Implementation side: check that the three author categories are recorded separately; verify that after a member is renamed or deactivated, the subject attribution of historical authors is not rewritten.

CounterexamplesUnder-delivery — an integration bot bulk-modifies two hundred records under a shared account's name, and history shows them all under that account with no way to tell which automation trigger caused which; over-delivery — every single cursor movement and selection is written into the change history, making the history panel too long to be usable (this also violates C1-3).

C4-4The scope of effect is explicit before executionMUST¶

In one sentence: Know before pressing whether this changes just mine or changes everyone's.

Applies toproducts with operations that have different scopes of effect for different members.

RuleWhether an operation takes effect only for this person, for specified members, or for everyone MUST be knowable to the operator before execution (see collab.action.effect.scope). The default ownership of shared view versus personal view MUST be explicitly defined: when changing presentation state such as filtering, sorting, grouping, collapsing, display density, or column width, the product MUST make clear where the change lands, and is forbidden from letting both kinds of change share the same entry point with different results (the default ownership of personal state is in C6-3). A structural operation affecting everyone (rename, move, change hierarchy, bulk modify, apply a template, change a workflow state) MUST state, before execution, how many objects it affects and the scope of impact. Omitting the statement of scope on the grounds that "it can be undone afterward" is forbidden — undo is not without cost in a multi-user setting (see C4-2).

Boundary conditionsThis rule does not require a confirmation pop-up for every operation; the statement can be a persistent indicator at the entry point ("currently editing the shared view"), with confirmation-tiering requirements in C4-5. It does not require listing every affected object; giving a count and category suffices.

Design applicationMake "shared view" and "my view" two visible states that are always displayed to show the current location, rather than a toggle hidden deep in a menu — most incidents of accidentally changing a shared view happen because the person did not know which side they were currently on.

Verification examples

• User side: have a member adjust a filter on a board, and record whether they know whether other people's boards changed too, and how they found out.
• Implementation side: check that the ownership definition for each type of presentation state matches its actual storage location; verify that structural operations give an impact count before execution.

CounterexamplesUnder-delivery — a member changes a filter to find one card, and the whole team of thirty people's board changes along with it, without the member even knowing; over-delivery — every column-width adjustment pops up asking "should this change apply to just you or to everyone."

C4-5Destructive operations on shared objects are held to a stricter standardMUST¶

In one sentence: Deleting your own thing and deleting everyone's thing are not the same act.

Applies toproducts that allow deleting, archiving, or invalidating an object someone else is currently using.

RuleThe severity tier of a destructive operation's consequence MUST take as inputs whether the object is visible to others, whether it is referenced by others, and whether others are currently working in it (see collab.action.destructive.level). When deleting or archiving an object that contains someone else's contribution, the product MUST state before execution whose content will be affected; removing someone else's contribution irrecoverably along with the object is forbidden without providing a way to preserve or export that contribution. A party referencing the deleted object (a link, an embed, a task dependency) MUST be able to learn that the object is no longer available; presenting it as blank or silently failing is forbidden. Executing a delete on an object someone else is currently editing MUST first present an invalidation notice on any reachable editing interface and protect their input; a session for which interface delivery has not been confirmed MUST stop accepting subsequent shared writes, and on reconnection must check the status before continuing. Delivery does not prove the person has actually read it; emergency de-authorization does not wait for user confirmation.

Boundary conditionsThis rule does not require forbidding deletion of shared objects, nor does it require every deletion to go through approval. It does not change the general handling of objects with no contribution or reference from others. Data-retention and compliance deletion requests (such as personal-information deletion) execute under their own rules; where they conflict with this rule's "preserve contribution" requirement, applicable regulation governs.

Design applicationWriting "this document contains seventeen comments from three colleagues" into the delete confirmation is far more useful than "this action cannot be undone." Give referencing parties an explicit invalidation presentation ("the referenced content has been deleted"), rather than letting the link silently go dead.

Verification examples

• User side: delete a document that has comments from multiple people and references from others, and check whether the deleter is told the scope of impact, and whether commenters and referencers learn of it.
• Implementation side: check that the severity-tier inputs include visibility, references, and online-editing status; verify a retrieval path exists for someone else's contribution.

CounterexamplesUnder-delivery — archiving a project wipes out all discussions from five members along with it, and members afterward neither receive a notification nor can retrieve the content; over-delivery — deleting even a blank card you just created yourself requires filling out a reason and waiting for administrator approval.

C4-6Bulk operations do not produce a proportional amount of interruptionSHOULD¶

In one sentence: Changing a hundred items is not the same as sending a hundred notifications.

Applies toproducts that offer bulk operations that produce reminders to others.

RuleThe reminders a single bulk operation produces for each affected member should be aggregated into an understandable whole, rather than sent one by one in proportion to the number of affected objects (see collab.action.batch.notice). The aggregated reminder still MUST let the recipient see the specific items relevant to them; aggregating down to something like "47 updates" with no way to judge whether action is needed is forbidden. Producing the reminder as a silent side effect of the operation is forbidden: when performing a bulk assignment, bulk status change, or bulk @-mention, the operator should know before execution who this operation will interrupt (see C4-4).

Boundary conditionsThis rule does not require suppressing individual critical reminders (such as being assigned a task that needs immediate handling); an emergency exception must predefine the triggering event conditions, the eligible subjects, and how the recipient is informed. It does not forbid offering a "don't notify for this change" option, but that option must not become a way to evade the scope-change notification required by C2-2.

Design applicationPut "this operation will notify 12 people" in the bulk-operation confirmation. Keep an expandable detail behind the aggregated reminder for affected parties, so someone can judge within one screen which items need their own action.

Verification examples

• User side: bulk-assign thirty cards to the same person, and record how many reminders that person receives and whether they can quickly see which need attention today.
• Implementation side: check whether the bulk path reuses the single-operation reminder logic; verify the aggregated reminder still contains judgeable detail.

CounterexamplesUnder-delivery — bulk-adjusting the due date of thirty cards sends the assignee thirty push notifications; over-delivery — all changes are aggregated into one daily-summary notification, so even an urgent assignment has to wait until the next morning.

C4-7Retries and partial success each have their own distinct resultMUST¶

In one sentence: Not receiving a receipt does not mean it wasn't done; if only part succeeded, say which part.

Applies tocollaborative operations that may be retried or partially completed, such as sending comments, invitations, bulk modifications, or responsibility transfers.

Rule

1. The system MUST distinguish the operation request, its actual taking effect, and the result receipt. A timeout or a lost receipt MUST NOT be directly interpreted as not having executed; success or failure can only be determined once the actual result is queried.
2. Resubmitting the same operation MUST recognize its operation identifier, or use an equivalent mechanism to prevent side effects such as duplicate comments, duplicate invitations, or duplicate responsibility transfers. When the result is unknown and safe retry cannot be proven, a way to check or handle it manually MUST be provided; automatically replaying the whole batch is forbidden.
3. A bulk operation MUST record success, failure, not-executed, and unknown by object, and display the detail to those authorized to view it; partial completion MUST NOT be presented as complete success. A retry handles only items already confirmed retryable, and re-verifies current permission and the object snapshot.
4. Multi-channel reminders for the same business event MUST be linked to that same event; a resend after failure MUST NOT bypass the recipient's mute setting and delivery permission.

Related configuration: collab.action.retry.policy, collab.action.delivery.policy.

Boundary conditionsThis rule does not require absolute exactly-once delivery across every system; it requires that duplicates be recognizable, that results not be misreported, and that unknowns not be blindly retried.

Verification examplesBulk-reassign ten items; the connection drops after three succeed. Before retrying, query the result of each item; do not reassign or renotify the succeeded items, and continue checking the unknown ones.

CounterexamplesUnder-delivery — a user sees "send failed" and clicks again, and the comment and the email each end up appearing twice. Over-delivery — the slightest network delay disables all collaborative operations with no way to check the result.

3.5 C5 Responsibility has an owner and can be handed off¶

Participating is not the same as being responsible. A document with eight collaborators does not answer "who owns this right now"; a task card with five watchers does not answer "who is driving it forward." This principle governs the ownership of responsibility and decisions, including whether ending a discussion produces an effective decision; the responsible-subject field: it must exist, must have an answer (including "no one responsible" as a legitimate answer), must be transferable between people, and must have a clear destination when a person leaves. It does not govern how an organization divides labor — that is a management system, outside the scope of these guidelines; it governs keeping the product's expression of responsibility from creating a state of no-one-responsible that is invisible as such.

C5-1The current responsible subject is resolvableMUST¶

In one sentence: The list of participants does not answer "who is responsible right now."

Applies toproducts with objects (tasks, approvals, content, spaces) that need someone to drive or maintain them.

RuleEvery object that needs someone responsible for it MUST, at any moment, be resolvable to its current responsible subject, or explicitly resolve to no one responsible (see collab.ownership.assignee). Substituting a participant list, a watcher list, the most recent editor, or the creator for the responsible subject is forbidden. "No one responsible" MUST be an explicit state that can be queried and presented; it must not appear as an empty field visible to no one. When the responsible subject is a group, the claiming rule within that group must be stated (at least one of: first-come-first-served, rotation, must be designated) — otherwise group responsibility is equivalent to no one responsible. An object's responsible subject and its visible scope are two dimensions, and inferring one from the other is forbidden (being able to see it does not mean being responsible for it; being responsible for it does not mean being able to see everything).

Boundary conditionsThis rule does not require every object to have a responsible subject — purely reference content can simply be recorded as not applicable. It does not prescribe an upper limit on the number of responsible subjects, but when there are multiple, it must be possible to answer "whose action counts as driving it forward."

Design applicationMake "unassigned" a normal state that can be filtered and counted, rather than a blank. Regularly surface objects that are "no one responsible, and unchanged for a long time" — this kind of object is the most common form of silent failure in collaboration systems.

Verification examples

• User side: take twenty in-progress tasks at random, have the team each state their own understanding of the current owner, and record the proportion of inconsistent or unanswerable responses.
• Implementation side: check whether the responsible-subject field is independent of the participant and creator fields; verify that "no one responsible" can be queried and filtered.

CounterexamplesUnder-delivery — a task card has six avatars on it, everyone assumes someone else is doing it, and two weeks later no one has moved it forward and no one has noticed; over-delivery — every document and every comment is required to have a named responsible person designated before it can even be created.

C5-2A handoff is a two-sided eventMUST¶

In one sentence: Assigning it out does not mean it has been taken up.

Applies toproducts that allow responsibility to be transferred from one subject to another.

RuleA responsibility transfer MUST record the receiving party's evidence of awareness and the actual effective state of current responsibility; presenting a one-sided assignment action directly as a completed handoff is forbidden (see collab.ownership.handoff.mode). The product MUST separately express four factual dimensions: initiated / delivered-or-accessible / awareness-evidence status / accepted-or-not. Delivery, client-side display, a read receipt, the person's own confirmation, and acceptance are different kinds of evidence and must not substitute for one another: when valid awareness evidence has not been obtained, display "awareness unknown"; asserting "not yet viewed" on that basis is forbidden; being aware also does not automatically mean having accepted it. When an assignment model that does not require the recipient's confirmation is used, the responsibility-effective rule MUST be predefined, and "awareness unknown" must be visible to both the initiator and anyone querying responsibility. When read records are turned off (see C1-5), acceptance may be proven by an explicit confirmation or a performance action bound to that specific handoff; rebuilding a general-purpose read record for this purpose is forbidden. When the recipient declines or awareness evidence is not obtained for a long time, responsibility MUST return to a definite state (back to the initiator, back to no one responsible, or transferred per a predefined rule); it is forbidden to remain in a dangling state that belongs to neither the initiator nor the recipient; this fallback requirement applies to every assignment model, including one-sided assignment. The respective effects of decline, revocation, reassignment, expiry fallback, repeated confirmation, and confirmation of an already-invalidated request MUST be predeclared; the release of responsibility is judged only against the currently valid handoff-request identifier — a confirmation aimed at a request that has already been reassigned does not accept new responsibility. When a model requiring acceptance is used, the original responsibility or a defined temporary owner is retained pending acceptance; when one-sided assignment is used, responsibility transfers at the predeclared point in time, but that taking-effect fact must not be stated as the recipient having become aware of it or having accepted it.

Boundary conditionsThis rule does not require implementing confirmation-based assignment — many teams' way of working is not suited to confirming every single time; it requires that insufficient awareness evidence not be hidden, nor rewritten into "not viewed." When the system auto-assigns by rule (round robin, load balancing), the awareness requirement applies equally.

Design applicationChange the default presentation after an assignment from "assigned to Li Si" to "assigned to Li Si · awareness unknown" — do not write "not yet viewed": the absence of a receipt only shows the product has no evidence, not that the person hasn't seen it.

Verification examples

• User side: assign a task to a member who is on leave that day, and observe the state the initiator sees on the interface, and what the task's ownership looks like a week later.
• Implementation side: check whether the four states are stored and presented separately; verify that the fallback rule actually executes when awareness evidence is not obtained for a long time. Also construct: obtaining the task from a notification after read records are disabled, explicit acceptance, acceptance after expiry, two people reassigning at the same time, and confirmation after being deactivated — for any of these receipt-lacking situations, "not yet viewed" must not be displayed, and confirmation aimed at an already-invalidated request must not accept new responsibility.

CounterexamplesUnder-delivery — a task is assigned to a colleague who left half a month ago, and the board keeps showing "in progress · owner: Zhang San"; over-delivery — every assignment requires the recipient to click confirm, and while the recipient is in a meeting, the task sits stuck at pending-confirmation the whole time.

C5-3Leaving and transfer are symmetricMUST¶

In one sentence: When a person leaves, the things under their name must not just go unreachable in place.

Applies toproducts where a member may leave, be removed, or have their account deactivated.

RuleWhen a member leaves, is removed, or has their account deactivated, the responsibility, content, and permissions under their name MUST each have a clear destination: transfer to a designated subject, convert to organization or space ownership, archive, or be explicitly recorded as ownerless (see collab.ownership.offboarding). Making content under a member's name inaccessible with no disposition path after that member disappears is forbidden, and the system silently transferring ownership to some subject who was never informed is also forbidden. The disposition must be ascertainable: who transferred which objects to whom and when must be queryable within the retention period (see C5-4). When a member is removed, any lock they hold MUST enter a releasable state (see C3-5), and their incomplete handoffs are handled per the fallback rule in C5-2. Termination of permission must not be conditioned on the handoff having completed; a failed object enters a restricted, queryable custodial state, to be handled by a clearly designated responsible party. Content produced by the member themself that is personal (private drafts, private notes) must be disposed of separately from content belonging to the shared space; the default disposition of the former must not be merging it into the shared space (see C6-1).

Boundary conditionsThis rule does not prescribe the specific ownership of the disposition — that is determined by organizational policy and applicable regulation; it requires that a disposition path exist, be executed, and be queryable. It does not exempt statutory obligations such as personal-information deletion; when these obligations conflict with "content retention," applicable regulation governs, and the existence of the conflict should be stated in the product's documentation.

Design applicationMake the departure flow a checklist rather than a delete button: N items of responsibility under their name, M exclusive holdings, K pieces of personal content, with disposition options given for each category. On a normal departure, check the disposable objects in advance; on emergency de-authorization, terminate access first. When a handoff fails, retain the restricted custodial state, the handling responsible party, and the next step, without expanding the audience for personal content.

Verification examples

• User side: deactivate an account that holds multiple tasks, multiple exclusive locks, and several private drafts, and check the actual destination of each category and whether it can be ascertained.
• Implementation side: check the completeness of the disposition record; verify that after removal there is no object that is both inaccessible and lacking a disposition entry.

CounterexamplesUnder-delivery — a colleague leaves, and the dozen shared documents they created become ownerless, with no one able to change the permissions or delete them; over-delivery — the moment a member is removed from a project, all of their historical comments and change records are deleted along with them, and the discussion context disappears.

C5-4A change in responsibility does not rewrite historical attributionMUST¶

In one sentence: After the owner changes, who wrote something before is still who wrote it.

Applies toproducts that record change history or contribution attribution.

RuleWhen the responsible subject changes, a member is renamed, or an account is merged or deactivated, the author attribution of a change that has already occurred is forbidden from being rewritten to the new responsible subject (see C4-3, collab.record.authorship). A member identifier in the historical record should resolve to the same subject after their display name changes, but rewriting a person's historical contribution under someone else's name is forbidden. When a personal identifier must be removed from history due to a statutory deletion request or organizational policy, the disposition MUST be explicit anonymization or removal, and that disposition itself MUST be identifiable as such; implementing it by substituting someone else's name is forbidden. The point in time of a responsibility handoff MUST be queryable, so that "whose period of responsibility did this change occur in" can be answered.

Boundary conditionsThis rule does not require permanently retaining history — the retention period is declared per collab.record.retention.ttl. It does not forbid highlighting the current responsible subject on the interface, only forbids overwriting the historical author with the current responsible subject.

Design applicationStore the member identifier separately from the display name — this is the implementation precondition for this rule. Design a dedicated historical presentation for "this member has left," rather than replacing the name with a blank or with the successor's name.

Verification examples

• User side: hand a task with contribution history from multiple people to a new owner, and check whether the authors of prior changes in the history still show as the original authors.
• Implementation side: after executing a member rename, account deactivation, and a responsibility handoff, check the historical author field for each in turn; verify that an anonymization disposition is identifiable.

CounterexamplesUnder-delivery — after a task is handed off, every prior operation's executor in the history now shows as the new owner, completely distorting accountability; over-delivery — to preserve the completeness of history, a departed member's name and contact information are kept permanently in the system with no disposition path at all, conflicting with personal-information handling requirements.

C5-5The boundaries for external and temporary members are explicitSHOULD¶

In one sentence: When a guest's access expires, and who owns what they left behind after it expires.

Applies toproducts that allow members outside the organization, guests, or temporary permissions to participate in collaboration.

RuleThe scope of participation, validity period, and post-expiry disposition for external and temporary members should be explicitly defined at the time of grant (see collab.ownership.guest.policy). A temporary permission MUST have a clear expiry point; a long-term external grant MUST have a review-responsible party and a review cycle. After expiry or exit, the content they previously produced and their contribution to shared content MUST have a clear attribution (retained and marked with its source, converted to organizational ownership, or removed per agreement), and that attribution must be knowable to internal members. While an external member is present, the product should make internal members able to perceive this fact — in a space with an external participant present, internal members' judgment of "who can see this sentence" is systematically biased toward optimism.

Boundary conditionsThis rule does not require distinguishing every category of member; a product that does not distinguish internal from external can be recorded as not applicable. It does not prescribe the length of the validity period — that is measured by the product and organization according to their own risk and its basis recorded. The strength within this rule is not uniform: "temporary permission expiry, long-term external-grant review" and "contribution attribution must be clear" are non-turnoffable baselines; "external participation being perceivable by internal members" is at the SHOULD level, and when there is real reason to deviate, the reason and alternative are recorded. A long-term external collaborative identity is not to be uniformly treated as a temporary guest merely because it is classed as an external subject — its term and review method are declared according to the actual relationship.

Design applicationMake the identifier for external participants a persistently visible presentation (not just a small tag in a member list), especially in the context of comments, mentions, and notifications. Give the responsible subject a chance to renew or dispose of it before expiry, rather than going straight to disconnection at expiry.

Verification examples

• User side: invite an external guest into a discussion, and have internal members answer "who can currently see this discussion," recording the proportion who answer correctly.
• Implementation side: check whether a temporary permission has a validity period and a review; verify that after expiry, the disposition of their content is executed as declared.

CounterexamplesUnder-delivery — an account temporarily opened for an external review two years ago is still valid, and can still open the current content of that batch of documents; over-delivery — internal members must get confirmation from an internal member before every single thing an external member says, and the review meeting cannot proceed.

C5-6Discussion, resolution, and decision are each recorded separatelyMUST¶

In one sentence: Ending a discussion does not mean everyone agreed; an approval covers only the content as it stood at that time.

Applies toproducts that provide comment threads, suggestions, review, voting, or joint decision-making.

Rule

1. A comment MUST be bound to a stable object and content anchor; when the anchor becomes invalid, the original context is preserved or it is explicitly marked as unable to be located — silently attaching it to other content is forbidden. Retention and retrieval are subject to current access permission.
2. A thread MUST distinguish open, resolved, reopened, deleted, or restricted; a resolve action MUST be traceable to the operator and time, and an authorized member MUST have a path to reopen or raise an objection. Resolving does not delete disagreement, nor does it automatically prove all participants agreed.
3. When an approval, vote, or confirmation will trigger subsequent execution, the product MUST define the eligible decision-makers, the conditions required, and the object snapshot and scope targeted; no reply, a read receipt, a like, or closing a thread is forbidden from being automatically converted into an approval on its own. If expressing a stance is itself a formal vote, its meaning MUST be made clear before participation.
4. When the content covered by an approval or a key condition changes after approval, it MUST be re-verified per predefined invalidation conditions; an expired decision cannot automatically approve newly added content. An automated summary MUST identify its sources, preserve unresolved items, and must not rewrite a minority opinion into unanimous agreement.

Related configuration: collab.ownership.discussion.policy, collab.ownership.decision.policy.

Boundary conditionsThis rule does not require every discussion to go through voting or approval; ordinary chat does not need a decision gate set up. The corresponding rules are enabled only when a formal decision is needed.

Verification examplesAfter B raises an objection to a passage and A deletes that passage, the thread can still state the original target; A marking it resolved does not display unanimous agreement; when key content changes after approval, re-verification is required.

CounterexamplesUnder-delivery — three likes on a task discussion are automatically recorded as three approvals, and the original dissenting opinion disappears from the summary. Over-delivery — fixing a single typo requires every commenter to re-sign off.

3.6 C6 There is private room within a shared space¶

If every character a person types is immediately visible to the whole team, they will stop trying things. This principle governs the portion of state in a shared workspace that belongs to the individual: a draft not yet finished, a comment not yet decided on, a filter condition meant only for oneself to see, and that "let me try this first." It specifies when these states start being visible to others, and how members control their own attention, following behavior, and scope of participation. Its difference from C4 lies in the regulatory object: C4 governs what effect my operation produces on others; C6 governs when my state starts being seen by others.

C6-1Unfinished work is not sent out by defaultMUST¶

In one sentence: Something not yet finished should not already be visible to others.

Applies tomulti-user products that provide content creation, commenting, or submission capability.

RuleUnfinished input MUST default to being visible only to the person themself: drafts, unsent comments, unsubmitted edits, unpublished changes (see collab.private.draft.default). Converting from not-yet-finalized to shared-visible MUST be an explicit action; using autosave, losing focus, a timeout, or closing the page as the publishing action is forbidden. When a product provides real-time collaborative editing (content becomes visible to others as it is typed), this property MUST be knowable before entering the edit, and at least one path that produces not-yet-finalized content MUST exist. The criterion for "private, not yet finalized" is that the content's actual access scope is limited to the author alone: a suggestion, branch, or copy satisfies this rule only when its access scope is in fact limited to the author; a shared suggestion mode satisfies the need for "not directly changing the formal content" but does not satisfy the need for a private draft — it is visible to the owner and can be accepted or rejected. Not-yet-finalized content is forbidden from entering search, notifications, summaries, or exports that face other people (see C2-4).

Input retention: The product MUST state where a private draft is saved and the boundary of its recovery; switching pages, a failed publish, or a permission change must not actively clear saved input. When persistent saving is not possible, the risk MUST be flagged before leaving the edit, and a retention path subject to permission constraints MUST be provided; using "saved" to mask a save failure is forbidden.

Boundary conditionsThis rule does not deny the value of real-time collaborative editing — it is the core value of this kind of product; what it requires is that this property be known, and that it not be the only available mode. An editing-activity indicator visible to others during collaboration (C3-2) is not the content-being-sent-out this rule addresses.

Design applicationMake "draft" and "published" states of the content itself rather than two different storage locations — putting them in different locations causes people to leave a draft in place and forget to publish it. For high-frequency not-yet-finalized content such as comments, retain a local draft across sessions, and make clear it has not been sent.

Verification examples

• User side: close the page after typing half a comment, and check whether that content has already become visible to others, and whether it is still there when reopened.
• Implementation side: check that not-yet-finalized content is excluded from the search index, notification digests, and exports; verify there is no publishing path triggered by timeout or loss of focus. Using two accounts, check the six paths of suggestion, branch, copy, notification, search, and export one by one: after one account writes unpublished content, the other account must not be able to obtain that content through any of these paths. Also take an undoable shared filter operation and check that it is not mistakenly counted as a qualifying exploration path.

CounterexamplesUnder-delivery — content in a comment box is visible to the whole team in real time as it is typed, and a sentence said three times and edited twice is all seen by everyone; over-delivery — every edit must first be written into a private draft and manually published, rendering real-time collaboration capability meaningless in practice.

C6-2Exploratory operations have a path that does not affect othersMUST¶

In one sentence: Wanting to try something should not require alerting everyone first.

Applies toproducts where a modification to a shared object takes effect for others immediately.

RuleThe product MUST provide at least one path for making an exploratory modification to a shared object without immediately affecting others: at least one of a personal view, a suggestion mode, a branch or copy, or a sandbox or preview (see collab.private.sandbox.mode). Making "directly modifying shared state" the only viable way to try out a change is forbidden. Whether a path qualifies is verified separately by whether it produces content, a notification, or a shared-state change visible to others; "the operation can be fully undone" does not constitute a qualifying exploration path — an undoable shared filter or structural change has already changed what others see before it is undone. Converting an exploratory modification to take effect for others MUST be an explicit action; when an exploration is abandoned, leaving a partially-effective result behind is forbidden. The existence of the exploration path itself MUST be discoverable at the shared object's editing entry point; existing only in documentation with no trace on the interface is forbidden.

Boundary conditionsThis rule does not require implementing branching and merging — for most products, a preview visible only to oneself satisfies the requirement; a suggestion mode satisfies it only when its content, activity notifications, and shared state are all kept from being exposed to others. It does not apply to objects that structurally cannot have a private intermediate state (such as a real-time vote result that is explicitly instantaneous and public); such objects are recorded as not applicable with the reason stated.

Design applicationChoose the path by the cost of the modification: changing one number is fine with a personal preview; changing a whole template or a workflow needs a copy. Put the entry point for the exploration path next to the editing entry point — burying it three levels into a menu is the same as not having it.

Verification examples

• User side: have a member try "see what it looks like without this column," and record what method they actually used and whether it affected others.
• Implementation side: verify that an abandoned exploratory modification leaves no partial result behind; check the discoverability of the exploration path's entry point.

CounterexamplesUnder-delivery — wanting to see whether a different grouping looks better requires directly changing the shared board, and after changing it back because it didn't look good, the whole team's interface jumped twice; over-delivery — every modification must first create a branch and then open a merge request, so fixing a single typo takes three steps.

C6-3A personal view does not change what others seeMUST¶

In one sentence: If I collapse a column, that should not collapse everyone else's screen too.

Applies tomulti-user products that provide presentation controls such as filtering, sorting, grouping, collapsing, zoom, or display density.

RuleA member's adjustment to presentation state MUST default to affecting only themself (see collab.private.view.ownership). Changing shared presentation state MUST be an explicit action distinguishable from a personal adjustment, and MUST state its scope of effect before execution per C4-4. When shared presentation state is changed, other members currently viewing that view MUST be able to perceive that a change has occurred; letting someone else's interface change with no indication at all is forbidden. When a product provides both a personal view and a shared view, the view currently in use MUST remain continuously visible (see the design application in C4-4).

Boundary conditionsThis rule does not forbid providing a shared view — a shared view is necessary in most team tools; what it specifies is default ownership and the explicitness of switching. A presentation change caused by the underlying data itself changing (a new record was added) is not the presentation-state change this rule addresses.

Design applicationMake "shared view" a mode that must be actively entered, and make personal adjustment the default — a product built the other way around lets every mistaken operation spill over onto the whole team. Attach an author and a time to changes made to a shared view, so people know why the interface changed.

Verification examples

• User side: have one member adjust a filter condition, and check whether other members' interfaces change; if they do, check whether those members can tell why.
• Implementation side: check that the storage location (personal-level or shared-level) for each type of presentation state matches what is declared; verify that a shared-view change produces a perceivable presentation for online viewers.

CounterexamplesUnder-delivery — a member sets a filter to find one record, and most of the whole team's board gets filtered out at the same time, so others think data was lost; over-delivery — no shared view is provided at all, and everyone has to manually set their filter to match before every meeting.

C6-4The move between private and shared areas is explicit and cannot pretend to be recalledMUST¶

In one sentence: Recalling can delete the content, but it cannot delete "having already been seen."

Applies toproducts that provide the ability to recall, delete already-sent content, or move content from a shared area back to a private area.

RuleContent moving from a private state into a shared state is an explicit action (see C6-1); the reverse move — recall, deleting already-sent content, moving from a shared area back to a private area — MUST truthfully present the exposure that has already occurred (see collab.private.recall.disclosure). The product is forbidden from using wording such as "recalled" or "not yet read by the other party" to imply the content was never seen, unless that determination comes from a reliable basis with the limitations of that basis stated. After a recall, the product MUST state its boundary of effect: content already copied, exported, screenshotted, delivered via a notification digest, or received by an external system by others is outside the scope of the recall. Whether the recall action itself is visible to others (whether it leaves a trace such as "one message recalled") MUST be predefined and applied consistently, and must not be decided case by case at implementation time.

Boundary conditionsThis rule does not deny the value of a recall feature; what it constrains is that the description of the recall's effect does not create a false expectation. It does not require the product to track the content's propagation beyond its own boundary — quite the opposite: precisely because that cannot be done, truthful disclosure is required.

Design applicationChange the post-recall message from "recalled" to an explanatory sentence ("removed from the conversation; if the other party already received a notification, the content may have already been seen"). This one sentence costs little, and it prevents subsequent behavior based on a false expectation.

Verification examples

• User side: send a piece of content that triggers a push notification, then immediately recall it, and check whether the recipient's notification bar still retains the content, and whether the sender is told of this possibility.
• Implementation side: check that the actual scope of the recall's effect matches the wording used; verify that the handling of copies in notification digests, email delivery, and external integrations is stated.

CounterexamplesUnder-delivery — someone sends the wrong message and clicks recall, the interface shows "recalled," but the original text is actually still there in the recipient's phone push notification, and the sender has no idea; over-delivery — because recall is never complete, no recall feature is offered at all, and a mistakenly sent message can only stay there.

C6-5Private communication is not folded into the shared recordSHOULD¶

In one sentence: A private chat does not become public material just because it was exported, indexed, or summarized.

Applies toproducts that provide both private communication (direct messages, private comments, personal notes) and a shared record.

RuleThe content of private communication should not enter a broader visible scope through export, search, aggregation, summary generation, or cross-feature reference (see collab.private.channel.scope). Including unauthorized-to-share private content when generating a summary, report, or knowledge compilation facing the shared space is forbidden; when such a compilation is generated by an Agent or automation, its readable scope is equally bound by this rule. When private content is accessed due to compliance, audit, or statutory requirements, the basis and scope of that access should be recorded; turning this kind of access into something routinely obtainable through a product feature is forbidden. When private communication is moved into the shared space, it must be an explicit action by the initiator, made knowable to the original conversation partner.

Boundary conditionsThis rule does not forbid a user from quoting or forwarding their own private content themself — that is the user's own disposition right. It does not change an organization's compliance access performed under statutory or institutional requirements; it only requires that this kind of access not be turned into an everyday-available button.

Design applicationSet a hard read boundary for summary and digest-type features, and mark the scope of the data source at the point where the result is generated. Make "forward to shared space" an action that leaves a trace visible to the conversation partner.

Verification examples

• User side: carry on a direct-message discussion within a project, then trigger a project-summary generation, and check whether the direct-message content appears in the summary.
• Implementation side: audit the read scope of summary-type features and the search index; verify that private content is not included in shared export results.

CounterexamplesUnder-delivery — an automatic project weekly-summary feature writes a private chat between two members about a third person into the summary sent to the whole team; over-delivery — for the sake of isolation, a conclusion reached in a private discussion cannot be brought into a shared document by any means, and the user can only manually copy and paste it.

C6-6Reminders can be scoped down, and being mentioned does not expand accessMUST¶

In one sentence: One can receive fewer interruptions; being mentioned does not mean being granted access.

Applies tocollaboration products that provide mentions, subscriptions, thread notifications, email digests, or push.

Rule

1. A member MUST be able to stop non-essential reminders by object or thread, and set a personal do-not-disturb period; when displaying deadlines and mute-resume times across time zones, the time zone MUST be queryable. Muting changes only the reminder — it cannot mark an already-assigned responsibility as handled or delete a pending item.
2. A mention MUST resolve the recipient and the authorized scope before sending; automatically granting new content access to someone or a group merely because they were @-mentioned is forbidden. When an invitation is actually needed, the granted scope MUST be explicitly displayed and executed as an independent authorization action.
3. A group mention MUST let the sender know the actual notification scope; when someone is not authorized to view the member list, the list must not be exposed to them. The conditions, subjects, frequency constraints, and records for emergency override of mute MUST be predefined; muting cannot be automatically overridden merely by repeated @-mentions.
4. Necessary events such as permission changes and responsibility fallbacks MUST remain in a queryable location; pausing push notifications cannot drop the event, nor can it be treated as the recipient having become aware of it.

Related configuration: collab.private.attention.policy, collab.action.delivery.policy.

Boundary conditionsThis rule does not require every notification to be deletable; necessary events may be retained within the product, but external forced interruption must meet the declared emergency conditions.

Verification examplesAfter muting a thread, @-mention it repeatedly and check that ordinary push does not resume; when someone with no access permission is mentioned, they do not receive a content excerpt, nor are they automatically added to the shared scope.

CounterexamplesUnder-delivery — clicking @ on an external colleague grants them the entire project. Over-delivery — after muting, even permission-tightening alerts and pending tasks stop being shown.

C6-7Participation restrictions have a scope and an exit pathMUST¶

In one sentence: Blocking, leaving, and de-authorization each have consequences, and a restriction must also have a way to be lifted.

Applies toproducts that provide shared discussion, directed interaction, or member-participation restrictions.

Rule

1. The product MUST distinguish personal mute or block, restricting someone's participation, removing a person from a space, and revoking their access; the affected interactions and content MUST be stated before the operation, and using "block" to imply the shared object has become invisible to that person is forbidden.
2. A member MUST have a path to stop unwanted directed interaction and seek help from a clearly designated responsible party; help-seeking material is disclosed only to the authorized handler and must not be broadcast by default to all members or to the person being reported.
3. When an authorized party restricts speech, commenting, or joining, the scope of effect, the conditions for taking effect, the duration or review conditions, and the release path MUST be recorded. The restricted person MUST receive a status explanation that does not leak sensitive material, along with an available path for review.
4. Leaving a space MUST state the subsequent handling of responsibility, content, and permissions; a personal block or a departure MUST NOT silently delete someone else's contribution, and a member leaving also does not mean their historical content is entirely withdrawn.

Related configuration: collab.private.participation.policy.

Boundary conditionsThis rule specifies participation control within the product; it does not specify which speech is a violation or how an organization should adjudicate it. An emergency restriction may be executed first, but this must not be used as an excuse to omit controlled recording and a review path.

Verification examplesAfter A blocks B, check that the two parties' shared-file permissions remain unchanged; after restricting commenting, test the time limit, review, and release; when leaving, check task handoff and private content.

CounterexamplesUnder-delivery — a block button leads people to mistakenly believe the other person can no longer see the shared board at all. Over-delivery — when facing repeated harassment, one is required to publicly disclose every detail before muting is allowed.

4. Terminology and definitions¶

This chapter defines the terms used within these guidelines to judge behavior and outcomes.

4.1 Conformance determination¶

For every applicable rule, judge each independent obligation as "pass / fail / not applicable / unverified"; not applicable must state the capability and situational basis. A SHOULD-level deviation needs the reason, the alternative mechanism, and the corresponding verification stated. The number of people, sample size, and duration in the examples are test configurations, not universal performance thresholds.

Document review, mechanism verification, and user-comprehension verification each retain their own evidence and cannot substitute for one another. Over-privileged access, lost contribution, presenting unknown as success, or treating silence or no-reply as agreement — a failure in any applicable use case means a fail, not offset by an average score. After a change to audience, concurrency, save, or notification policy, re-verify the affected combined scenarios.

Appendix A: Fault-injection verification checklist¶

This checklist is for testing whether a clause actually takes effect; it adds no new obligation. Inject item by item and record the system's actual behavior; recording "not applicable" is an acceptable result; recording "not tested" is not.

A.1 Perception and visibility

A.2 Concurrency and conflict

A.3 Operation and responsibility

A.4 Private room

A.5 Classification test

Used to test whether the split in Chapter 1 holds: take 10 to 15 specific requirements (which may come from this document's clauses or from real review comments), and have at least three reviewers who were not involved in writing it independently judge which principle each belongs to. If ownership disagreement concentrates between two particular principles, it shows the regulatory objects of those two principles have not been properly separated — in that case, the principles should be adjusted, not given an intermediate layer or a mapping explanation. The two spots already known to need priority testing are flagged explicitly in Chapter 1 (C1 and C2, C4 and C6).

Appendix B: Evidentiary boundaries and source types¶

B.1 The basis for normative terms

The sole basis for marking something MUST is: without it, some promise made to the user would fail in a foreseeable situation. The following three categories of evidence provide different kinds of support; they are not three independent sources of mandatory force — an implementation reference alone is not sufficient to decide a MUST marking:

The five rules marked SHOULD (C2-6, C3-6, C4-6, C5-5, C6-5) are all tradeoff questions rather than baseline questions: a deviation may have legitimate reasons, but it must be recorded and subjected to the same verification. Among them, both C2-6's two response strategies and C4-6's aggregation granularity depend on the product's specific risk judgment, and this document does not give a uniform value.

B.2 The three thinnest points of evidence in this document

Listed explicitly, not masked by normative-sounding language:

1. C3-3's "auto-mergeable scope" lacks a cross-product general criterion. There is currently no citable, generally recognized list of which semantic combinations can be safely auto-merged; this document requires the product to declare business risk units, incompatible combinations, and an out-of-scope path, and to verify that original contributions are preserved; the combinations given in the text are a starting checklist, not an exhaustive list. This is the rule in this document most likely to be satisfied only formally without substance.
2. The granularity boundary of C1-3 and C1-6 depends on situational judgment. There is no universal dividing line between "enough for collaboration" and "enough to evaluate someone" that can be written into a clause; what this document gives is a criterion (whether it can be stated what specific collaboration problem it avoids, whether its use flows toward evaluating a person), not a field list. The acceptable range varies greatly across organizational cultures.
3. The implementation cost of C4-1 has not been assessed by this document. Maintaining a per-member undo stack and handling cross-member dependencies varies greatly in implementation difficulty across different data models; this document specifies only the nature of the behavior and has not assessed under what architecture the cost of this requirement might rise high enough to need a separate boundary condition. When a dependency cannot be safely handled, the undo may be declined with an alternative path stated; this cannot be used to forbid all undo that does not affect others.

B.3 What this document does not do

It does not give a synchronization algorithm (it does not prescribe operational transformation, conflict-free replicated data types, or locking as the required choice), does not give a permission model (it does not prescribe role-based, attribute-based, or an access control list), does not give an organizational structure, does not give retention-period values, and does not give an upper limit on conflict-prompt frequency. These are decisions for the product and the organization; this document only specifies that these decisions must be made, must be testable, and which values are not permitted.

B.4 Sources

The complete source cross-reference, verification status, and retrieval record are in reference.md. A clause in this document does not hold merely because some product has done it this way; a product's practice is evidence that "this kind of mechanism is feasible in a real product," not a basis for "it should be required this way."

Appendix C: Combined scenarios and acceptance records¶

This appendix consists of application examples; it adds no new obligation. Each verification checks the initiator, the recipient, any affected third party, and the actual data result together; seeing only a success message is not enough to determine a pass.

Minimum acceptance record: the task and object, applicable rules, roles and permissions, the configuration's actual values and source, the operation sequence, the injected fault, each party's visible state, backend or local evidence of the result, the pass conclusion, any unverified items, and the responsible party for handling them. User-side observation should also record whether the audience, result, and next step were understood; a user's lucky guess cannot mask a mechanism failure.

---

Implementation acceptance scenarios¶

The following scenarios convert existing clauses into reviewable acceptance inputs; they do not set a separate universal performance threshold. Select according to the product's applicable capabilities, and supplement with real devices, users, input sequences, and evidence; record the reason when not applicable, and something not executed must not be recorded as passed.

Each scenario separately checks the configuration's effective value, the execution record, and a result the user can understand. Retain the version, target, event timing, scope of failure, and recovery result; an unknown external result is not filled in as either success or failure.