colregs 0.2.3 → 0.2.4

package/PROVENANCE.md

@@ -19,6 +19,10 @@ publications. Nothing here is authoritative: consult the published rules.
   reconstruct it from memory, `rules.json` records it under `gaps` and the
   paragraph is omitted. 24(g) covers inconspicuous, partly submerged tows and
   is outside the applicability table in this release.
+- **Withheld text is not a gap.** A `gaps` entry is a paragraph we could not
+  obtain. A paragraph with `text_status: withheld` is one we hold but may not
+  publish, under a licence bar recorded in `withheld_reason` — see ADR 0010.
+  None exist yet; `intl` is entirely verbatim.
 - **Known quirks kept verbatim:** the source's own text of Rule 1(c) repeats
   "special rules ... special rules made" and Rule 13(b) reads "coming up with
   a another vessel" (sic), and Rule 10(c) reads "A vessel, shall so far as

package/README.md

@@ -1,17 +1,32 @@
 # colregs
 
-The COLREGS 72 navigation *light* rules as language-neutral JSON, plus the
-USCG's own diagrams and enough geometry to draw the lights yourself. Built as
-the base other countries' national amalgamations hang off of, not scoped to
-one country's rulebook.
+Two vessels are closing.  *What must they do?  Who gives way?  What must they display?*
 
