# Witnessability Notation — Specification v0.4 Nov 3, 2026 · @ESSENTIS The Witnessability Notation is a visual vocabulary for one kind of picture: a claim situation — where a record was produced, who controlled that boundary, which claim the record is offered for, and where the inference stops. It is informative. It names the reporting distinctions of CBEE and the grounding classes of WEXP Core −02 by shape (WEXP's verdicts are stated in the report, not drawn; §5) and adds no semantics of its own; where a picture and the versioned text differ, the text prevails. ## 1. Status and scope **Status.** Proposed notation, version 0.4 (draft, §13), 3 November 2026, accepted by the founder as the current text on the same day (“Черновик принимаю”); it supersedes v0.3 of 1 November 2026 (with errata E-1 to E-6). Before accepting it, the founder decided D-10 (option B: a claim may be unranked; no ceiling sits directly above it, and a ceiling between ranked claims does not reach it), N-15 (option C: sources of version 0.4 state every boundary's grounding), N-18 (option B: a struck arrow may be marked as the boundary's limit on an unranked claim), E-5 (the enforcement bar's wording) and E-6 (the strike on a lintel), the last two applied to v0.3 as well. It supersedes v0.3 by the changes listed in the CHANGELOG under v0.4: the ceiling's label reads `ceiling of · ` (N-11); a ceiling may cite the premises it rests on (N-12), which makes `wn: "0.4"` a source version; a claim of a 0.4 source may be unranked (`rank: null`), which states that the author does not order it against the other claims of its kind; no ceiling sits directly above it, and a ceiling between ranked claims does not reach it; its boundary's limit is a struck arrow marked `limit` (D-10, N-18, decided by the founder; §5, §7); the Control, Trust and Authority Boundaries other than the control band are stated as a limit in §7 (D-2); the boundary line maps to the Core's Record-Production Transition or Interface, and boundary types that coincide in one component are stated as a limit in §7 (D-11, decided by the founder); the textual equivalent of §9 is the full report; the threshold text of §5 and §14 agrees with decision DR-6; §12 names generator 0.4.0, the bridge outputs and the render QA; and the corrections that followed the first external review of 3 November 2026 (R-1, §14): the readings of the refuted arrow, the downgrade, the ceiling, the linked support, the control band and the enforcement bar now say what CBEE −02 and WEXP Core −02 say; a boundary without a point makes no finding; a ceiling's reach depends on the order within a kind, which is the author's stated finding; sources of version 0.4 state every boundary's grounding; and the textual equivalent names every record unambiguously. Before R-1 no picture changed its findings. After R-1 some do, each for a recorded reason: the payment examples lose a ceiling that their premises did not ground, the Certificate Transparency example moves a claim for which a different type of evidence is relevant into a kind of its own, and the examples whose sources gave no grounding now state it. Informative. It is not a normative extension of the Witnessability Conceptual Core 1.0, of CBEE (`draft-sergeev-claim-boundaries-02`) or of WEXP Core (`draft-sergeev-wexp-core-02`). A diagram illustrates a report written under those texts; the report is the source, and the picture may be challenged against it. Errata to v0.3, applied here too: E-1 (2 November 2026, §5a), E-2 (3 November 2026, the ceiling), E-3 (3 November 2026, §5 boundary line and capability ring), E-4 (3 November 2026, §5 and §14 threshold text; the site figures' textual equivalent), E-5 (3 November 2026, the readings corrected after review R-1; the site figures state their grounding), E-6 (3 November 2026, the strike on a lintel only where that ceiling excludes the claim; §4, G-5). Errata to v0.4: E-7 (3 November 2026, §14 D-6, the public location: `/notation/` canonical, a fixed page per published version), E-8 (4 November 2026, §14: N-9 and N-10 listed as open, carried into the v1.0 candidate), E-9 (4 November 2026, §13: the errata to a published version are listed on its site page), E-10 (4 November 2026, §13 and §14 D-6: how errata apply to a published version), E-11 (4 November 2026, §14 D-5: the people named for the tests recorded by role), E-12 (4 November 2026, §10, §11, §12, §14 D-6, §15: statements that no longer held), E-13 (4 November 2026, §13 and §14: the licence decided), E-14 (4 November 2026, the opening, §1 and §15: what the notation names; the canvas redrawn). **Scope.** The notation covers one kind of picture: a *claim situation*. One action; the boundaries that observed it; the records those boundaries produced; the claims the records are offered for; the state of each offer; the premises everything rests on. It is used in Witnessability editorial pages, in figures of papers and Internet-Drafts, in slides and in boundary cards. **Out of scope.** Architecture diagrams, sequence diagrams, data models and anything that is not a claim situation. A reader who needs those uses the notation of that genre and keeps this one for the evidentiary layer. **Terms.** *Record*, *claim*, *evidence*, *relying party* are used in CBEE's general sense. *Witnessability Boundary*, *Record-Production Transition or Interface*, *Observation Locus*, *Capture Capability Envelope*, *Binding Relation*, *Effective Capture Coverage* are Core 1.0 §5 constructs. *Supported*, *unsupported*, *not evaluated*, *refuted* and *downgrade* are CBEE §reporting terms; *accept*, *downgrade*, *reject* are WEXP verdicts. **Companion artifacts.** The specimen canvas ("Witnessability Notation — visual vocabulary", seven artboards, eyebrows v0.4 since 4 November 2026) shows every mark drawn; the reference generator `wn-notation` renders diagrams from a text source to SVG and TikZ. This document is the one that governs: where the canvas or the generator disagrees with it, this document is corrected or they are. ## 2. Design principles Six commitments. Each is a test a reviewer can apply to any picture that claims to be in the notation. **One picture, one situation.** A diagram shows one action, the boundaries that observed it, the records they produced and the claims the records are offered for. Anything not drawn is not claimed; if two situations are needed, two pictures are drawn. **Every arrow carries a state.** An arrow is an offer of a record for a claim, and it has exactly one of four states: supported, unsupported, not evaluated, refuted. The shape carries the state; the word beside the arrow restates it; colour never does. An arrow without a state is a sketch. **Premises travel with the picture.** The premises block — evaluator, evaluated set, accepted premises, items not evaluated — is part of the diagram in every medium and at every size. A diagram without it is published as a sketch or not at all. **Colour has one meaning.** The accent appears only on the observation point: the place where something was observed. Everything else is ink on paper. The dark theme swaps paper and ink and lightens the accent; nothing else changes. **Three line qualities, one scale.** Solid means established or observed. Dashed means declared or asserted — the producer's own account, not yet grounded. Dotted means absent: no record, no finding. The same scale applies to boundaries, records and arrows, so a reader learns it once. **Words with every mark.** Boundaries, parties and kinds are named in words, never by icon. Claims are the exact proposition, as text. A mark that cannot be read aloud is not in the notation. ## 3. Abstract syntax A diagram is a tree of typed elements. The list below is the whole vocabulary; the generator's source format is a direct transcription of it (§12). **Diagram.** title; optional action (the action the claims are about); optional ordered list of kinds; bands; claims; arrows; ceilings; ties; coverage brackets; downgrades; premises; evaluator; evaluated set; not-evaluated items; reliance flag. **Band.** id, label (the controlling party), one or more boundaries. One band = one party's control over its boundaries and the paths their output travels. **Boundary.** id, label, `declared` (v0.1; in v0.2 the boundary carries grounding ∈ {asserted-only, attributed, attested}, the classes of WEXP Core −02 §7; declared: true reads as asserted-only; v0.4 adds not-evaluated, also a WEXP class, and in sources of version 0.4 the grounding is required and only `grounding` states it, N-15: a source of 0.1 or 0.2 that gives none still reads as attested, with a warning. The class grades the boundary's description, not its records: attributed means that a description of the boundary is signed under an identity the evaluator accepts, WEXP Core −02 §7), `enforcement` (true when the boundary is an enforcement point that the party whose conduct the claim describes does not control and cannot bypass, E-5), zero or more observation points, zero or more detached assertions. Maps to the Record-Production Transition or Interface, Core 1.0 §5.4, a type of the Witnessability Boundary of §5.3 (v0.4, D-11). With its points and its band, the element is CBEE's producing boundary: where the evidence was produced, what that vantage point could observe, and who controls it. A ceiling names the element. **Point.** id, `observed` (true: an observation is evidenced; false: capability without capture), one or more records. Maps to Observation Locus and Capture Capability Envelope, Core 1.0 §5.4. **Record.** id, label, tags (verified properties such as signed, registered, proof; PROV and IV are not record tags, WF-14), form ∈ {record, assertion, absent}. A record belongs to exactly one point, except an assertion, which may be detached from any point. **Claim.** id, text (the exact proposition), kind, rank (an integer, or null; higher is stronger within the kind only. CBEE −02 reads “stronger” and “weaker” within the kind of claim at issue and has no scale or ranks of its own; the rank is the author's statement of that order, and a ceiling's reach depends on it, so it is part of the finding; see §5b. In a source of version 0.4 a claim with `rank: null` is unranked: the author states no order between it and any other claim of its kind (D-10, decided by the founder on 3 November 2026: option B). In a kind with more than one claim every claim states its rank, an integer or null, so that an omission is never read as “not ranked” (WF-5); the only claim of a kind may omit it. In sources of 0.1 and 0.2 an absent rank reads as 0, as before), type (optional; a WM 2.0 proposition type: Obs, Auth, Inv, Exec, Orig, NonExec; the claim's identity across levels, rule R-2). Maps to Target Proposition, Core 1.0 §2.1; kinds follow CBEE −02 §5: a kind is a family of claims to which the same type of evidence is relevant, such as the bases of §4. **Arrow.** one source record, or two or more source records for a linked support (with an optional threshold: a label, or the structured form {k, n} or {t}, from which the label is derived; for a supported linked support with budget t the generator requires records in at least 2t + 1 separately controlled bands), target claim, state ∈ {supported, unsupported, not-evaluated, refuted}, cited premises, optional note (a rule number, a reason such as “unverifiable”), optional `limit` (v0.4, N-18: on an unsupported arrow from one record to an unranked claim, the arrow states the boundary's limit on that claim, not a gap in the evidence set; WF-20). One arrow per (record, claim) pair. **Ceiling.** boundary, kind, `above` (the claim directly below the ceiling, or none: the ceiling sits below the whole stack and the boundary warrants no claim of that kind), cited premises (optional, v0.4: the premises under which the boundary places this limit). Maps to the claim ceiling of CBEE −02 §5; its model-level counterpart is the Model's Boundary Ceiling (Witnessability Model 1.1, Axiom BC). The Core's Boundary Ceiling Rule (Core 1.0 §6.5), which limits what may be said about a property preserved across a boundary, is a related rule, not the same one. **Tie.** two records, `established` flag, optional label. Maps to Binding Relation, Core 1.0 §5.4. **Coverage.** boundary, and either a label or the closed channel set C with interval and cutoff, from which the label is derived (WM 2.0 §8.1: closure is a premise, not a record). Maps to Effective Capture Coverage and CBEE rules 4–5. **Downgrade.** source claim (asserted; unsupported or not evaluated), target claim (the strongest claim of the same kind that has a supported arrow). Maps to CBEE −02 §11, “downgrade to the supportable claim”. Not a protocol verdict (§5). **Premise.** id (P1, P2 …), text. The premises block also carries the evaluator, the evaluated set and the items not evaluated. ## 4. Concrete syntax Geometry is given at 1× (the site). Slides use 2.4×; print converts px to pt at 0.75 and keeps 0.4 pt as the hairline floor. Type: claims in IBM Plex Mono 13/18; record labels in Plex Mono 12/16; tags, kinds, boundary and band labels in Plex Mono 11/16, uppercase, tracking 0.08 em, secondary colour; premises in Plex Mono 11/16, secondary; captions in Plex Sans. Plex Serif is for titles around a picture, never inside it. **Core marks (8)** — the set a reader must know. - **Boundary** — vertical hairline, 1 px ink. Label above its top end. Production crosses it left to right. - **Observation point** — 8 px filled circle in the accent, centred on the boundary line. The only accent in the picture. - **Record** — box 28 px tall, 1 px ink border, label in Mono 12; tags follow the label after a middle dot in secondary. Joined to the point by a 16 px tick. Width fits the longest label on the page (min 100 px, max 300 px). - **Claim** — Mono 13/18 text, no box, left-aligned in a 280 px column; a kind tag above the stack. Stronger claims of one kind sit higher. The unranked claims of a kind (v0.4, D-10) sit below its ranked claims, under the eyebrow `not ranked · no order of strength` when the kind has more than one claim; no ceiling is drawn between them, and their order is that of the source. - **Supports** — 1.5 px shaft, round caps, filled head (5×5 marker units). Label above the shaft, right-aligned 6 px before the tip: `supported · P1, P2`. - **Does not follow** — the same arrow with a 9 × 9 px strike across the shaft at 45°. The strike sits where the arrow crosses a ceiling of its own boundary that excludes the claim; otherwise 18 px before the tip (E-6: a lintel that does not exclude the claim, such as one crossed on the way to a claim below it or to an unranked claim, does not take the strike). Label `unsupported`. A limit (v0.4, N-18): the same strike, label `unsupported · limit`, its premises after it on a straight arrow, or below on an elbow. - **Not evaluated** — dotted shaft (0.5 on, 4 off, round caps), open head filled with paper. Label `not evaluated`; the reason on a second line below. - **Ceiling** — horizontal hairline with 6 px downward ticks at both ends, spanning the claim stack and, when an arrow crosses it, extended left to that arrow's channel. Label above, right-aligned: `ceiling of · `, then the ids of the premises it cites, if any: `ceiling of operator service · effect · P3` (v0.4, N-11 and N-12; a source of version 0.1 or 0.2 keeps the label of its rules, `ceiling · · `). When the ceiling sits below the whole stack the label adds `(reaches none)`; a source of 0.1 or 0.2 keeps `(no claim of this kind)`, which review R-1 showed could be read as saying that the kind has no claim. **Extended marks (13)** — used when the situation needs them. - **Declared boundary** — asserted-only grounding: the boundary hairline dashed 4/3. Attributed: solid hairline with the label suffix · attributed. Attested: solid hairline. (WEXP Core −02 §7 classes; v0.1 declared: true = asserted-only.) - **Capability, no capture** — 8 px ring, 1.5 px accent stroke, paper fill, on the boundary. - **Assertion** — record box dashed 4/3, tag `asserted`; drawn beside the boundary without a point. - **No record** — record box dotted 1/3, label `no record`, at a point drawn as a ring. - **Refuted** — solid shaft ending 6 px short of a 9 px cross at the tip; no head. Label `refuted · `. - **Downgrade** — vertical 1.5 px arrow, filled head, 16 px right of the claim column, from the asserted claim to the supported one; label `downgrade`. - **Binding tie** — 1 px secondary line between two records with 5 px open squares at both ends; dashed until established; optional label. - **Coverage bracket** — 1 px secondary line with 6 px upward ticks, under the records of a boundary; label below: interval, capture rule, cutoff. - **Enforcement point** — 14 × 2 px bar across the boundary. - **Reliance line** — two vertical hairlines 3 px apart at the right edge, label `reliance`. - **Control band** — rectangle in the tint, no border, party label in the top-left corner; one band per party; 16 px between bands. In monochrome (the rfc profile, §8) the tint has no value and the band is drawn as a 0.5 px outline — thinner than the 1 px boundary hairline and the 1 px record border (DR-9, 1 November 2026). - **Linked support** — several records warrant one claim only together: a 1.5 px stem from each record into one vertical 1.5 px bar in its own channel, and one arrow from the bar to the claim at the claim's row. A stem that ends on the bar carries a 5 × 5 px filled ink square (junction); a line that merely crosses a bar carries none. The state label names the threshold: `supported · 2 of 3`, `unsupported · one domain`. Stems and bar take the state's line quality (dotted for not evaluated). - **Premises block** — hairline rule in line colour, eyebrow `premises and scope`, then Mono 11/16 lines: `V evaluator · evaluated set: …`, `P1 …`, `— not evaluated: …`. **ASCII forms (v0.3).** The same marks drawn with the characters RFC artwork uses, for the text rendering of an Internet-Draft or RFC (§8, “Internet-Drafts and RFCs”), at most 69 columns. Boundary: `|`, with `*` at an observation point and `o` for a capability without capture; an asserted-only boundary is `:`. Record: a `+--+` box; an assertion has `- -` top and bottom and `:` sides; no record has `. .` and `.`. Supports: `---->`; not evaluated: `. . >` with an open head; does not follow: `/` across the shaft; refuted: `X` at the tip. Ceiling: a lintel `+------+` with its label on the lines above, right-aligned. Control band: a box with its label inside; the action under the label. Binding tie: `o` `|` `o`, `:` until established. Coverage bracket: `+---+` under the records with the label below. Enforcement point: `=|=`. Linked support: one stem per record into a vertical bar, `+` at each junction. Downgrade: `|` ending in `v`. Reliance: `||`. The unranked claims of a kind (v0.4): the line `NOT RANKED - NO ORDER OF STRENGTH` above them, wrapped to the claim column. The state label sits on the line above the shaft, right-aligned at the tip; threshold, premises and note on the lines below. Everything inside a band wraps to the band's width, claims wrap to what is left, and a picture that cannot fit in 69 columns is split, as §12 advises for tall pictures. The typographic characters of the labels are mapped (`·` → `-`, `—` → `--`). The glyph choices are the generator author's of 1 November 2026 and are open to revision by the project. **Grid.** 8 px base; records 28 px tall with 12 px gaps; claim rows 18 px lines with 12 px between claims and 20 px between kinds; 22 px for a ceiling row; the column gap between records and claims is at least 96 px: 26 px, plus a 12 px channel per elbow and one spare, plus the widest arrow label and 12 px. **Colour roles.** Light: paper #F6F3EE, ink #141412, secondary #5B5853, accent #9A3B26, tint #EAE5DC, line #D4D0C9. Dark: paper #141412, ink #F2EFE9, secondary #B1ADA5, accent #D0613F, tint #23231F, line #3B3A35. ## 5. Semantics Each mark has one reading, fixed by a definition in the Witnessability Conceptual Core 1.0, the CBEE or the WEXP Core. The second line of each entry says what the mark does **not** mean, because the common misreadings are the ones the notation was designed to block. **Boundary line** = a Record-Production Transition or Interface (Core §5.4, a type of the Witnessability Boundary of §5.3; v0.4, D-11): where an observation, a signal or a processed input of the action becomes a persistent or transferable record. A line drawn without an observation point makes no finding about whether capture occurred or a record was produced there: it shows only that the author places a boundary there. Any finding about absence is limited to the evaluated set and the coverage the premises establish (CBEE rule 5), and is drawn as a no-record box inside that coverage. It is a property of the system's topology at the time of the action. Does not mean: a network perimeter, an organisational unit or a security control. Those are Control, Trust or Authority Boundaries (Core §5.4); control is shown as a band, trust and authority are not shown (D-2). Nor does it mean that a signature, an endorsement or an attestation was produced there (§7, “Coinciding boundary types”). **Observation point** = an Observation Locus (Core §5.4) at which capture actually occurred for this action: a record exists. Does not mean: that the record is correct, complete or trustworthy. The point says only that something was captured there. **Capability ring** = a Capture Capability Envelope without a capture: the party could have observed and did not, or no record of the observation survives. Does not mean: that nothing happened. CBEE rule 5: absence of a record is evidence of non-occurrence only within established coverage. **Record box** = a verified artefact: the evaluator holds it and has checked the properties written as tags. Tags are verified properties only. Does not mean: the artefact's content is true. A signature verifies the signer and integrity, not the statement signed. **Assertion box** = an artefact or statement the evaluator has not verified, or whose basis is the producer's own description. It may still be the strongest available input; it is drawn so the reader never mistakes it for a record. **No-record box** = the evaluator looked at a point where capture capability is established and found nothing. Drawn only inside established coverage; outside coverage the point and the box are omitted, because “no record” would say nothing. **Claim text** = a Target Proposition (Core §2.1), written literally. Its kind names the base at which it is made (CBEE §bases: observation, intent, invocation, execution, effect, and the reporting kinds such as statement, registration, completeness). Position in the stack is strength within the kind only, and only among ranked claims: the claims under `not ranked · no order of strength` have no order of strength (v0.4, D-10). **Supports arrow** = under the cited premises, the record warrants the claim. The evaluator asserts this; the arrow is the evaluator's finding, not the producer's. Does not mean: the claim is true in the world. It means the evidence meets the bar the premises state. **Linked support** = the records joined by the bar warrant the claim jointly and none of them warrants it alone (the linked, as opposed to convergent, support of argument mapping). The threshold on the label says how many of them must be faithful for the finding to hold ({k, n}), or how many may fail ({t}). Its value is the evaluator's. Given in the structured form ({k, n} or {t}), the label is derived from it, and the generator checks it against the picture: n against the number of joined records, and, for a supported linked support with budget t, the records against at least 2t + 1 separately controlled bands (WF-14, decision DR-6). The generator does not compute the value itself (§14, D-7). The bar is the picture's way of drawing a joint support of the technical manuscript. The bands around it show the control the author has established. The check of 2t + 1 separately controlled bands is a check that the stated threshold agrees with the picture's structure; it does not show that the records are independent for the claim. That rests on premises: which capabilities of which party or coalition matter to the claim, under which threat model, over which period, and which dependencies the records share (CBEE −02 §8.1). Does not mean: that each record supports the claim a little. A record that is in a linked support is not drawn with its own arrow to the same claim (WF-7). **Struck arrow** = the record was offered for the claim and the evaluator finds that the claim does not follow (CBEE §reporting: unsupported). The claim may still be true; the point is that this record does not get the reader there. Does not mean: the claim is false. That is the refuted arrow. Struck on a lintel of its own boundary, the arrow meets that ceiling's exclusion; to an unranked claim, a plain strike is a gap in the evidence set and a strike marked `limit` is the boundary's limit (v0.4, N-18). **Limit** (v0.4, N-18) = a struck arrow marked `limit`: under the premises it cites, no record from this record's boundary can warrant this unranked claim, whatever the record's quality. It is the meaning of a ceiling (CBEE −02 §5), drawn on the arrow of a claim that has no place in an order, where a lintel cannot stand (D-10). Does not mean: that the claim is false; that another boundary cannot reach it; or a gap in the evidence set, which, for an unranked claim, is a plain strike. **Not-evaluated arrow** = the pair was in scope but not assessed, with the reason given (outside the evaluated set, unverifiable, out of time). CBEE requires evaluated and not-evaluated to be stated separately; the dotted arrow is the picture's way of keeping that separation visible. **Refuted arrow** = under the cited premises, the evidence supports the negation of the claim (CBEE −02 §11); the basis is named on the label, and in a source of version 0.4 a refuted arrow without a basis is an error. Does not mean: that the record casts doubt on the claim, or that the claim lacks support; doubt and lack of support are drawn as unsupported. Used sparingly: most negative findings are “unsupported”, not “refuted”. **Ceiling** = the claim ceiling (CBEE −02 §5): the limit that records from this boundary place on claims of this kind, under the stated premises, whatever the records' quality. A claim above the ceiling is unreachable from this boundary even by a perfect record. A ceiling is an exclusion rule, not an evidence source. Does not mean: that the claim above is false; that another boundary cannot reach it; or that a claim below it is supported — support still needs a supported arrow from a record. A second boundary may have a higher ceiling for the same kind. The ceiling sits between claims ordered by rank, and what it excludes follows from that order; the order is therefore part of the finding, stated by the author and open to challenge like a premise. CBEE −02 §5 does not presume that all claims of one kind are comparable, or that one strongest claim exists. A kind is a family of claims to which the same type of evidence is relevant (CBEE −02 §5): a claim for which a different type of evidence is relevant belongs to another kind. A ceiling between claims needs their order: it sits directly above a ranked claim (WF-19) and excludes the ranked claims above it. An unranked claim has no place in that order, so such a ceiling does not reach it, and where the kind has unranked claims, a lintel between ranked claims draws the boundary's limit on the ranked claims only. Where the boundary cannot reach an unranked claim, its arrow is struck and marked `limit` (N-18), and the premises it cites give the grounds that concern the boundary, as a ceiling's would; a plain strike to an unranked claim is a gap in the evidence set. A ceiling that reaches none needs no order and excludes every claim of its kind, ranked or not (§7, D-10). A ceiling needs grounds that concern the boundary: its premises say why no record from this boundary can reach the claims above it, whatever the record's quality. That the records in the set lack what a claim needs is not such a ground; it is an unsupported arrow. The premises a ceiling cites are the stated premises under which it holds; they are numbered in the premises block like those of an arrow. Does not mean: that the premises make a claim below the ceiling supported. **Claims not ranked** (v0.4, D-10) = the claims under the eyebrow `not ranked · no order of strength` are of one kind, and the author states no order of strength between them, or between any of them and the ranked claims above. Does not mean: that the upper one is stronger; that they belong to different kinds; or that a ceiling between ranked claims reaches them. **Downgrade** = the CBEE report's downgrade to the supportable claim (CBEE −02 §11): the asserted claim is unsupported or not evaluated, and the evaluator reports, alongside it, the strongest claim of the same kind that the evidence does support. The arrow points from what was said to what stands. Where there is no unique strongest supported claim, CBEE reports the supported claims, and the picture shows them by their supported arrows without a downgrade arrow; two supported claims of which one is unranked have no unique strongest (D-10). A downgrade joins two ranked claims, the target the weaker (WF-11): an unranked claim is not ordered against any other, so no downgrade goes to or from it, and the supported arrows show what stands. Does not mean: a protocol verdict. Where the claims are typed claims of WEXP Core, its verdict `downgrade` covers more cases: counter-evidence that blocks an exactly supported claim, and supported alternatives above the assertion, incomparable with it, or none at all (WEXP Core −02 §8.2, §8.3). A verdict is stated in the report and the premises block, not drawn. **Binding tie** = a Binding Relation (Core §5.4): the evaluator has established that two records concern the same event or object (matched identifiers, compared digests, co-registration). Dashed while the binding is asserted but not established. Does not mean: the two records agree. They can be bound and contradict each other. **Coverage bracket** = Effective Capture Coverage (Core §5.4): the interval and capture rule within which absence of a record is informative. **Enforcement bar** = an enforcement point that the party whose conduct the claim describes does not control and cannot bypass, positioned so that the action cannot complete without it (CBEE −02 §8, control-topology test). It sits in the band of the party that controls it, which is not the band of the party in question. Bypassing it is circumvention, which also covers directing the point's decision (CBEE −02 §8.1); the premises of the findings that rely on the bar say why the party in question can do neither. Does not mean: that the party cannot act out of sight of a record; that is concealment, a separate capability, on which the bar says nothing. **Reliance line** = the evaluator notes that a party relies on this finding without having independent access to the records. It carries no verdict of its own. **Control band** = one party's control over the boundaries and the output paths inside it. Two observation points inside one band are under one party's control, however different they look, so neither is independent of that party for any of its capabilities that matter to the claim. Separate bands show separate control as the author has established it. Whether records are independent for a claim turns on which capabilities matter to it and what grounds their limits (CBEE −02 §8.1), and control over delivery does not give control over the source (ibid.); the bands are where those premises are drawn, not proof of them. **Premises block** = the scope line of the report: who evaluated, what set of claims was in scope, what was not evaluated, and the numbered premises every arrow label cites. A picture without it is a sketch of a situation, not a diagram of a finding. ## 5a. Relation to existing notations The notation reuses conventions its readers already know and says so, because a borrowed convention is read fast and a disguised one is read wrong (Moody's cognitive integration, §10). For each neighbour: what is borrowed, what differs. **Data-flow diagrams with trust boundaries** (threat modelling: STRIDE tooling, OWASP Threat Dragon). Borrowed: the boundary as a line that production crosses, drawn apart from the boxes. Differs: a trust boundary says who is trusted on each side; a witness boundary says who could capture what. The two can coincide and often do not; a diagram of this notation never marks trust. **Assurance cases: GSN** (Community Standard v3, 2021), **CAE, SACM** (OMG metamodel). Borrowed: claims as text, evidence as a distinct node, “supported by” as the relation; the name of the supports arrow is a deliberate echo. Differs: GSN argues top-down from a goal through strategies to solutions and asks whether the argument is complete; this notation starts from topology and asks what records of a boundary can warrant at all. GSN has no ceiling and no notion of producer control; its “undeveloped” mark flags a goal or strategy not yet developed, not a relation left unevaluated; its evidence node has no boundary. A GSN solution node can cite a diagram of this notation as the appraisal of its evidence. **Provenance graphs: W3C PROV** (entity, activity, agent). Borrowed: the record as an artefact distinct from the activity that produced it; the tag `PROV` names the verified relation. Differs: PROV records lineage as asserted by a producer; this notation records what an evaluator established, and draws producer assertions dashed. **Sequence and ladder diagrams** (IETF drafts, UML). Borrowed: vertical lines and left-to-right reading. Differs: a ladder diagram shows messages between parties in time; this notation shows no time and no messages, only what was captured and what it warrants. A ladder diagram of a protocol and a boundary diagram of the same run are complementary, not substitutes. **Attack trees and MITRE Attack Flow** (v4, 2026). Borrowed: nothing in form. Related in purpose: both describe what an adversary could do. The control band and the enforcement bar answer a question Attack Flow does not ask: whether the party that produced a record could have bypassed the point that produced it. **Argument diagrams: Toulmin, Wigmore charts, argument maps** (AIF). Borrowed: the premise as a first-class, numbered element that an inference cites; the “does not follow” mark has an ancestor in Wigmore's symbols for weakened inference; and the linked support is the linked-versus-convergent distinction of argument mapping (Beardsley 1950, Thomas 1973), drawn with the junction convention of electrical schematics; GSN v3's “m of n” choice is the nearest ancestor of its threshold label. Differs: those notations grade the strength of support; this one refuses to (§7) and reports the evaluator's four states only. **Flowcharts and swim lanes** (ISO 5807; control-point markings in audit walkthroughs). Borrowed: the band as a lane for one party. Differs: a lane carries process steps; a band carries capture points and records, and two points in one band are never independent of that band's party. What the notation exists for: these marks together, on the relations of one claim-relative figure — the ceiling, the struck arrow for non-inference, the dotted not-evaluated relation, and control read off topology, with independence for a claim stated as a premise rather than implied by the drawing. The neighbours above lack them. Other fields have ancestors of each, some partial: for independence, the stemma codicum (Maas 1927) and the shared basic event of a fault tree (IEC 61025); for the ceiling, the detection, recognition and identification levels of video surveillance (IEC 62676-4); for the struck arrow, Pollock's undercutting defeater, which Verheij's ArguMed draws as an exception blocking a link; for the not-evaluated relation, GSN's “undeveloped” mark and ROBINS-I's “No information”, both on an element or a cell rather than a relation. What is new is the combination, not the marks. ## 5b. Levels: one programme, three registers The programme describes the same situations at three levels, and a reader must never mistake one for another. The rules here are adapted from the ARIS architecture (Scheer): one diagram type per level, one identity for an object across levels, refinement downwards only. ARIS kept its levels consistent with a tool-enforced repository; here the repository is the YAML source and its ids, and nothing else. **Level 1 — conceptual** (articles B and A). Objects: event, trace, medium, witness region, addressee, forum; the five axes (discrimination, persistence, multiplicity, independence, accessibility). Diagram type: the capacity diagram of article B, Figure 1. The marks of this notation are not used at this level; only its type scale, its line-quality scale and its single accent are. **Level 2 — model** (Witnessability Model 1.1 and 2.0; the technical manuscript, §§3–6). Objects: histories, records as functions of histories, admissible transformations (binding), failure families, separation margin, content levels WL0–WL3 with the qualifiers PROV and IV, the composition rule. Mostly tables and formulas; where a picture is needed it is the Model's ladder-and-ceiling figure, not a boundary diagram. **Level 3 — evaluation** (CBEE, WEXP; this notation). Objects: bands, boundaries, points, records, claims, arrows, ceilings, ties, coverage, premises. The boundary diagram. **Level 4 — protocol** (WEXP message flows as IETF ladder diagrams) lies outside this specification. **Rules.** - R-1 — One diagram type per level. A figure states its level in its first eyebrow or its caption: conceptual, model or evaluation. - R-2 — One object, one identity. A record, boundary or claim that appears at two levels carries the same id; its label may differ, its id may not. The YAML source is the repository. - R-3 — Refinement goes down. A level-3 picture may refine a level-1 or level-2 statement; it never redefines it, and nothing drawn at level 3 is read back as a claim about capacities or histories. - R-4 — Marks do not travel. The dot, the strike and the ceiling are not reused at level 1 with a looser meaning. What travels is type, the line-quality scale and the accent. - R-5 — Every row of the correspondence below is a testable claim: the lower-level picture must decide what the higher-level statement asserts, or the row is removed. **Correspondence (draft, to be tested under §11).** - Witness region (1) ↔ observation point on a boundary (3). A region with capability and no capture is the ring. - Trace (1) ↔ record (3), only once captured; the trace itself has no mark at level 3. - Medium (1) ↔ bands and the paths records travel (3). - Independence, axis (1) ↔ failure family, separate domain (2) ↔ separate band (3). Two records in one band are never independent of that band's party. - Discrimination, axis (1) ↔ separation condition and margin (2) ↔ supports or struck arrow, linked support with its threshold (3). - Multiplicity, axis (1) ↔ number of reports (2) ↔ number of points and records (3). - Persistence, axis (1) ↔ erasure and corroboration over time (2; article A) ↔ record form solid, dashed, dotted (3). Time itself has no mark (§7). - Accessibility, axis (1) ↔ addressee and forum (1) ↔ evaluator, evaluated set and reliance line (3). What this buys: article B's figures and a CBEE boundary diagram can stand side by side without either pretending to be the other, and the two architectures of §7.3 of the technical manuscript are level-3 pictures of level-2 statements (examples `fig-7-3a` and `fig-7-3b` of the reference implementation). ## 6. Composition grammar and well-formedness **Reading order (G-1 … G-6).** Pictures are read left to right and top to bottom, and the grammar follows that order. - G-1 — Production is on the left, claims are on the right. Bands, boundaries, points and records occupy the left part of the frame; the claim stack occupies one column at the right; arrows run left to right. Nothing produces a claim from the right. - G-2 — One band per controlling party; bands are stacked vertically and never overlap. A boundary belongs to exactly one band. - G-3 — Records of one boundary are stacked under their observation point in the order they were produced, top to bottom. A record's vertical position is otherwise free; the generator aligns it with the first claim it is offered for. - G-4 — Claims are grouped by kind, kinds in the order of the CBEE bases (or the explicit order the author gives); within a kind the stronger claim is higher, and the unranked claims sit below the ranked ones under their eyebrow (v0.4). A ceiling is a horizontal line between two ranked claims of one kind, or below the lowest claim. - G-5 — An arrow is a straight line or a single two-elbow route in a vertical channel between the record column and the claim column. Arrows never pass through a record, a band label or another arrow's label. A ceiling an arrow must cross is extended left to that arrow's channel, and the strike is placed at the crossing, when that ceiling excludes the arrow's claim. - G-6 — The premises block is the last element, full width, under a hairline. Everything cited in the picture is resolvable in it. **Well-formedness (WF-1 … WF-20).** These are the rules the reference generator checks (`python -m wn check`). All are errors and stop rendering, except WF-12, which is a warning. - WF-1 — Record ids and claim ids are unique. - WF-2 — A record has a non-empty label and a form in {record, assertion, absent}. - WF-3 — A record with no observation point is an assertion. Only an assertion may be detached from a boundary. - WF-4 — A claim is non-empty literal text and carries a kind. - WF-5 — Within one kind, ranks differ: the stronger claim sits higher, so two ranked claims of one kind cannot share a rank. A rank is an integer, or null for an unranked claim (v0.4, D-10). In a source of version 0.4, in a kind with more than one claim, every claim states its rank. - WF-6 — Arrows run from a record to a claim. Claims never point at claims: a chain of inference is drawn as separate arrows from the record, or as a downgrade. - WF-7 — One arrow per (record, claim) pair, with exactly one of the four states. A record is offered for a claim once: alone or inside one linked support, never both. - WF-8 — A premise cited on an arrow or on a ceiling exists in the premises block. - WF-9 — A ceiling names an existing boundary and a kind present in the picture; `above` names a claim of that kind. - WF-10 — Tie ends are records. - WF-11 — A downgrade stays within one kind, joins two ranked claims and goes to the weaker (v0.4: an unranked claim takes no downgrade, D-10). A claim of another kind is a separate finding, not a downgrade. - WF-12 (warning) — A refuted arrow names its basis; a diagram without a premises block is a sketch. The generator also warns about a record offered for no claim. - WF-13 — A linked support joins two or more distinct records; a single record is an ordinary arrow. A threshold belongs to a linked support only. - WF-14 (v0.2; v0.4) — The version is 0.1, 0.2 or 0.4 (v0.3 added no source field); premises on a ceiling need version 0.4. A boundary's grounding is asserted-only, attributed or attested. A claim's type, if given, is a WM 2.0 proposition type. PROV and IV are not record tags: PROV is the proposition type Orig, IV a threshold on a linked support (decision Q-1, 31 October 2026). A structured threshold is {k, n} with n equal to the number of linked records and 1 ≤ k ≤ n, or {t}; in a source of version 0.4 a free `label` given with it must begin with the derived label (“2 of 3”, “t = 1”). A supported linked support with budget t has its records in at least 2t + 1 separately controlled bands (WM 2.0 §4: decided iff the margin exceeds 2t); the generator refuses the picture otherwise. - WF-15 (v0.4) — In a source of version 0.4 every boundary states its grounding in the field `grounding`: asserted-only, attributed, attested or not-evaluated (N-15); `declared` does not state it. A source of 0.1 or 0.2 without either reads as attested, as before, and the generator warns. No ceiling names a boundary whose grounding is not-evaluated, and no limit (N-18) leaves a record of one: such a boundary has no usable ceiling (WEXP Core −02 §7), in every source version. - WF-16 (v0.4) — In a source of version 0.4: a no-record box stands only at a boundary with established coverage (CBEE rule 5), and at least one finding from it cites a premise, since the closure of the coverage is a premise, not a record; a not-evaluated arrow gives its reason; a refuted arrow names its basis (WF-12 becomes an error); a ceiling cites at least one premise, its grounds. In 0.1 and 0.2 sources these are warnings. - WF-17 (v0.4) — A downgrade's asserted claim has arrows, all of them unsupported or not evaluated, and its target is the strongest claim of the kind that has a supported arrow (CBEE −02 §11); where the kind has no unique strongest supported claim, as when two supported claims include an unranked one, no downgrade is drawn. A supported arrow does not reach a claim that the ceilings of its records' boundaries exclude, or that a limit (N-18) from the same boundary excludes: for a single record, its boundary's ceiling of that kind or limit on that claim; for a linked support, the ceiling or limit of every joined record's boundary. Both are errors in every source version, since either makes the picture contradict itself. - WF-18 (v0.4) — In a source of version 0.4, the ids of bands, boundaries, points, records, claims and premises are unique across the source. - WF-19 (v0.4) — A ceiling's `above` names a ranked claim: a ceiling between claims needs their order (D-10). A ceiling directly above a ranked claim excludes only the ranked claims above it; a ceiling that reaches none excludes every claim of its kind, ranked or not; WF-17 applies the exclusion so read. - WF-20 (v0.4, N-18) — `limit` stands only in a source of version 0.4, on an unsupported arrow from one record (not a linked support) to an unranked claim, and the arrow cites at least one premise, its grounds, as a ceiling does (WF-16). A ranked claim is limited by a ceiling. The generator checks WF-20 before WF-17. **Minimal diagram.** One band, one boundary, one observation point, one record, one claim, one arrow with a state, and a premises block with the evaluator and one premise. Anything smaller is an illustration of a mark, not a diagram. ## 7. What the notation cannot express A notation is defined as much by what it refuses to draw. The following are deliberate gaps; a reader who wants them must go to the report text, and an author who finds a way to draw them inside the notation has broken it. **Likelihood.** There is no mark for “probably”, no arrow thickness, no shade of grey. An arrow is supported, unsupported, not evaluated or refuted. CBEE reporting has those categories and no others; the picture must not invent a fifth. **Ranking across kinds.** A claim about execution is not “stronger” than a claim about intent; they are claims at different bases. Vertical position compares claims of one kind only, and a downgrade cannot cross kinds (WF-11). **Event time.** Records of one boundary are stacked in production order, but there is no time axis. Two records in different bands cannot be read as earlier or later. Sequence, where it matters, is a premise or a tie label. **Trust, reputation, scores.** A record box says what was verified; it does not say how much the evaluator trusts the party. Control is drawn as topology (separate bands); independence for a claim is a premise, neither a rating nor a consequence of the drawing. **Intent, state of mind, motive.** Nothing in the vocabulary names a person's intent. An intent-base claim is a claim about what records show of a declared intention, and is drawn like any other claim. **Causation between records.** There is no arrow from record to record. A tie says two records concern the same thing; it does not say one produced the other. **Completeness of the picture.** A diagram shows the boundaries the evaluator examined. It cannot show that no other boundary exists; the premises block says what was and was not evaluated, and the picture stops there. **Claims of one kind that are not comparable** (v0.4, D-10, decided by the founder on 3 November 2026: option B). Within a kind the ranked claims are stacked by rank (WF-5), and a ceiling excludes the ranked claims above it, so their order is part of the finding, not a display order. CBEE −02 §5 does not presume that all claims of one kind are comparable or that one strongest claim exists. A claim the author does not order is given no rank. It is drawn below the ranked claims of its kind, under the eyebrow `not ranked · no order of strength`; no ceiling sits above it (WF-19), and a ceiling between ranked claims does not reach it, so its limit, where its boundary cannot reach it, is stated on its own arrow. What the notation still cannot express is a partial order, such as one claim stronger than two claims that are not ordered between themselves: the author ranks a chain or leaves claims unranked, and an unranked claim has no stated order with any claim of its kind. Option C of D-10 (chains within a kind) would express it and was not adopted. One more gap follows from B: where no record of a boundary is offered for an unranked claim, the boundary's limit on it has no arrow to sit on and is stated in the report only. A limit arrow and a plain strike look alike but for the word `limit` on the label; the textual equivalent names it. And in a kind with ranked and unranked claims, a boundary that reaches no ranked claim but can reach an unranked one cannot be drawn: a ceiling above the lowest ranked claim leaves that claim reachable, a ceiling that reaches none excludes the unranked claim too, and a limit is not for ranked claims (WF-20). The report states such a limit. A claim for which a different type of evidence is relevant is not of the same kind (CBEE −02 §5) and is drawn in its own. The generator cannot check the order a ranking states: it is the author's statement, open to challenge like a premise. **Control, Trust and Authority Boundaries** (v0.4, D-2). Of the boundary construct types of Core §5.4 that are not production boundaries, only control is drawn, as the band (one band per controlling party, G-2). Trust and Authority Boundaries are not drawn: a diagram is about production, and a mark for trust would read as a rating (see "Trust, reputation, scores" above). A report that depends on them states them as premises. **Coinciding boundary types** (v0.4, D-11). A component that produces records may also be, in the same place, a Signature-Production, Endorsement-Issuance or Attestation-Production Transition, a Transformation Transition, or a Custody or Disclosure Interface (Core §5.4). The line draws record production only. A signature shows only as a `signed` tag on a record, which says that the evaluator verified it; the other types are stated as premises when a finding depends on them. No type is read off the line, and two types are not treated as one because they share a component (Core §5.3, §5.6). A boundary's grounding (asserted-only, attributed, attested; WEXP Core −02 §7) grades how the boundary's description is grounded; `attested` is not an Attestation-Production Transition. ## 8. Media profiles One source, one rendering engine, several outputs. The marks never change between media; only scale, colour scheme and the surrounding frame do. **Site (witnessability.io).** Inline SVG at 1× in a `
`, with the generator's CSS variables (`--wn-ink`, `--wn-secondary`, `--wn-accent`, `--wn-tint`, `--wn-paper`, `--wn-line`) bound to the site's tokens, so the picture follows the light and dark schemes without a second file. Every figure has a `
` that states the finding in one sentence, and the SVG carries a `` with the generated alt text (§9). Fonts come from the site's self-hosted IBM Plex; no external request is made by a diagram. **Slides.** 2.4× scale on the dark scheme, one diagram per slide, caption in Plex Sans at the foot. Builds reveal one band or one arrow at a time by toggling opacity on generated groups; no mark is redrawn for emphasis, because emphasis would be a new meaning. **Papers and specifications.** TikZ via `wn-notation.tex` (generated by the reference implementation, `python -m wn render --tikz`). Px convert to pt at 0.75; the hairline floor is 0.4 pt so boundaries survive print and PDF rasterisation. Greyscale print keeps every distinction, because no distinction is carried by hue alone; the accent dot becomes a dark dot, which still reads. **Internet-Drafts and RFCs (v0.3).** The policy for SVG in RFCs is RFC 9896 (January 2026): no script, no animation or interactivity, no external pointers, figures consistent with the text and never its only representation; the profile and the tooling are the RFC Production Center's, and as of 1 November 2026 that tooling (xml2rfc 3.35.0, svgcheck 0.12.0) still enforces the SVG 1.2 RFC schema of RFC 7996. The rfc profile of the generator (`--rfc-svg`) emits the same geometry in that schema: inline presentation attributes, black and white only, generic font families, arrowheads as filled paths, one text element per line, no classes, ids, markers or CSS; `` and `<desc>` kept. The monochrome mapping is that of greyscale print — accent to ink, paper to white, secondary and line colours to black — and the control band becomes a 0.5 px outline (§4). The text rendering of a draft carries an ASCII drawing (§4, “ASCII forms”; `--ascii`); `--rfcxml` wraps both in an RFCXML `<artset>` for a `<figure>`. The profile is re-checked when the RPC publishes new guidance; the generator's structural test is where it is relaxed. **Boundary cards.** Two fixed frames: 1200 × 630 (link preview) and 352 × 500 (portrait card). Both carry one minimal diagram (§6), the claim and verdict rows, a short premises line (≤ 46 characters each) and the brand mark top-left. Records are set at 11 px and claims in a 120 px column; a card never shows more than one band and three claims. **Print and PDF.** Same as papers; A4 and Letter margins of 20 mm; diagrams are vector, never rasterised; the CSS variable set is replaced by the light palette values. **Hand sketch.** The eight core marks were chosen so they can be drawn with a pen: a line, a dot, a box, text, an arrow, a struck arrow, a dotted arrow, a lintel. A whiteboard sketch that follows the grammar is a valid diagram of the notation; it just has no version stamp. ## 9. Accessibility **Non-text contrast (WCAG 2.2 SC 1.4.11, 3:1).** The meaning-bearing strokes are ink on paper (16.7:1 light, 16.1:1 dark) or ink on tint (14.7:1 light, 13.7:1 dark). The accent dot on tint measures 5.5:1 in the light scheme and 4.1:1 in the dark scheme; on paper 6.3:1 and 4.8:1. Secondary text (labels, tags) on tint measures 5.6:1 light and 7.1:1 dark, which also clears the 4.5:1 text threshold at the 11 px label size. The `line` colour (1.4:1) is used for one element only, the hairline above the premises block, which is a separator and carries no meaning. **Use of colour (SC 1.4.1).** No distinction is made by hue alone. The accent marks the observation point, which is also distinguished by shape (the only circle on the boundary line). Arrow states differ by stroke pattern and head, not colour. Bands differ by position and label, not by colour. The dark scheme is therefore a retint, not a re-encoding. **Textual equivalent.** Every diagram is a picture of a report, and the report is the equivalent. The generator writes a `<desc>` that lists, in reading order: the action; the bands and their boundaries with their grounding; each record with its tags and form, named by its label and, where two records share a label, by its boundary as well, so that every relation below can be traced to one record; each claim by kind, stronger first, with the unranked claims of a kind named as not ranked; each finding as “\<record> → \<claim>: \<state> (\<premises>)”, a limit with “· limit of its boundary” after its state, a linked support with its records joined by “+” and its threshold; then the ceilings with their labels and places, the ties, the coverage, the enforcement points, the downgrade, the reliance line, the evaluator and evaluated set, the items not evaluated, and the premises in full, with the WM 2.0 state vector (each entry naming its claim) and the version last (generator 0.4.0; earlier generators wrote only the claims by state). On the site the same text is available as a details disclosure below the figure. A screen-reader user gets the finding, not a description of lines. **Low vision and zoom.** At 400 % zoom the SVG scales as vector; labels stay in Plex Mono, which keeps `0`/`O` and `1`/`l` distinct. Minimum type size inside a diagram is 11 px at 1× (14.7 px CSS at 1.33× site scale); captions are 15 px Plex Sans. **Motion.** Slide builds use opacity only, no movement; `prefers-reduced-motion` turns builds off and shows the finished diagram. **Print and greyscale.** See §8; nothing is lost in monochrome, the control band's tint excepted, which becomes an outline (§4). ## 10. Self-assessment against the Physics of Notations Moody's nine principles (2009) are the standard yardstick for a visual notation. The assessment below is the author's; §11 says how it is to be checked by other people. **Semiotic clarity** — one symbol, one concept. The first draft failed this: dashed was used for a declared boundary, for an assertion and for “no record”. Resolved by the three-line-quality scale (solid = established, dashed = declared or asserted, dotted = absent or no finding); each form now has one meaning across all element types, and the scale itself is one visual variable with three ordered values. Two overloads are known since D-10 and N-18: vertical position within a kind means strength among ranked claims and nothing among the claims under `not ranked · no order of strength`, the eyebrow carrying the difference in text; and the strike carries two concepts on an unranked claim, a gap in the evidence set and the boundary's limit, told apart only by the word `limit` on the label. No other symbol redundancy, overload, excess or deficit is known. The Authority Boundary has no glyph, by decision D-2 (§7, §14). **Perceptual discriminability** — the eight core marks differ in at least two visual variables each (shape and texture, or shape and colour). The weakest pair is the struck arrow vs the refuted arrow (both negative; both have a diagonal element). They differ in head (filled vs none) and in the position of the mark (mid-shaft vs tip). The comprehension test (§11) measures this pair specifically. **Semantic transparency** — the arrow for inference, the strike for “does not follow”, the dotted line for “not evaluated” and the lintel for “ceiling” are mnemonic. The capability ring (“could observe, did not”) and the binding tie with square ends are opaque and need the legend; both are extended marks. **Complexity management** — the vocabulary is split into eight core marks and thirteen extended marks. A diagram shows one situation, one action, one evaluator. Bands are the only grouping device; there is no nesting. **Cognitive integration** — every diagram carries the same frame (claims right, premises below) and the same type scale across site, slides, papers and cards; an arrow label cites premise ids that the text uses. The site figure caption restates the finding in prose. **Visual expressiveness** — of Bertin's eight variables the notation uses shape, texture (line quality), position (horizontal and vertical) and one colour; it leaves size, orientation, brightness and the remaining hues unused on purpose, so that nothing can be read into them (§7). **Dual coding** — every mark is accompanied by text: state labels on arrows, kinds above claims, labels on boundaries and bands, the premises block. The picture is never the only carrier. **Graphic economy** — eight core marks are within the recommended span (Moody cites six as a ceiling for novices; the notation treats the state labels as the mitigation for the two extra). Twenty-one marks in total is justified by the number of distinct CBEE reporting concepts, each of which appears in the reports anyway. **Cognitive fit** — one notation for experts and the public is a known tension. The response is the core/extended split and the hand-sketch property (§8): a reader who knows eight marks can read most diagrams, and an author can draw them on a whiteboard. Overall, as the author's design self-assessment and not a finding: compliant in principle on nine of nine, with two items tested rather than assumed (struck vs refuted; ring and tie transparency) and one gap by decision (no Authority Boundary glyph, D-2). ## 11. Test protocol The notation is accepted as v1.0 only when the three tests below have been run and the results recorded in the decision record (§13). Until then it is v0.x. **Test A — comprehension.** Readers: six to eight, none of whom took part in the design; at least two with no background in evidence, logging or security. Material: six generated diagrams (the four examples of the site page plus two new ones), each shown with its legend and without its caption. Task per diagram: (1) list the claims that are supported; (2) list the claims that are unsupported, and separately those that are refuted; (3) say what is not evaluated and why; (4) say which boundary, if any, cannot warrant a claim of a given kind, and whether a claim below a ceiling is thereby supported; (5) say whether two named records are bound; (6) for a boundary drawn without a point, or with a ring, say what the diagram finds about capture there; (7) say what the bands show about the independence of records from different parties; (8) name each boundary's grounding (added on 3 November 2026 after review R-1). Score each answer against the source YAML. Record per-mark error rates; the struck/refuted pair, the ceiling, the ring and the tie are the marks of interest. Pass: median per-reader accuracy ≥ 85 % on tasks 1–3 and ≥ 70 % on tasks 4–8; no single core mark with an error rate above 20 %. A failing mark is redesigned and the test repeated for that mark only. **Test B — adversarial drawing.** Two authors who know the CBEE try, for one hour each, to draw a diagram that (a) makes an unsupported claim look supported to a casual reader, (b) implies likelihood, time order or cross-kind strength, or (c) passes `wn check` while misrepresenting the YAML. Every success is recorded as an issue against the grammar or the validator and resolved before v1.0. Pass: no open issues of type (c); issues of type (a) and (b) resolved or documented as limits in §7, except that an issue in which a well-formed picture conveys a finding opposite to its source's (a supported claim read as unsupported, or the reverse; a refuted claim read as unsupported, or the reverse) is resolved in the grammar, never documented. **Test C — round trip.** For each example: YAML → picture → a reader writes the finding as a CBEE-style report (evaluated set, supported, unsupported, refuted, not evaluated, downgrade) → compare with a reference report that a second person prepares from the YAML source alone, not from the generator's output, so that a fault of the generator shared by the picture and its `<desc>` is caught. Compared: every finding with its exact set of records, its state, whether it is a limit (N-18), its threshold and its premises; the boundary and the band of every record; every boundary's grounding; every ceiling with the claims it excludes; every tie with its status; the coverage; the downgrade; the claims of each kind that are not ranked (v0.4, D-10). Pass: the reports agree on every item. The `<desc>` is compared with the reference in the same way. This is the test that the picture says exactly what the source says and nothing more (rebuilt on 3 November 2026 after review R-1; before, only (record, claim, state) triples against the `<desc>`). **Screen reader.** The textual equivalent is read by at least one user of a screen reader, who answers tasks (1) to (5) of Test A from it alone (added after review R-1). **Regression.** The golden-file tests in the reference implementation run on every change; the suite includes the cases review R-1 named: two records with one label, a source without grounding, a boundary without a point, a ceiling and a supported arrow to a claim it excludes, and claims of one kind whose order would change a ceiling's reach; and, after D-10, unranked claims: no ceiling above one, a ceiling between ranked claims that does not reach one, the strike on its own arrow, and no downgrade where no supported claim is the unique strongest; and, after N-18, limits: refused on a supported arrow, a ranked claim, a linked support, without a premise or at a boundary whose grounding was not evaluated, and a supported arrow from the same boundary refused; a golden file changes only with a recorded reason. The render QA script (text overlap, overflow, margin; `tools/render_qa.py` since generator 0.4.0) runs on every published board and figure and must report zero issues. **Recording.** Each run produces a dated entry: participants (role, not name), materials by content hash, per-task scores, issues raised, decisions taken. The entry is appended to the decision record and referenced from the CHANGELOG. ## 12. Reference implementation `wn-notation` (generator 0.4.0 for this version) is the executable form of §§3–6 and §8. It exists so that no published reference figure is drawn by hand (a hand sketch that follows the grammar is still a diagram of the notation, §8, without a version stamp): the picture in a paper, on a slide and on the site is the same geometry from the same source. **Source format.** One YAML (or JSON) document per diagram, a direct transcription of the abstract syntax: `wn: "0.4"` (`"0.1"` and `"0.2"` are still accepted and read under their own rules, including the ceiling's label), `title`, optional `action` and `kinds`, `bands` (each with `boundaries` → `points` → `records`, plus `assertions`), `claims` (with `rank`, an integer or null since 0.4, and `type`), `arrows` (`from` — one record, or a list of records for a linked support —, `to`, `state`, `threshold`, `premises`, `note`, `limit` since 0.4), boundaries with `grounding` (required since 0.4), `ceilings` (with `premises` since 0.4), `ties`, `coverage`, `downgrade`, `reliance`, `evaluator`, `evaluated_set`, `premises`, `not_evaluated`. **Commands.** - `python3 -m wn check <sources>` — validates WF-1 … WF-20; errors stop, warnings print. - `python3 -m wn render <source> --svg <path> --tikz <path> [--png <path> --fonts-css <css>] [--no-css] [--rfc-svg <path>] [--ascii <path>] [--rfcxml <path>]` — renders one source to any of the outputs. `--no-css` omits the embedded style block when the site supplies it; `--rfc-svg`, `--ascii` and `--rfcxml` are the Internet-Draft outputs of §8 (v0.3). `--mermaid`, `--jsonld` and `--sysml` (generator 0.3.0) are projections into established notations under the bridge rules of `bridges/BRIDGES.md` (N-13); they are informative companions of this specification, not part of the notation, and conformance (below) does not cover them. - `python3 -m wn preamble <path>` — writes `wn-notation.tex`, the TikZ style set; one `\input` per paper. - `python3 -m unittest discover tests` — golden-file comparison (brand SVG, rfc SVG, ASCII, and the bridge outputs), rule tests, per-figure id tests, the textual-equivalent test of §9, and — when svgcheck and xml2rfc are installed — the tooling checks of §8. - `python3 tools/regen.py --golden --out [--png]` — regenerates the golden files and the rendered outputs; `python3 tools/render_qa.py out/*.svg` — the render QA of §11. **Pipeline.** `model.py` loads and validates; `layout.py` computes the scene (claim rows by kind and rank, record rows aligned to the first offered claim, elbow channels, extended ceilings with the strike at the crossing, labels right-aligned before the tip, bands, premises block); `describe.py` writes the textual equivalent of §9; `svg.py` and `tikz.py` render the same scene. Metrics live in one table (`layout.M`) and match §4. **Outputs.** SVG: `.wn-*` classes, `currentColor` strokes, colours through CSS variables with the light palette as default, `<title>` and `<desc>`; since generator 0.2.1 every figure carries its own id prefix `wn-<title-slug>-<hash>` on `<title>`, `<desc>` and the markers, so several inline figures on one page keep unique ids and their own accessible names, and `data-wn` carries the source's version. SVG, rfc profile and ASCII: §8 (v0.3). TikZ: one `tikzpicture` per figure using the styles in `wn-notation.tex`, px → pt at 0.75; verified to compile with pdflatex. PNG: rasterised by Playwright/Chromium with the site's self-hosted fonts, for QA and decks. **Examples shipped.** `ct-witnessability` (real data of 3 November 2026: the certificate witnessability.io serves, its two SCTs and inclusion proofs, Chrome's CT policy, the CA and one log in one band, the ceilings of both logs below the authorization claim, the operator's monitoring drawn as a boundary without a point; evidence in `research/notation/2026-11-03-ct-witnessability/`), `legend` (the supported, unsupported and not-evaluated states, a ceiling with a cited premise; the legend figure of the site page; the refuted state is drawn in `missing-record`), `signed-request` (invocation vs effect; ceiling below the effect stack; a bound tie), `preserved-archive` (fixity, accuracy, authority; a compared tie), `missing-record` (no-record box inside coverage, ring, refuted arrow), `cbee-payment` (three bands, the operator service's ceiling below the effect stack, a downgrade, an action line; since 1 November 2026 with the claim wording of CBEE −02 §10; the settlement ledger's ceiling removed after review R-1), `cbee-payment-unbound` (the §10 variant with the binding not established: one ceiling below the effect stack, no downgrade — the second figure of the CBEE −03 appendix candidate); `unranked-delivery` (one outbound log line and two hops: two claims of one kind that neither entail each other, unranked; the sending server cannot reach the second hop's acceptance, and that limit sits on the claim's own struck arrow, marked `limit`, with a premise about the boundary; D-10, N-18); tech-paper/fig-7-3a-six-domains and fig-7-3b-shared-control (the two architectures of Section 7.3 of the technical manuscript, six domains versus two, drawn with linked supports; the first figures of that paper). **Dependencies.** Python 3.10+, PyYAML; Playwright with Chromium only for PNG. No network access at render time. **Conformance.** An implementation conforms to this specification if, for every example, it renders the same (record, claim, state) triples, limits, ceilings, ties, claims not ranked and premises as the reference, and if `check` rejects every WF-1 … WF-20 violation in the test suite. Pixel identity is not required; grammar identity is. **Known limits (v0.3; v0.4 adds one).** The ASCII rendering does not yet separate several arrows into one claim (the SVG and TikZ layout does since generator 0.4.0). One claim column; records of one boundary cannot be reordered by the author; a diagram with more than about eight records or twelve claims becomes tall and should be split; no automatic line-breaking of claim text beyond 280 px (long claims wrap, which is allowed, but the author should shorten them); Cyrillic labels render in Plex Mono where the subset is loaded but have not been tested for width (§14). ## 13. Versioning, errata and governance **Numbering.** The notation is versioned separately from the Core, the CBEE and the WEXP drafts, with semantic versioning: a major version changes the meaning of an existing mark or removes one; a minor version adds a mark or a rule without changing existing readings; a patch fixes geometry, wording or the generator without touching meaning. The source format carries the version (`wn: "0.4"`; v0.3 added no source field; v0.4 adds premises on a ceiling, `rank: null`, `limit` on an arrow, and makes `grounding` required), so every diagram states which rules it was drawn under. A rendered diagram carries the version in its `<desc>` (SVG) or as a comment (TikZ); the site shows it in the figure's details disclosure. **Status line.** Every published version states its status in §1: draft (v0.x; a new draft may replace it at any time, and the text of a published draft changes only by a recorded erratum, §14 D-6), candidate (frozen for the tests in §11), stable (v1.0 and later; changes only by the process below). This document is a draft. **Dependence on the texts.** The notation is informative. Where a picture and the versioned text of the Core, CBEE or WEXP differ, the text prevails, and the difference is an erratum against the notation. A new revision of a referenced draft is reviewed for impact on §5; the result is recorded even when there is none. **Errata.** An erratum names the version, the section, the mark, the defect and the fix, and is dated. Errata are recorded in the CHANGELOG (`CHANGELOG.md` in the work repository, since 3 November 2026), listed on the site page of the version they apply to (E-9), and applied to the text of that version, which keeps its number. An erratum never changes a reading silently: if the fix changes what a published diagram means, the erratum says so and the diagram is republished. **Decision record.** Design decisions that a later reader might reopen are recorded as short dated entries (context, options considered, decision, consequences), in the pattern the Core uses for its own release qualifications. The first entries are: the three-line-quality scale replacing dashed-for-everything; accent reserved for the observation point; one claim column; claims never pointing at claims; the linked support with junction squares, added on 31 October 2026 for Section 7.3 of the technical manuscript (extended mark 13, WF-13); the decisions of 31 October 2026, recorded in the work repository under research/notation/2026-10-31: PROV as the proposition type Orig (Q-1), order among types as display only (Q-2), NonExec in Core with the closure premise (Q-3), “witness boundary” on public pictures (D-1), the site page as the canonical address with a repository copy (D-6), structured thresholds checked by the generator (D-7, option B); test results from §11. **Change process.** A change is proposed as an issue against the generator repository with a rendered before/after pair, is checked against §10 (which principle does it serve, which does it cost), and is accepted only with updated golden files and, for a change to §5, an updated semantic entry with its “does not mean” line. **Licence.** Decided by the founder on 4 November 2026 (E-13): the regime of the Witnessability Conceptual Core 1.0. The specification, its figures and legend, the canvas and the notation's other documents are under Creative Commons Attribution 4.0 International (CC BY 4.0). The reference implementation (wn-notation, with its tests, examples and outputs) is under the Apache License 2.0. The vocabulary and schema files of the bridges (`wn.ttl`, `wn-shapes.ttl`, `context.jsonld`, `WitnessabilityNotation.sysml`) are dedicated under CC0 1.0, as the Core designates open schemas. Each grant extends only to rights that subsist and are held or licensable by the grantor, Mikhail A. Sergeev; the texts and the code were drafted with AI assistance, and no claim is made that every fragment is copyrightable. Third-party material keeps its own licence. Attribution line: “Witnessability Notation v\<version>, witnessability.io”. The brand mark, the project's names and any conformance claim are not covered. ## 14. Open decisions These need a decision by the project, not by the author of this document. Each is stated with the options and the author's recommendation. **Decided on 31 October 2026** (decision record in the work repository, research/notation/2026-10-31): D-1 → option A, “witness boundary” on public pictures; D-6 → the site page /notation/\<version>/ as canonical, with a copy in the repository (revised on 3 November 2026: `/notation/` canonical, `/notation/<major>.<minor>/` for each published version; D-6 below); D-7 → option B, the threshold is structured and checked by the generator (v0.2, WF-14). **Decided on 1 November 2026** (DECISION-RECORD-2026-11-01): DR-7, the rfc profile targets the RPC's tooling, not the text of RFC 9896; D-8 (DR-9) → the control band in monochrome is a 0.5 px outline; D-9 (DR-8) → the text rendering of a draft carries an ASCII drawing, not a description. **Proposed in this draft (3 November 2026), for the founder's decision:** N-11 and N-12 (the ceiling's label and premises, §4, §5); D-10 → option A, stated in §7 (replaced by option B, decided on 3 November 2026); D-2 → option A, stated in §7; D-3 and D-4 → the recommendations below. **Decided by the founder on 3 November 2026, in this draft:** D-11 → the boundary line maps to the Record-Production Transition or Interface (§3, §5, §7); D-5 in part → the pilot readers of Test A and the two authors of Test B are named. **Decided by the founder on 3 November 2026, after review R-1:** D-10 → option B, unranked claims (§3, §5, §7, WF-19); N-15 → option C, grounding stated in 0.4 sources (WF-15); E-5 → the enforcement bar's wording of §5, applied to v0.3 as erratum E-5; then N-18 → option B, the limit marker (WF-20), and E-6, the strike on a lintel, applied to v0.3 as well; and this text accepted as v0.4, with the proposals it made (N-11, N-12, D-2 → A, D-3 and D-4 as recommended). **Decided by the founder on 4 November 2026:** the licence, the regime of the Core (§13, E-13). **Still open:** the rest of D-5 (the six to eight readers of Test A), the second form of D-7 (a threshold computed from the Model), N-16 and N-17 below, and N-9 and N-10, carried into the v1.0 candidate (E-8; below). **D-1 — Label family on public pictures.** The same mark is called a Witnessability Boundary in the Core (the genus; since D-11 the line maps to its Record-Production Transition or Interface), a producing boundary in the CBEE (the line with its points and its band) and a witness boundary in NAMING-01. Pictures on the site, in slides and on cards need one label family. Option A: “witness boundary” (NAMING-01; shortest; matches the brand). Option B: “producing boundary” (CBEE; matches the draft the pictures mostly illustrate). Option C: the Core's full term. Recommendation: A on public pictures, with the CBEE term in the first caption that introduces a picture in a CBEE context; papers use the term of the text they sit in. All labels stay in Plex Mono either way (§4). **D-2 — Glyphs for the remaining Core constructs.** Control, Trust and Authority Boundaries (Core §5.4) have no mark; control is shown as a band, trust and authority are not shown. Option A: leave them out and say so in §7 (they are not production boundaries and a diagram is about production). Option B: add a band variant per type (texture of the band edge). Recommendation: A; add only if a real report needs them. **Proposed in this draft:** A, stated in §7. Accepted with v0.4 on 3 November 2026. **D-3 — Cyrillic.** The Russian materials need Plex Mono Cyrillic. Options: load the Cyrillic subset on the site (about 20 kB per weight); or keep diagrams in English with Russian captions. Recommendation: English inside diagrams, Russian captions, until a Russian-first report exists; then load the subset and re-run the render QA for label widths. **Proposed in this draft:** the recommendation. Accepted with v0.4 on 3 November 2026. **D-4 — The brand mark on cards.** Cards carry the mark top-left and the diagram below. Option A: keep (the mark's detached point echoes the observation point and the two reinforce each other). Option B: drop the mark on cards and let the notation be the identity. Recommendation: A for link previews, B for in-article cards. **Proposed in this draft:** the recommendation. Accepted with v0.4 on 3 November 2026. **D-5 — Who runs Test A.** The comprehension test needs six to eight readers who did not design the notation. Options: project contacts; a paid panel; readers recruited through the site. The author cannot decide this; the result decides whether v1.0 happens. Test B needs two more people, authors who know the CBEE (§11). **Named by the founder on 3 November 2026:** two pilot readers of Test A, who try the materials before the test is run, and the two authors of Test B. As §11 records participants, this text names them by role; the names are in the work repository. Still open: the six to eight readers of Test A, at least two of them without a background in evidence, logging or security. The pilot readers are not counted among them. **D-6 — Public location of the specification.** Options: a page on witnessability.io under `/notation/0.1/`, mirroring `/core/1.0/`; or a document in the generator repository only. Recommendation: both, with the site page as the canonical one, because the site already carries the Core's versioned pages and the audit found that pattern working. **Revised on 3 November 2026** (E-7; the founder asked the Coordinator to decide whether the version belongs in the URL): `/notation/` is the canonical page; it always shows the current text and names its version. Each published version also keeps a fixed page, `/notation/<major>.<minor>/`, for citation; a recorded erratum may change it, and nothing else does. A version never published gets no page: v0.2 and v0.3 stay in the repository, and v0.1 is recorded in the CHANGELOG. The namespace `/ns/wn/` carries no version. Reasons: a diagram names the version it was drawn under, so a citation must reach that version's rules (the CBEE −03 appendix names “version 0.2”); most links want the current text, and a versioned URL as the only entry goes stale with every version (0.2 to 0.4 took three days); W3C pairs “This version” with “Latest published version” in the same way (PROV-O: `/TR/2013/REC-prov-o-20130430/` and `/TR/prov-o/`); a namespace that changed with each version would break every graph that uses it, which is why PROV keeps one namespace across all its documents (`http://www.w3.org/ns/prov#`); and a patch changes no reading (§13), while an erratum that changes one says so and republishes the diagrams it affects, so the path carries only major and minor. **D-8 — The control band in monochrome** (decided 1 November 2026, DR-9). The tint has no black-and-white value. Options: a 0.5 px solid outline; no rectangle (the label and the 16 px gap carry the grouping); a dashed outline (rejected: dashes already mean asserted-only and assertion); hatching (impossible in the SVG 1.2 RFC schema, which has no pattern element). Decision: the outline. **D-9 — The text rendering of an Internet-Draft** (decided 1 November 2026, DR-8). Options: accept xml2rfc's notice that the artwork is only available as SVG; a description as the ascii-art alternative; an ASCII drawing. Decision: the drawing, with the description as the generator's fallback when no drawing is passed. **D-7 — The threshold on a linked support.** Decided on 31 October 2026 in its first form (DR-6, option B): the threshold is structured, `{k, n}` or `{t}`, the label is derived from it, and the generator refuses a picture the structure contradicts — n that is not the number of joined records, or a supported linked support with budget t whose records sit in fewer than 2t + 1 separately controlled bands (WF-14). The value itself stays the evaluator's: the generator checks it against the picture and does not compute it. **Still open, the second form:** compute the value from the Model — the separation margin of the technical manuscript, or the (min, ∩) composition rule of the Witnessability Model 1.1 — so that the generator refuses a threshold the evidence does not support, not only one the picture contradicts. That needs one identity space for records across the Model, the CBEE report and the picture (§5b, rule R-2), which is the meta-model (roadmap M6). Recommendation: v1.0 without the second form. **D-10 — Claims of one kind that are not comparable** (raised on 3 November 2026 with erratum E-2). Ranks force a linear order within a kind (WF-5); CBEE −02 §5 does not presume one. Options: (A) keep ranks and say the order is the author's; (B) allow unranked claims and draw their limit on each arrow (the strike only), with no lintel; (C) group comparable claims into chains, one lintel per chain. Recommendation: A until a real report needs B or C. **Proposed in this draft:** A, stated in §7. **Changed after review R-1 (3 November 2026):** the reviewer showed that A as written lets a display order decide what a ceiling excludes, and that the CT example had such a pair (“the operator requested this certificate” over “WE1 issued this certificate”). The reviewer recommends B. A first proposal here, that a kind is one chain and ranking states entailment, was withdrawn the same day after an independent check: it redefined CBEE's kind (CBEE −02 §5: “a family of claims to which the same type of evidence is relevant”, which “does not presume that all claims of one kind are comparable”) and asserted an entailment that neither CBEE nor WEXP Core states (WEXP Core −02 §4.2: the base order “is not an entailment relation”). **Interim rule, until the decision:** the order within a kind is part of the finding, and no ceiling separates claims the author cannot order. The CT example's request claim is in a kind of its own on CBEE's definition: a different type of evidence (the CA's validation records) is relevant to it. **Decided by the founder on 3 November 2026: B,** as the reviewer recommended (DECISION-RECORD-2026-11-03, “The founder's decisions on D-10, N-15 and E-5”). In a source of version 0.4 a claim may be unranked (`rank: null`; WF-5 requires the rank to be stated in a kind with more than one claim). No ceiling sits directly above an unranked claim (WF-19), a ceiling between ranked claims does not reach it, and no downgrade goes to or from it (WF-11) (§5, §7). A ceiling that reaches none still excludes it: that needs no order, and excluding every claim of the kind but the unranked ones would contradict the ceiling's own label (confirmed by the founder on 3 November 2026). Implemented in generator 0.4.0: the unranked claims of a kind are drawn below its ranked claims under the eyebrow `not ranked · no order of strength`; the textual equivalent and the report of Test C name them; the example `unranked-delivery` shows them; no published picture changes, since every example states its ranks. C remains possible later, if a real report needs a partial order (§7). An independent check of the change, the same day, found three defects of text, one of the example and several risks; all are corrected, and two are raised below as candidates (E-6, N-18). **D-11 — Which boundary type the line draws** (raised on 3 November 2026). **Decided by the founder on 3 November 2026** (DECISION-RECORD-2026-11-03, “D-11”): the line maps to the Record-Production Transition or Interface of Core §5.4, a type of the Witnessability Boundary of §5.3, not to the genus. With its points and its band, the element is CBEE's producing boundary. Reasons. Core §5.1 keeps the constructs apart, “not to collapse them into one universal boundary”, and §5.3 makes a Witnessability Boundary a typed demarcation; mapped to the genus alone, the line would be that universal boundary. The genus also includes the Control, Trust and Authority Boundaries that §5 says the line does not mean. And the Core's example execution-evidence profile (§5.7) lists Observation Locus, Capture Capability Envelope, Effective Capture Coverage, Binding Relation and Record-Production Transition: the point, the ring, the bracket and the tie already take the first four. Consequences: §3, §5, §7 (“Coinciding boundary types”) and §15 change. The former gloss, “the surface at which an event of the action becomes capturable”, described the Observation Locus and is withdrawn. No picture and no finding changed with D-11. The sentence first added to §5, that a line with no point is an interface at which no record was produced, claimed more than a picture can show; review R-1 found it, and §5 now says that such a line makes no finding. D-1 is unaffected: its labels name the boundary element on pictures. **N-15 — Grounding stated, not defaulted** (raised on 3 November 2026). WEXP Core −02 §7: a descriptor asserted by a producer is at most asserted-only; a valid signature associated with an accepted identity can make it attributed; an applicable boundary-grounding profile can make it attested. The generator reads a boundary with neither `grounding` nor `declared` as attested, which draws the strongest class by default. Options: (A) keep the default and say so in §3; (B) default to asserted-only; (C) in sources of version 0.4, `grounding` is required and its absence is a WF-14 error; sources of 0.1 and 0.2 keep their present reading. Recommendation: C. No published picture changes, and a new picture cannot claim the strongest class by omission. **After review R-1:** the reviewer agrees on C and adds two points, both taken: the WEXP class not-evaluated is a value of its own, drawn dashed with the label suffix “· grounding not evaluated”, and a boundary so graded has no usable ceiling (WEXP Core −02 §7); and keeping the old reading for 0.1 and 0.2 sources does not make their pictures right, so the generator warns on them and the examples were audited and now state their grounding, graded on the boundary's description (DECISION-RECORD-2026-11-03, R-1). Implemented in generator 0.4.0 as WF-15. **Decided by the founder on 3 November 2026: C.** **E-5 — The enforcement bar's gloss** (raised on 3 November 2026; an erratum to v0.3 as well). §5 says that the control-topology test “turns on whether the producer could have routed around the point that produced the record”. CBEE −02 §8.1 separates the two: bypassing an enforcement point is circumvention, and bypassing a recording boundary is concealment. Proposed wording, revised after review R-1, which pointed out that circumvention in CBEE −02 §8.1 also covers directing the decision of the point (“complete the action without the enforcement point, or direct the decision of that point”), and again after the independent check of that revision, which pointed out that the party controlling the band controls the point by definition: CBEE −02 §8 asks for “an enforcement point that B does not control and cannot bypass”. The text now in §5. **Decided by the founder on 3 November 2026,** and applied to v0.3 as erratum E-5 before its site page is deployed (CHANGELOG). **E-6 — The strike on a lintel** (raised on 3 November 2026 by the independent check of D-10; a candidate erratum to v0.3). §4 of v0.3 puts the strike “where the arrow crosses a ceiling of its own boundary”. An unsupported arrow that crosses such a lintel on its way to a claim the ceiling does not exclude (a claim below it) is then struck on the lintel, which reads as “excluded”. Generator 0.4.0 strikes on a lintel only where that ceiling excludes the claim (§4, G-5). No figure of the site page or of the examples changes: none has such an arrow. **Decided by the founder on 3 November 2026:** the same correction is applied to v0.3 §4 and G-5 as erratum E-6 (CHANGELOG). **N-18 — A limit marker on an arrow** (raised on 3 November 2026 by the independent check of D-10). Under B, the limit a boundary places on an unranked claim is a struck arrow whose premises give the boundary grounds (§5, *Ceiling*); it looks like a strike for a gap in the evidence set (§7). The check proposes an arrow field `limit: true`, drawn as the strike with the label `unsupported · limit · P…`, its premise required as for a ceiling (WF-16) and checked against supported arrows from the same boundary as WF-17 checks a ceiling; the textual equivalent and Test C would carry it. Options: (A) leave the premises to tell the two apart, as now; (B) add the marker. Recommendation: B before v1.0, if a real report draws a boundary limit on an unranked claim. **Decided by the founder on 3 November 2026: B,** implemented in generator 0.4.0 as the arrow field `limit` and WF-20, with WF-17 extended; the label reads `unsupported · limit`; the textual equivalent, the report of Test C and the bridges carry it; the example `unranked-delivery` uses it, and the legend has a row for it. **R-1 — First external review** (3 November 2026; eighteen findings; dispositions in DECISION-RECORD-2026-11-03, “Review R-1”). Taken into this draft: the readings of the refuted arrow, the downgrade, the ceiling, the linked support, the control band and the enforcement bar (§5); a boundary without a point makes no finding (§5); D-10, N-15 and E-5 as above; WF-15 to WF-18 (§6); record identity in the textual equivalent (§9); the tests (§11); the contrast figures (§9); and the examples, whose changes are listed in §12. Changed otherwise: D-10, where a remedy of the draft's own was withdrawn after an independent check; an interim rule stood until the founder chose B on 3 November 2026. The corrections of the first pass were themselves checked independently the same day, and nine further defects were corrected (record, “Review R-1, second check”). Deferred: a draft mode and a publication mode of `wn check` (N-17), and the grounding suffix on every class (N-16). **N-16 — The grounding class on every boundary label** (raised on 3 November 2026 by review R-1). Attested is drawn as a plain solid line, so the difference between attested and attributed rests on a label suffix that a quick reader may miss. Option: write the class on every boundary label. Recommendation: decide with Test A, task (8). Open. **N-17 — A draft mode and a publication mode** (raised on 3 November 2026 by review R-1). The reviewer proposes that `wn check` in a publication mode require the evaluator, the evaluated set and the grounds of every negative finding. WF-15 to WF-18 already make the last two errors in sources of version 0.4. Recommendation: add the mode when a publication pipeline needs a gate the source version does not give. Open. **N-9 and N-10 — The premises of absence; not evaluated means not evaluated** (raised on 2 November 2026 as v0.4 candidates, not taken into v0.4; listed here by erratum E-8, 4 November 2026). N-9: a claim of type NonExec supported by exclusion cites premises for the closure of the channel set of its coverage and for the functioning of those channels over the interval (W-8 as amended on 2 November 2026); WF-16 requires only that at least one finding from a no-record box cite a premise. N-10: a claim that a `not_evaluated` entry names by its id is not also the target of an arrow whose state is supported, unsupported or refuted; `not_evaluated` entries are free text in 0.4 sources. **Decided by the founder on 4 November 2026:** both go into the v1.0 candidate, N-9 as WF-21 (a warning) and N-10 as WF-22 (an error). WF-21 needs a way for a premise to state which of the two it is; WF-22 needs the id form of `not_evaluated` entries. Open until the candidate draft states them. **N-11 and N-12 — The ceiling's label and premises** (raised on 3 November 2026 with erratum E-2). N-11: `ceiling of <boundary> · <kind>` instead of `ceiling · <boundary> · <kind>`, so the label cannot be read as naming the ceiling after the boundary. N-12: CBEE −02 §5 places a ceiling under stated premises, and v0.3 gave a ceiling no premises; a ceiling may now cite premise ids, shown at the end of its label and checked by WF-8. **Proposed in this draft;** implemented in generator 0.4.0, which keeps the v0.3 label for sources of version 0.1 and 0.2. Accepted with v0.4 on 3 November 2026. ## 15. Sources **Project texts this notation draws.** - Witnessability Conceptual Core 1.0 — witnessability.io/core/1.0/ (source release v1.0.0). Sections used: §2.1 Target Proposition; §5.1 and §5.3 Witnessability Boundary (the typed genus); §5.4 Record-Production Transition or Interface (the boundary line, D-11), Observation Locus, Capture Capability Envelope, Effective Capture Coverage, Binding Relation, Control, Trust and Authority Boundaries, and, for the limit of §7, Signature-Production, Endorsement-Issuance, Attestation-Production and Transformation Transitions and the Custody and Disclosure Interfaces (all among the boundary construct types of §5.4); §5.6 Extensibility Rule; §5.7 Boundary Profile (the execution-evidence example); §6.5 Boundary Ceiling Rule (related to the ceiling, §5). - Sergeev, M. A.; Ikher, V. — Witnessability Model 1.1. DOI 10.5281/zenodo.21970802. - Sergeev, M. A.; Ikher, V. — Witnessability Model 2.0, working draft of 13 October 2026 (unreleased; publication programme document, tab 15, rev 3). The proposition types of §3 and the margin rule behind WF-14 are read from it. - The technical manuscript, v0.6, §7.3 (two architectures; the linked support of §5). Unreleased. - Claim Boundaries for Execution Evidence (CBEE), draft-sergeev-claim-boundaries-02, IETF Datatracker. Sections used: bases; bounding principle and claim ceiling; non-inference rules 1–13; control-topology test; independence; reporting (evaluated / not evaluated; supported / unsupported / refuted; downgrade). - WEXP Appraisal Core, draft-sergeev-wexp-core-02, IETF Datatracker. Sections used: §7 grounding classes; §8.2 verdicts accept / downgrade / reject; §8.3 the support relation. - WEXP Coverage, draft-sergeev-wexp-coverage-00, IETF Datatracker. Basis for the coverage bracket. - Naming note NAMING-01, “witness boundary” (a project note, not published on witnessability.io). Vocabulary. - Brand guide and tokens (witnessability-site: brand/brand-guide.md, brand/tokens.json). Colours, type, the seed paragraph on diagram notation. **Method.** - Moody, D. L. — The “Physics” of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering. IEEE Transactions on Software Engineering 35(6), 2009, 756–779. The nine principles of §10. - Bertin, J. — Sémiologie graphique (1967; English edition Semiology of Graphics, 1983). Visual variables, §4 and §10. - W3C — Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, 2023. SC 1.4.1 Use of Color, SC 1.4.3 Contrast (Minimum), SC 1.4.11 Non-text Contrast; §9. - ISO 5807:1985 — Information processing: documentation symbols and conventions for data, program and system flowcharts. Structure of a notation standard (symbols, meaning, composition rules), followed in §§3–6. - OMG — Unified Modeling Language, Infrastructure (abstract syntax / concrete syntax / semantics separation). Structure of §§3–5. **Companion artefacts of this work.** - Design canvas “Witnessability Notation — visual vocabulary” (seven boards: Main, Marks, Relations, Grammar, Cards, Media, Tokens; redrawn for v0.4 on 4 November 2026). Superseded for the legend by the generator's legend sheet (`wn-notation/tools/legend.py`, 3 November 2026). - Reference implementation `wn-notation`, generator 0.4.0 for this version (model, layout, SVG, TikZ, ASCII, rfc profile, bridges, CLI, ten examples, golden tests, render QA, legend sheet, README). - Audit “Аудит witnessability.io — 31 октября 2026”, for the state of the site and the deployment that the media profiles in §8 assume. **Related notations (§5a).** - SCSC Assurance Case Working Group — Goal Structuring Notation Community Standard, Version 3, May 2021 (SCSC-141C). - OMG — Structured Assurance Case Metamodel (SACM). - W3C — PROV-DM: The PROV Data Model, W3C Recommendation, 2013. - Shostack, A. — Threat Modeling: Designing for Security, 2014 (data-flow diagrams and trust boundaries); OWASP Threat Dragon. - Schneier, B. — Attack Trees, Dr. Dobb's Journal, 1999; MITRE Center for Threat-Informed Defense — Attack Flow v4, 2026. - Toulmin, S. — The Uses of Argument, 1958; Wigmore, J. H. — The Science of Judicial Proof, 3rd ed., 1937 (the chart method); Beardsley, M. C. — Practical Logic, 1950, and Thomas, S. N. — Practical Reasoning in Natural Language, 1973 (linked and convergent support). - ISO 5807:1985 (flowchart symbols); Rummler, G. and Brache, A. — Improving Performance, 1990 (swim lanes). - Ancestors in other fields (§5a, 2 November 2026): Maas, P. — Textkritik, Teubner, 1927, §4 (the stemma; a copy of an extant witness is struck out); IEC 61025:2006 — Fault tree analysis (shared basic events); IEC 62676-4:2014 and edition 2, 2025 — Video surveillance systems for use in security applications, Part 4: Application guidelines (detection to identification levels); Pollock, J. L. — Defeasible Reasoning, Cognitive Science 11(4), 1987 (undercutting defeaters); Verheij, B. — ArguMed, JURIX 1998; Sterne, J. A. C. et al. — ROBINS-I, BMJ 355:i4919, 2016 (“No information”). - RFC 9896, SVG in RFCs (Editorial Stream, January 2026; obsoletes RFC 7996; updated by RFC 9920); RFC 7996, SVG Drawings for RFCs: SVG 1.2 RFC (December 2016) — the schema xml2rfc 3.35.0 and svgcheck 0.12.0 enforce as of 1 November 2026; §8 (v0.3). Contrast ratios in §9 were computed from the token values with the WCAG 2.x relative-luminance formula on 31 October 2026; the ink-on-paper and ink-on-tint figures were recomputed on 3 November 2026 after review R-1, which found the earlier “16:1 and above” too high for ink on tint.