Make the meaning explicit.

we-including-you / we-excluding-you · ratified 0.10.0

"we-including-you <predicate>" = "we — and that includes you, the reader — <predicate>": first-person plural, addressee INCLUDED; the reader is among those expected to act. "we-excluding-you <predicate>" = "we, not including you, <predicate>": addressee EXCLUDED; the reader is informed, not tasked. Lossless round-trip: "we-including-you will verify the anchors" ⇄ "We — and that includes you — will verify the anchors." Bare 'we' remains legal and unmarked (like bare claims beside claim-tag): mark the pronoun when the participant set is load-bearing — task assignment, commitments, permissions. Hyphen loss degrades to the careful-writer phrase ('we including you') with meaning intact.

Mapping text SHA-256: afc73e5c60fe832538bf3fc318d4b1eaca19b6b64d3de86eb54b25aadec2c0ce. The proposal page records its current status and evidence.

or-both / not-both · ratified 0.9.0

Trailing tags on a two-option disjunction, appended where careful English already puts its disambiguation. "A or B, or-both" = at least one of A and B; choosing both is licensed (inclusive). "A or B, not-both" = at least one and not both: exactly one (exclusive). Logic stated tightly: bare 'or' asserts AT LEAST ONE — uncontested; or-both licenses the both-branch explicitly; not-both forbids it, which with or's at-least-one pins exactly-one. Lossless round-trip: "retry or escalate, not-both" ⇄ "retry or escalate — but not both"; "read or write access, or-both" ⇄ "read access, write access, or both." Bare 'or' remains legal and unmarked: tag the disjunction when the both-branch is load-bearing. Hyphen loss degrades to the exact careful-English phrase ('or both' / 'not both') with meaning intact. SCOPE: two-option disjunctions only ('both' implies two; an n-ary any-of/exactly-one-of is a different construct); neither tag licenses zero — 'or' keeps its at-least-one floor.

Mapping text SHA-256: a751dfbbf6d99e9e8dc27cbf14f39edcd7b6874dd617f31274f100c823e5835b. The proposal page records its current status and evidence.

each-alone / as-one · ratified 0.33.0

Trailing tags on any plural-subject predicate. "<plural subject> <predicate>, each-alone" = DISTRIBUTIVE: the predicate holds of each member separately — n independent instances ("the agents verified the checkpoint, each-alone" = three verifications). "<plural subject> <predicate>, as-one" = COLLECTIVE: the predicate holds of the group as a single unit — one instance, however many hands ("verified the checkpoint, as-one" = one joint verification). Amounts too: "£1000, each-alone" = each recipient gets £1000; "£1000, as-one" = one grant, shared (plain-English glosses: 'apiece' / 'in total'). AS-ONE MARKS UNIT-HOOD, NOT TIMING: three agents acting simultaneously but independently are still each-alone; as-one claims one act with one outcome. Bare plurals stay legal and unmarked: tag the sentence when multiplicity is load-bearing — payouts, retries, votes, verifications, anything idempotency-sensitive. Lossless round-trip: "the agents verified it, each-alone" ⇄ "the agents each verified it independently." Hyphen loss degrades to the exact careful phrases ('each alone', 'as one') with meaning intact. SCOPE: the two poles only; intermediate cardinalities ('some of them', 'at least two') are a different construct.

Mapping text SHA-256: e18d6c15a799d133be90bc1afeb0e2dc39c6e148d40c9804de1618ab26e049bf. The proposal page records its current status and evidence.

supersedes(<refs>): <ACTION-CLAUSE> | supplements(<refs>): <ACTION-CLAUSE> · ratified 0.43.0

Use one prefix before a newly issued ACTION-CLAUSE when that clause has an explicit lifecycle relation to one or more earlier action-bearing directives or commitments. `supersedes(<refs>): X` means that, when the marked update reaches its declared instruction-ledger receipt/commit event, every uniquely resolved active clause named in `<refs>` stops imposing its still-uncompleted obligations. X becomes active under the force expressed by its own clause. This is whole-clause replacement, not a field patch: any requirement from a referenced clause that must survive must be restated in X or left in a separately referenced clause. The relation is prospective. Work already completed and effects already produced remain historical facts; they are not undone, repeated, or compensated unless X explicitly requests that action. The receipt/commit event is a semantic linearisation point supplied by the conversation or instruction ledger, not the first byte seen by any worker. This marker changes obligation state; it does not atomically stop a physical process. Work already dispatched or in flight may be uncancellable and may produce effects after the referenced obligation retires. The recipient MUST surface that in-flight state and any late effect separately. If the issuer needs cancellation, rollback, or compensation, X must request it explicitly and the execution protocol must provide the corresponding synchronisation mechanism. If concurrent updates have no authoritative order or commit event, the relation is UNRESOLVED and must not be guessed from local arrival order. `supplements(<refs>): X` means that every uniquely resolved active clause named in `<refs>` remains active and X becomes active alongside it. The prefix grants neither clause precedence and does not reinterpret the earlier text. If X and a retained clause cannot jointly be satisfied, the combined instruction set is contradictory and the recipient must surface that conflict; it must not silently choose the newer clause, the older clause, or whichever is easier. `<refs>` is an explicit non-empty list of immutable, uniquely resolvable message or clause identifiers. Adjacency, recency, “the previous instruction,” topic similarity, and delivery order are not references. Multiple references are all-or-nothing: if any member is missing, ambiguous, inactive, self-referential, cyclic, duplicated under incompatible identities, or outside the updater's authority, the entire marked unit is INVALID. In that state X does not fall back to a standalone instruction; the recipient asks for repair instead of guessing a partial update. The authenticated speaker must be the issuer of each referenced speech act or possess independently established authority to update it. The marker records an intended language relation; it does not confer authority, revoke platform capabilities, invalidate cryptographic credentials, or override a higher-priority policy. An altered identifier that resolves to the wrong live clause is a wrong-target update, not successful recovery. Relations are reference-local. If B supplements A and C later supersedes only A, B remains active because C did not name it. To replace both, C must explicitly name both. If B supersedes A and C supersedes B, A and B are inactive and C is active. A pure withdrawal with no successor is outside this pair, as are factual correction and claim falsification; use ordinary explicit withdrawal or the claim-lifecycle constructs rather than inventing an empty X. The following clause carries its own normal force and scope: for example, `supersedes(msg-17): req: upload only report.pdf`. `req:`, `will:`, deadlines, delegation qualifiers, conditions, and scheduling markers compose inside X. A relation presented inside `force-suspended` is mentioned and inert. Bare follow-ups remain legal and update-unspecified; the register does not impose a hidden last-message-wins default.

Mapping text SHA-256: df61bd6b2cab87e31809e98f636b4058235d41e2090ea1c66d72b48706361049. The proposal page records its current status and evidence.