-Data only. No runtime, no dependencies, no inference.
+The COLREGS, the International Regulations for Preventing Collisions at Sea, answer all three.  This project
+transforms the colregs so that a machine can evaluate and reason about them *deterministically*:
+the whole of the rules as structured data, so the same situation always yields the same result,
+and every result can be traced back to the rule that produced it.  Going further, the engine
+and the rules are then *checked with formal methods*, which means mathematically proving the rule set
+is consistent and complete rather than just testing it a bunch and hoping it all works out.
+
+This package is the data: the rules as language-neutral JSON, the USCG's own diagrams, and
+enough geometry to draw the lights yourself.  Jurisdictions are deltas on the international
+base, so national amalgamations hang off it rather than forking it.
+
+Related packages:
+* [colregs](https://github.com/mark-brannan/colregs) - the data and JSON Schema
+* [colregs-engine](https://github.com/mark-brannan/colregs-engine) - the engine that evaluates rules
+* [colregs-mcp](https://github.com/mark-brannan/colregs-mcp) - an MCP server so AI can use the engine
+* [nav-wright](https://github.com/mark-brannan/nav-wright) - draws vessels and displays (stub)
+* [searoom](https://github.com/mark-brannan/searoom) - a study tool demo
+
+See a [live demo](https://mark-brannan.github.io/searoom/) of searoom and the colregs data/engine.
 
 > **Status: pre-release.** Not complete, and not fit for navigation. Navigate
 > by the published rules.
 
 ```text
-data/rules.json          verbatim rule text, keyed by paragraph path and jurisdiction
+data/rules.json          rule text, keyed by paragraph path and jurisdiction
 data/lights.json         the six Rule 21 lights: colour, arc, Rule 22 range
 data/facts.json          the fact record, and how to decode SignalK navigation.state
 data/applicability.json  predicate -> lights, each entry also carrying modality, citation, jurisdiction
@@ -22,107 +37,82 @@ images/                  38 USCG diagrams + 5 arc GIFs
 fixtures/                fact records and the entries that apply to them
 ```
 
-## Coverage
+## What this package does not do
 
-Part C lights (Rules 20-31), `intl` jurisdiction, night only. Day shapes,
-Part D signals, and every other jurisdiction (US Inland, Canada, CEVNI) are
-on the roadmap in [`docs/requirements.md`](docs/requirements.md) but not
-present here.
+It has no runtime and no dependencies. It does not infer anything: it is a
+pure function of the fact record, and deciding *that* a vessel is fishing, or
+aground, or making way is the caller's job. Nothing here reads a sensor.
 
-One exception, not a claim to model the Inland Rules: `us/inland` carries
-two entries, `30a-buoy` and `30b-buoy`, for a vessel made fast to a mooring
-buoy — 33 CFR 90.5 deems her at anchor and the Convention does not, so the
-case cannot be stated under `intl` at all
+It does not select a single display. Where the rules permit a choice, every
+lawful option comes back and none is picked. Selection belongs to the consumer.
+
+## Coverage
+
+Every rule with a machine-checkable consequence: Part B conduct, Part C
+lights and shapes, Part D sound and light signals, and Annex I geometry.
+`intl` is the base; `us/inland`, `ca/inland` and `eu/cevni` are deltas on it.
+[`docs/requirements.md`](docs/requirements.md) is the numbered contract for
+all of it. One case the Convention cannot state, a vessel made fast to a
+mooring buoy, lives only under `us/inland`
 ([ADR 0008](docs/adr/0008-mooring-buoy-modifier.md)).
 
-## The four layers
+## The layers
 
-**Rule text.** Keyed by *paragraph path*, like `27(a)(i)` or `25(d)(ii)`,
-because the paragraph is the unit you actually cite. The text is verbatim
-International text; Inland-only inserts were stripped rather than paraphrased.
+**Rule text.** Verbatim, keyed by *paragraph path*, like `27(a)(i)`, because
+the paragraph is the unit you actually cite. Where a licence bars republishing
+a jurisdiction's words, the paragraph is still modelled and its text withheld
+rather than paraphrased — evaluation never reads the text.
 
-**Light definitions.** This layer is Rule 21. Each light carries its colour,
-its arc as a bearing range, and its minimum visible range by length band from
-Rule 22. Bearings run in degrees clockwise from right ahead, and an arc whose
-`from_deg` exceeds its `to_deg` wraps through the bow. So the masthead light
-is 247.5° to 112.5°, which is 225° of arc.
+**Light definitions.** Rule 21's lights with colour, arc as a bearing range,
+and Rule 22 range by length band. Bearings run clockwise from right ahead; an
+arc whose `from_deg` exceeds its `to_deg` wraps through the bow.
 
 **Facts.** Three orthogonal axes (`fact:propulsion`, `fact:activity`,
-`fact:position`), a `fact:making_way` modifier that refines
-`position:underway`, and scalars such as `fact:length_m` and
-`fact:tow_length_m`. There is deliberately no vessel-class field. Under COLREGS
-what a vessel *is* follows from what it is *doing*, so classification falls
-out of the axes on its own.
-
-SignalK's `navigation.state` flattens all of that into one enum. `facts.json`
-therefore carries a decode table, the enum values it can't decode, and the
-five places where the flattening loses information. Fishing at anchor and
-making-way are the two of those that matter in practice.
-
-**Applicability entries.** Each entry is a predicate over facts, a set of
-lights or references to other entries, a modality, a citation, and a
-jurisdiction. Every entry has an id (`25b`, `27a-mw`) that both consumers can
-point at.
-
-**Identifiers.** Two classes, with opposite requirements. Citation-derived ids
-— paragraph paths and the entry ids built from them — carry no prefix, because
-the path *is* the citation. Vocabulary ids do: `light:masthead`,
-`fact:activity`, `activity:nuc`, `rel:in_lieu_of`. See
-[`docs/identifiers.md`](docs/identifiers.md); coming from a 0.1.x release, see
-[Migrating from 0.1.x](#migrating-from-01x).
+`fact:position`), a `fact:making_way` modifier, and scalars such as
+`fact:length_m`. There is deliberately no vessel-class field: under COLREGS
+what a vessel *is* follows from what it is *doing*. A decode table maps
+SignalK's `navigation.state` onto the axes and names what the flattening
+loses.
+
+**Applicability entries.** Each is a predicate over facts, a set of lights or
+references to other entries, a modality, a citation, and a jurisdiction. Every
+entry has an id (`25b`, `27a-mw`) a consumer can point at.
+
+**Identifiers.** Citation-derived ids (paragraph paths, entry ids) carry no
+prefix, because the path *is* the citation. Vocabulary ids do:
+`light:masthead`, `fact:activity`, `activity:nuc`, `rel:in_lieu_of`. Every
+identifier is immutable once published; retirements go through
+[`data/deprecated-identifiers.json`](data/deprecated-identifiers.json). See
+[`docs/identifiers.md`](docs/identifiers.md).
 
 ## Design
 
-This repo is requirements-first. Coding sessions work against numbered
-requirements and cite them; decisions that shaped the design are recorded as
-ADRs rather than argued again.
-
-- [`docs/requirements.md`](docs/requirements.md): the source of truth
-- [`docs/adr/`](docs/adr/): decisions, with the reasoning that produced them
+Requirements-first: sessions work against the numbered requirements in
+[`docs/requirements.md`](docs/requirements.md) and decisions live in
+[`docs/adr/`](docs/adr/) rather than being argued again. Four ideas carry
+most of it.
 
-Three ideas carry most of the design:
+**The paragraph is the unit.** Rule text, citations and composition all key
+on the paragraph path. Citation unit and composition unit turn out to be the
+same thing.
 
-**The paragraph is the unit.** Rule text, citations and composition all key on
-the paragraph path (`27(a)(i)`, not "Rule 27"). Citation unit and composition
-unit turn out to be the same thing.
+**Jurisdiction is a dimension, not a fork.** Every record carries a
+`jurisdiction`: `intl`, or `<country-or-body>/<waters>` as a delta on it.
+Entries a jurisdiction doesn't override are inherited, not restated.
 
-**Jurisdiction is a dimension, not a fork.** Every rule-text record and every
-applicability entry carries a `jurisdiction`: `intl` (the reserved base value)
-or `<country-or-body>/<waters>` (`us/inland`, `eu/cevni`). A jurisdiction is a
-delta on `intl`; entries it doesn't override are inherited, not restated
-(REQ-SCOPE-2/3). Geography that merely gates a rule inside one jurisdiction
-(Great Lakes, Western Rivers) is an ordinary fact a predicate reads, not a
-jurisdiction of its own (REQ-SCOPE-5).
+**Predicates, not enumerations.** Gates are `fact:length_m < 7`, never a
+pre-built list of configurations. Enumerated tables are where prior art
+silently loses rules; a predicate cannot omit a case it was never asked about.
 
-**Predicates, not enumerations.** Gates are `fact:length_m < 7`, never a pre-built
-list of configurations. Enumerated tables are where prior art silently loses
-rules; a predicate cannot omit a case it was never asked about.
-
-**Alternatives are first-class.** COLREGS routinely permits a choice: a
-tricolor *in lieu of* separate sidelights, a torch *in lieu of* either. The data
-carries every lawful option with its modality and gate, and picks none of them.
-Selection belongs to the consumer.
+**Alternatives are first-class.** A tricolor *in lieu of* separate sidelights,
+a torch *in lieu of* either. The data carries every lawful option with its
+modality and gate, and picks none of them.
 
 ## Predicate semantics
 
 An entry applies when **every** constraint in its `when` is satisfied. An
-absent fact never satisfies a constraint. Numeric constraints are
-`{gte, gt, lte, lt}`; a list means membership; anything else is equality.
-`fact:activity: "activity:ram"` also matches `activity:ram_underwater`, which
-is a refinement of it.
-
-A `when` is a conjunction, and two constructs open it up. `{"not": C}` is a
-constraint satisfied when the fact does *not* satisfy `C`; `any_of` is
-disjunction, holding sub-predicates as a key of a `when` and constraints as the
-value of a fact. **`not` over an absent fact is unsatisfied**, like every other
-constraint over an absent fact — so `{"not": C}` and `C` are both false on a
-record that never mentions the fact, and the two are not complements there. That
-is deliberate: predicates stay conservative, and a duty is never laid on a vessel
-because a consumer left a field out. It also means `not` is a constraint on one
-fact and never a key of a `when` — a predicate-level negation would be satisfied
-by silence, which is the one thing the absent-fact rule is there to forbid. Where
-a paragraph really does mean "any vessel other than …", the negation goes on the
-fact the paragraph names, and the fact has to be present for the entry to apply.
+absent fact never satisfies a constraint, including `not`: a duty is never
+laid on a vessel because a consumer left a field out.
 
 | form | where | means |
 |---|---|---|
@@ -133,94 +123,34 @@ fact the paragraph names, and the fact has to be present for the entry to apply.
 | `{"any_of": [C, …]}` | a fact's constraint | the fact satisfies at least one `C` |
 | `"any_of": [W, …]` | a key of a `when` | at least one sub-predicate `W` holds |
 
-The `ram`/`ram_underwater` refinement belongs to the *value*, not to one
-constraint form: it applies to equality, to list membership and to each
-`any_of` disjunct alike, and `{"not": C}` negates the refined reading rather
-than sneaking underneath it. It used to fire on a scalar constraint only, so a
-list quietly missed it; that is fixed, and a list and `{"any_of": […]}` are now
-interchangeable wherever both are legal.
-
-Some facts are **derived** rather than supplied. `facts.json`'s `derived`
-section holds them, each with a decode table that is its definition — an ordered
-list of predicate/value rows, first match wins — read the same way as the
-SignalK `navigation.state` table. `fact:rule18_class` is the one that exists: a
-vessel's rank under Rule 18, decoded from her propulsion, her activity and the
-27(c) and WIG booleans, because Rule 18 ranks vessels by the Rule 3 terms of art
-and `fact:activity` answers a different question — what she *shows*. A consumer
-never supplies a derived fact.
-
-Entries **compose**: several apply to one fact record, and Rule 28 or Rule 26
-add to Rule 23 rather than replacing it. Relations between them:
+Entries **compose**: several apply to one fact record, and Rule 26 adds to
+Rule 23 rather than replacing it. A condition on whether a paragraph applies
+at all goes in the predicate; a condition on which of two applicable
+paragraphs prevails is a relation.
 
 | relation | meaning |
 |---|---|
 | `rel:includes` | import the referenced entry's **lights only**, never its predicate |
 | `rel:conditional_includes` | import lights when the stated `when` holds; `one_of` is a set of legal alternatives |
 | `rel:in_lieu_of` | this entry's lights replace the referenced entries' lights |
-| `rel:excludes` | must not be shown together: a pick-one between alternatives (25(c) and the tricolor), never one obligation vetoing another |
+| `rel:excludes` | must not be shown together: a pick-one between alternatives, never one obligation vetoing another |
 | `rel:exempts` | the referenced requirement does not apply (30(e)) |
-| `rel:overrides` | the superiority relation: this paragraph's requirement prevails over the referenced one's when both apply (Rule 18's "except where Rules 9, 10 and 13 otherwise require"); for lights, Rule 26(a)'s "only the lights prescribed in this Rule" displacing Rule 30's anchor lights |
-
-A condition on whether a paragraph applies to the vessel at all goes in the
-predicate; a condition on which of two applicable paragraphs prevails is a
-relation. Delete the other paragraph: if this one is still true of the vessel,
-it is a relation. Rule 28 at anchor is a predicate; Rule 18 displacing Rule 15's
-role is `rel:overrides` (REQ-MODEL-13, ADR 0005 §4).
-
-Where the rules permit a choice, the data keeps every lawful option instead of
-picking one. A 12 m sloop under sail has three legal displays: 25(a), the
-25(b) tricolor, or 25(a) plus the 25(c) red-over-green. Which one a given boat
-shows depends on what's installed, and that decision belongs to the consumer.
+| `rel:overrides` | this paragraph's requirement prevails over the referenced one's when both apply (Rule 18; Rule 26(a) over Rule 30's anchor lights) |
 
 Modality is `shall`, `may`, `shall-if-practicable`, `shall-not`,
 `shall-not-impede`, or `conditional` with a `modality_by` table when it turns
-on a fact (23(a)(ii) is `shall` at 50 m and above, `may` below).
-
-Most entries read one vessel and produce lights. A few read **two** — a
-situation, not a fact record — and produce an `effect` instead. Rules 4, 11
-and 19(a) say which section of Part B governs; Rules 18, 9, 10, 12 and 15 say
-which vessel gives way — Rule 18 reading `fact:rule18_class` rather than
-re-listing the activity axis, Rules 12 and 15 reading the propulsion their own
-words name and leaving the rank to Rule 18's `rel:overrides`; and Rules 7(d),
-13, 14 and 15 say what kind of encounter it is —
-`head-on`, `crossing` or `overtaking` — or that risk of collision exists.
-Those carry `category` and `subjects: 2`, and address each vessel
-through a subject segment: `own:fact:activity`, `other:fact:propulsion`,
-`pair:geo:in_sight`. A key with no subject means `own:`, so nothing above
-changes. `docs/identifiers.md` has the namespace and the effect vocabulary;
-`fixtures/situation-fixtures.json` is their contract.
-
-The three encounter types **partition** relative bearing. 13(b)'s overtaking
-sector is written once, as one constraint; Rule 15's crossing is `not` over
-that same constraint and `not` over Rule 14's head-on cone, so no crossing
-sector is enumerated anywhere and none can drift out of step. The suite sweeps
-both vessels' bearings in half-degree steps and asserts that exactly one
-encounter applies at every point, that 13(b)'s 22.5°-abaft-the-beam edge is
-exclusive on both sides, and that Rule 13(d)'s latch holds the classification
-at `overtaking` however far the bearing afterwards draws out. The numbers the
-Rules do not state — what counts as an appreciable bearing change, how wide
-"nearly reciprocal" is — are declared once in `facts.json` under
-`situation.constants`, marked pencil, and read from there by every entry.
-
-A situation can state geometry no two vessels can occupy, so the suite checks
-every fixture that states its kinematics against them (REQ-VERIFY-8): the two
-relative bearings must be two readings of one line of sight, positions must
-reproduce range and bearing, and CPA, TCPA and bearing rate must be the ones
-the headings and speeds give. The equations and tolerances are declared once in
-`facts.json` under `situation.geometry.consistency`. The sweeps construct
-situations that pass the same check, and the property that no two vessels are
-both give-way is asserted over a sweep of steady-bearing geometries — where it
-is a theorem — with the both-starboard geometry that breaks it pinned as one
-the check rejects.
-
-## What this package does not do
-
-It does not infer anything. It is a pure function of the fact record. Deciding
-*that* a vessel is making way, or fishing, or aground is somebody else's job.
-Nothing here reads a sensor.
-
-It does not select a single display. Where the rules offer alternatives, all of
-them come back.
+on a fact.
+
+Most entries read one vessel and produce lights. The Part B entries read
+**two**, a situation rather than a fact record, and produce an `effect`:
+which section governs, which vessel gives way, whether the encounter is
+`head-on`, `crossing` or `overtaking`. They address each vessel through a
+subject segment (`own:fact:activity`, `other:fact:propulsion`,
+`pair:geo:in_sight`); a key with no subject means `own:`. The encounter
+sectors partition relative bearing, so no crossing sector is enumerated and
+none can drift. [`docs/identifiers.md`](docs/identifiers.md) has the
+vocabulary, [`docs/part-b-invariants.md`](docs/part-b-invariants.md) the
+invariants, and `fixtures/situation-fixtures.json` is the contract.
 
 ## Verifying
 
@@ -230,124 +160,17 @@ npm test
 
 Every fixture reproduces exactly; every citation, cross-reference, light and
 geometry reference resolves; every image is on disk with its SHA-256 recorded;
-every decoded `navigation.state` value and every fact a predicate reads is
-declared.
-
-A **drift test** (REQ-VERIFY-2) cross-checks two directions: forward, fact
-record to lights, and reverse, lights already shown to which other entries
-could explain them. It fails on any collision the data doesn't already
-declare through `rel:includes`/`rel:in_lieu_of`/`rel:excludes`/
-`rel:exempts`/`rel:conditional_includes`.
-
-Every numeric gate that affects *which entries apply* has fixtures immediately
-either side of its threshold (REQ-VERIFY-5), and every entry is exercised by
-at least one fixture and absent from at least one other (REQ-VERIFY-3). Three
-gates that affect only *modality*, not which entries apply, are flagged as an
-open question rather than fixtured against a schema that can't express the
-distinction; see [Q-5](docs/requirements.md#9-open-questions).
-
-`fixtures/applicability-fixtures.json` is the cross-implementation contract: an
-implementation in any language should reproduce those entry sets exactly.
-
-## Migrating from 0.1.x
-
-0.2.0 is the first release whose vocabulary identifiers carry a type prefix.
-`colregs@0.1.1`, the last version on npm, has the bare names; every 0.1.x
-consumer holds strings that no longer resolve. Renaming an identifier is a
-breaking change under REQ-PKG-4, and the rename is the one exception
-REQ-MODEL-10 records: 0.1.1 predates the identifier audit, sits outside the
-immutability baseline, and nothing after it may be renamed this way again.
-
-**What did not change.** Paragraph paths (`27(a)(i)`) and entry ids (`25b`,
-`27a-mw`) are citation-derived and stay bare. No entry id present in 0.1.1
-is removed — the 40 entries of 0.1.1 are all in 0.2.0, with 30 more.
-
-**What did.** Every light id, fact key, fact value and relation verb, in
-every place it appears: `lights.json` keys, `facts.json` keys and `values`,
-the `light` field of an entry's `lights[]`, the keys and values of an entry's
-`when` and `modality_by[].when`, the relation keys on an entry
-(`includes` → `rel:includes`, and so on), the `relations` map in
-`applicability.json`, the `light` field in `geometry.json`, the
-`signalk_navigation_state.decode` table, `actuable_subset.fields`, and the
-`facts` record of every fixture. The rule is in
-[`docs/identifiers.md`](docs/identifiers.md): a light is `light:<id>`, a
-fact key is `fact:<key>`, a value of an enumerated fact is `<fact>:<value>`,
-a relation is `rel:<name>`. The full table, generated from the two data
-sets rather than from memory:
-
-| kind | 0.1.1 | 0.2.0 |
-|---|---|---|
-| light id | `masthead` | `light:masthead` |
-| light id | `sidelights` | `light:sidelights` |
-| light id | `sidelight_starboard` | `light:sidelight_starboard` |
-| light id | `sidelight_port` | `light:sidelight_port` |
-| light id | `sternlight` | `light:sternlight` |
-| light id | `towing` | `light:towing` |
-| light id | `all_round` | `light:all_round` |
-| light id | `flashing` | `light:flashing` |
-| light id | `torch` | `light:torch` |
-| light id | `deck_lights` | `light:deck_lights` |
-| fact key | `propulsion` | `fact:propulsion` |
-| value of propulsion | `power` | `propulsion:power` |
-| value of propulsion | `sail` | `propulsion:sail` |
-| value of propulsion | `oars` | `propulsion:oars` |
-| fact key | `activity` | `fact:activity` |
-| value of activity | `none` | `activity:none` |
-| value of activity | `fishing` | `activity:fishing` |
-| value of activity | `trawling` | `activity:trawling` |
-| value of activity | `towing` | `activity:towing` |
-| value of activity | `pushing` | `activity:pushing` |
-| value of activity | `being_towed` | `activity:being_towed` |
-| value of activity | `nuc` | `activity:nuc` |
-| value of activity | `ram` | `activity:ram` |
-| value of activity | `ram_underwater` | `activity:ram_underwater` |
-| value of activity | `cbd` | `activity:cbd` |
-| value of activity | `mine` | `activity:mine` |
-| value of activity | `pilot` | `activity:pilot` |
-| value of activity | `diving` | `activity:diving` |
-| fact key | `position` | `fact:position` |
-| value of position | `underway` | `position:underway` |
-| value of position | `anchored` | `position:anchored` |
-| value of position | `aground` | `position:aground` |
-| value of position | `moored` | `position:moored` |
-| fact key | `making_way` | `fact:making_way` |
-| fact key | `length_m` | `fact:length_m` |
-| fact key | `tow_length_m` | `fact:tow_length_m` |
-| fact key | `max_speed_kn` | `fact:max_speed_kn` |
-| fact key | `gear_extent_m` | `fact:gear_extent_m` |
-| fact key | `beam_m` | `fact:beam_m` |
-| fact key | `composite_unit` | `fact:composite_unit` |
-| fact key | `non_displacement` | `fact:non_displacement` |
-| fact key | `wig` | `fact:wig` |
-| fact key | `wig_near_surface` | `fact:wig_near_surface` |
-| fact key | `near_channel` | `fact:near_channel` |
-| fact key | `inconspicuous_partly_submerged_tow` | `fact:inconspicuous_partly_submerged_tow` |
-| fact key | `towed_alongside` | `fact:towed_alongside` |
-| fact key | `obstruction_exists` | `fact:obstruction_exists` |
-| fact key | `obstruction_side` | `fact:obstruction_side` |
-| value of obstruction_side | `port` | `obstruction_side:port` |
-| value of obstruction_side | `starboard` | `obstruction_side:starboard` |
-| relation | `includes` | `rel:includes` |
-| relation | `conditional_includes` | `rel:conditional_includes` |
-| relation | `in_lieu_of` | `rel:in_lieu_of` |
-| relation | `excludes` | `rel:excludes` |
-| relation | `exempts` | `rel:exempts` |
-
-The mapping is mechanical and total: strip nothing, prepend the namespace.
-The one string that needed the prefix to disambiguate is `towing`, which in
-0.1.1 was both a light id and an `activity` value; it is now `light:towing`
-or `activity:towing` depending on which it was.
-
-A consumer that builds a fact record from SignalK `navigation.state` gets
-the new keys and values from the decode table for free. One that stored a
-0.1.1 fact record, light id or relation name must rewrite it by the table
-above; `fixtures/applicability-fixtures.json` is the check that the rewrite
-came out right.
-
-From 0.2.0 on, every identifier in the package is immutable once published
-(REQ-MODEL-10). [`data/deprecated-identifiers.json`](data/deprecated-identifiers.json)
-is the REQ-MODEL-11 registry a retired identifier goes into, and `npm test`
-refuses a removal that is not recorded there. [`data/version.json`](data/version.json) mirrors `package.json`; release-please keeps it in sync (see [ADR 0009](docs/adr/0009-data-version-stamp.md)).
+every fact a predicate reads is declared. A drift test cross-checks fact
+record to lights and lights back to entries, and fails on any collision the
+data doesn't declare through a relation. Every numeric gate has fixtures
+either side of its threshold, and every entry is exercised by at least one
+fixture and absent from another. The encounter sweeps assert that exactly one
+encounter applies at every bearing, and that no steady-bearing geometry makes
+both vessels give-way.
+
+`fixtures/applicability-fixtures.json` and `fixtures/situation-fixtures.json`
+are the cross-implementation contract: an implementation in any language
+should reproduce those exactly.
 
 ## Provenance and licence
 
@@ -356,5 +179,5 @@ publications, public domain; see [PROVENANCE.md](PROVENANCE.md). The
 compilation is Apache-2.0.
 
 Not authoritative, not endorsed by the Coast Guard. Navigate by the published
-rules. When the `ca/inland` delta lands, it will carry the same condition
-its licence does: it must not be represented as an official version.
+rules. The `ca/inland` delta carries the same condition its licence does: it
+must not be represented as an official version.

package/data/applicability.json

@@ -196,6 +196,7 @@
     }
    ],
    "images": [
+    "NRHB_23_a.png",
     "NRHB_23_aii.png"
    ]
   },
@@ -393,7 +394,7 @@
    ],
    "modality": "shall",
    "images": [
-    "NRHB_24_a.png"
+    "NRHB_24_av.png"
    ]
   },
   {
@@ -952,7 +953,8 @@
    ],
    "modality": "shall",
    "images": [
-    "NRHB_27_d.png"
+    "NRHB_27_d.png",
+    "NRHB_27_diii.png"
    ],
    "notes": "27(d)(iii): when at anchor these lights are shown instead of Rule 30's."
   },
@@ -987,9 +989,6 @@
     "27d"
    ],
    "modality": "shall",
-   "images": [
-    "NRHB_27_ei.png"
-   ],
    "notes": "Only when the vessel's size makes the full 27(d) display impracticable."
   },
   {
@@ -1134,7 +1133,7 @@
    ],
    "modality": "shall",
    "images": [
-    "NRHB_30_a.png"
+    "NRHB_30_d.png"
    ]
   },
   {
@@ -1158,7 +1157,10 @@
    "rel:in_lieu_of": [
     "30a"
    ],
-   "modality": "may"
+   "modality": "may",
+   "images": [
+    "NRHB_30_a.png"
+   ]
   },
   {
    "id": "30c",
@@ -1232,7 +1234,7 @@
    ],
    "modality": "shall-if-practicable",
    "images": [
-    "NRHB_30_d.png"
+    "NRHB_30_dii.png"
    ],
    "notes": "The two red lights are 'shall, if practicable'. 30(f) exempts vessels under 12 m from them; it does not exempt the 30(a)/(b) anchor lights, see 30d-anchor."
   },
