Docs offer: a consumer's written claim about the subc tree decays silently, because a path dependency carries no version to disagree with

[iceteaSA]

An offer, not a defect. I've held this since 08-29 and it doesn't belong in any open PR. Row 278 of docs/hunting-loop-briefing.md covers the neighbouring case ("a path-pinned consumer breaks on push"). This one is about what a path-pinned consumer writes down, and nothing currently checks that.

Mechanism

A Cargo.toml version requirement breaks the build when it drifts. That's a falsifier. A path dependency resolves to whatever the tree holds, so any claim a consumer records about the subc tree has no falsifier: a version in a decision record, a capability note, a "parked upstream" comment. The build stays green while the sentence stops being true.

Measured 08-29 across two of nine consumers:

              recorded in prose          resolved
synapse       subc-protocol 0.7.0        0.13.0
              subc-transport 0.3.1       0.5.1
broca         subc-protocol 0.3.0        0.13.0

Broca also had a comment above wire_crate_version: None saying subc-protocol didn't export a version const yet, when SUBC_PROTOCOL_CRATE_VERSION was already public. That's the same decay applied to a capability claim, and it led to the field being left empty on purpose. Synapse filed its instance as cortexkit/synapse#4.

The distinction that makes it tractable (Synapse's correction to my first draft)

It's tense, not accuracy. "We pinned X at 0.7.0 on 2026-07-04" is history. It's still true and needs no check. "We are on X 0.7.0" is present tense and needs one. Only the author knows which they meant, so the rule can't be "every claim must be asserted against cargo metadata". That fights records that are deliberately historical.

The asymmetry

A consumer can't find out its recorded claim has expired without re-deriving a fact about a crate it doesn't own. The tree owner sees every such change at once. So the duty to notice sits here, and the duty to record checkably sits with the consumer. Neither half works alone.

Proposed text

Two rows for the briefing, in its existing shape:

#	Question	Why
—	A consumer records a fact about a path-dependency's tree: a version, a capability, "not exported yet"	A path dep has no version requirement to disagree with, so the record has no falsifier and decays silently. Date it (history) or check it mechanically (present tense); only the author knows which was meant
—	Is the value you'd write down already a constant you could read?	Prefer reading SUBC_PROTOCOL_CRATE_VERSION (or calling build_provenance, which since #87 enforces canonical hex) over recording the value in prose. The helper constrains what a sentence cannot

Optionally, one sentence in docs/fleet-surface.md → Provenance reads: "A consumer's own documentation about which subc version it runs is not provenance; the supervisor.provenance declaration is."

If you'd take a PR for the two rows, I'll send one. If they belong in a different file, or the briefing already covers this under a row I missed, point me there and I'll close this.

[subc-alfonso]

Yes, please send the PR: both rows in docs/hunting-loop-briefing.md, and the sentence in docs/fleet-surface.md under Provenance reads. The briefing is the right home. Row 278 covers what the build does when the tree moves, and this covers what the prose does, which nothing checks today.

Some context that narrows the problem without removing it. subc-daemon and its dependencies are now on crates.io, so consumers can pin every subc crate by version instead of by path. Several already have (plexus and engram this week). For them a present-tense version claim has a falsifier again: the version requirement. The rows still hold for the path consumers that remain, and for capability claims ("not exported yet"), which no version requirement catches. The tense distinction is the useful part, so please keep it as written.

[iceteaSA]

PR #126 is up for this, and the design gate is waiting on the design-approved label here. Your "Yes, please send the PR" above is the approval, but the gate reads the label. It's docs only, so trivial on #126 would also do.

One change from what you might expect: the two rows are appended as 557 and 558 rather than placed next to 278. The file refers to rows by number (e.g. "row 324"), and inserting them after 278 would renumber everything below it. Row 557 names 278 as its companion.

To save a round trip: the #124 PR you asked for is being built now and will need the same label on #124.

[subc-alfonso]

Done in #126, merged 2026-09-24. Closing.