@@ -1654,7 +1656,8 @@
       },
       "pair:geo:tcpa_s": {
        "gt": 0
-      }
+      },
+      "other:hist:was_overtaking": false
      },
      {
       "own:hist:was_overtaking": true
@@ -1683,7 +1686,7 @@
     "12a2",
     "12a3"
    ],
-   "note": "Categorised `precedence`, not `classification` as ADR 0005 sec. 1 and the proposal's first-cut table have it. 13(a) is the one paragraph of Rule 13 that assigns a role, and a `classification` entry has no field to put a role in; 13(b)'s sector test is the classification and is what sets the latch. Q-14 settles membership paragraph by paragraph and this is one of them. The predicate now carries both halves of 'any vessel overtaking any other': the 13(b) sector, which 13b-overtaking classifies, and the 13(d) latch, which 13d classifies. They are a disjunction, which is what the entry could not write before the predicate language grew `any_of` (Q-33). Now also overrides the three Rule 12 entries: 'notwithstanding anything contained in' the Rules of Part B Sections I and II includes Rule 12, and two sailing vessels in an overtaking would otherwise hold 13(a)'s and 12(a)'s roles at once (Q-40).",
+   "note": "Categorised `precedence`, not `classification` as ADR 0005 sec. 1 and the proposal's first-cut table have it. 13(a) is the one paragraph of Rule 13 that assigns a role, and a `classification` entry has no field to put a role in; 13(b)'s sector test is the classification and is what sets the latch. Q-14 settles membership paragraph by paragraph and this is one of them. The predicate now carries both halves of 'any vessel overtaking any other': the 13(b) sector, which 13b-overtaking classifies, and the 13(d) latch, which 13d classifies. They are a disjunction, which is what the entry could not write before the predicate language grew `any_of` (Q-33). Now also overrides the three Rule 12 entries: 'notwithstanding anything contained in' the Rules of Part B Sections I and II includes Rule 12, and two sailing vessels in an overtaking would otherwise hold 13(a)'s and 12(a)'s roles at once (Q-40). The sector branch now also reads `other:hist:was_overtaking: false`, so it cannot newly name a second give-way vessel while the other side already holds 13(d)'s latch -- once overtaking, always overtaking, on whichever vessel history says holds the role (Q-47).",
    "gap": "Only own's side. 13(a) lays the duty on the overtaking vessel, so this entry is directional by design and the overtaken vessel's stand-on role comes from the same entry read on the swapped situation. What it still cannot say is 13(c) -- a vessel in any doubt as to whether she is overtaking shall assume that she is -- because doubt is a state of the observer and no fact carries it; and it inherits 13b-overtaking's speed-comparison gap. Q-41, Q-46."
   },
   {