jcp §4.10: the flow gate had no spec section, and six code references cited it #190

Merged

dcharlot merged 1 commit from feat/revocation-freshness into main 2026-10-09 02:49:32 -04:00

Conversation 0 Commits 1 Files changed 2 +170

dcharlot commented 2026-10-08 11:14:14 -04:00

Owner

Copy link

jcp-runtime cites "SPEC §4.10" in six places — the taint floor, the flow
gate, check 6c — and jcp/SPEC.md has no §4.10. The section was never written.

So the mechanism that decides whether a value's provenance may exercise a grant
is implemented, gate-enforcing and tested, with no normative text behind it.
That is the mirror of what this sweep has mostly been closing: a check with no
claim, rather than a claim with no check.

I found it by nearly colliding with it — #189 had taken §4.10 for durable spend,
and is renumbered to §4.11, because the code had already spoken for the number.

§4.10 documents what is there

Every normative sentence is backed by a test that already exists in
jcp-runtime:

• the label's three independent components, ⊥ and ⊤;
• the ceiling as a FlowBelow caveat, several composing to the strictest via
  meet on the label and min on the tainted sub-budget, so attenuation never
  widens one;
• the taint floor as the enforcement point's own refusal — the flow analogue of a
  trust root (§7), default-open;
• the three-case table whose middle row is the whole point:

facts	meaning	result
absent	provenance not computed	fails closed against a ceilinged grant
⊥	computed, clean	passes any ceiling
labelled	computed, tainted	tested against ceiling and floor

"Not computed" MUST NOT be read as "clean".

• the placement, which is normative: after capability and signature, because
  a ceiling inside an unauthenticated grant would seal a verdict over
  attacker-chosen policy; before caveats and budget, so a tainted call costs
  zero joules.

A sentence I had to pull back

I first wrote that the implementation propagates labels. It does not —
flow_gate takes the facts from its caller, so propagation belongs to the
host, the only party that sees the data move. The spec now says so, and says
what JCP guarantees instead: a host that propagates gets a decision bound to
what it reported, and one that does not gets a refusal rather than a pass.

Conformance class C25 is declared and defined in §9's list — citing a class
without defining it would be the same dangling reference this PR exists to fix.

§4.3 gains a Propagation paragraph

§4.3 binds an enforcement point once it holds a revocation, and says nothing
about how it comes to hold one. With a budget sharded across N points (§4.5), a
revocation that reached three of five leaves the grant live at two — and an allow
from a point that had not yet heard is indistinguishable, after the fact, from
an allow by a point that heard and ignored it. The first is propagation
delay. The second violates this spec.

An implementation MUST now define how revocations reach its points, and SHOULD
let each state how current its knowledge is.
Runtime::revocation_known_through records it, defaulting to None, which an
auditor MUST read as unverifiable rather than current — "did not say" is not
"was current".

Stated in the method's own docs rather than left implied: the marker is state
on the enforcement point and the jcp/2 receipt does not carry it, so an auditor
needs it out of band. Binding it into the signed core is the stronger fix and
reaches every Decision construction site across six standards' reference
implementations — 75 of them, in workspaces that do not build together — so it is
separate work, not a line in this one.

Verification

jcp-rs workspace 404 passed. The two clippy warnings in jcp-runtime are
pre-existing (2 on the baseline, checked against a stash).

Falsifying the marker caught a vacuous assertion of my own. I had written
that declaring a marker changes no decision, and checked it by comparing two
runtimes that both held no revocation — which passes however the marker
behaves. The test now applies a real revocation first, so clearing the
revocation set from the setter is caught.

Two earlier mutation attempts also "passed" because they patched lines that do
not exist: Runtime derives Default, so the marker's None comes by
derivation and there is no constructor literal to break.

reverted	caught by
the default marker claims currency (Some(0))	an_unstated_revocation_marker_is_not_a_current_one
declaring a marker clears the revocation set	same test, after it was strengthened

Merge order with the sibling PR

#190 adds §4.10 (the flow gate) and this one adds §4.11. They conflict with
each other, though each merges cleanly against main: both insert a new §4.x at
the same anchor, after §4.9 and before §5. Nothing else overlaps —
jcp-orchestrate and jcp-runtime are disjoint, and neither references the
other's symbols.

Merge #190 first. Then rebase this one; the resolution is to keep both
sections in numeric order, which is also the order they must read in: §4.10
Flow, §4.11 Durable spend. I checked the landing by merging the whole set onto
main in a scratch branch — the sequence comes out §4.9, §4.10, §4.11, §5, and
afterwards §4.10 has 13 code references against 1 spec section and §4.11 has 0
against 1.

(A git merge-tree between the two branches reported no conflict and I believed
it; a real merge disagrees. The textual check was wrong, not the branches.)

🤖 Generated with Claude Code

`jcp-runtime` cites **"SPEC §4.10"** in six places — the taint floor, the flow gate, check 6c — and `jcp/SPEC.md` has no §4.10. The section was never written. So the mechanism that decides whether a value's provenance may exercise a grant is implemented, gate-enforcing and tested, with **no normative text behind it**. That is the mirror of what this sweep has mostly been closing: a check with no claim, rather than a claim with no check. I found it by nearly colliding with it — #189 had taken §4.10 for durable spend, and is renumbered to §4.11, because the code had already spoken for the number. ## §4.10 documents what is there Every normative sentence is backed by a test that already exists in `jcp-runtime`: - the label's three independent components, `⊥` and `⊤`; - the ceiling as a `FlowBelow` caveat, several composing to the **strictest** via `meet` on the label and `min` on the tainted sub-budget, so attenuation never widens one; - the taint floor as the enforcement point's own refusal — the flow analogue of a trust root (§7), default-open; - the three-case table whose middle row is the whole point: | facts | meaning | result | |---|---|---| | absent | provenance **not computed** | **fails closed** against a ceilinged grant | | `⊥` | computed, clean | passes any ceiling | | labelled | computed, tainted | tested against ceiling and floor | "Not computed" MUST NOT be read as "clean". - **the placement, which is normative**: after capability and signature, because a ceiling inside an unauthenticated grant would seal a verdict over attacker-chosen policy; before caveats and budget, so **a tainted call costs zero joules**. ### A sentence I had to pull back I first wrote that the implementation propagates labels. It does not — `flow_gate` takes the facts from its caller, so propagation belongs to the **host**, the only party that sees the data move. The spec now says so, and says what JCP guarantees instead: a host that propagates gets a decision bound to what it reported, and one that does not gets a refusal rather than a pass. Conformance class **C25** is declared *and defined* in §9's list — citing a class without defining it would be the same dangling reference this PR exists to fix. ## §4.3 gains a Propagation paragraph §4.3 binds an enforcement point *once it holds* a revocation, and says nothing about how it comes to hold one. With a budget sharded across N points (§4.5), a revocation that reached three of five leaves the grant live at two — and an allow from a point that **had not yet heard** is indistinguishable, after the fact, from an allow by a point that heard and **ignored** it. The first is propagation delay. The second violates this spec. An implementation MUST now define how revocations reach its points, and SHOULD let each state how current its knowledge is. `Runtime::revocation_known_through` records it, defaulting to `None`, which an auditor MUST read as **unverifiable** rather than current — "did not say" is not "was current". **Stated in the method's own docs rather than left implied:** the marker is state on the enforcement point and the `jcp/2` receipt does not carry it, so an auditor needs it out of band. Binding it into the signed core is the stronger fix and reaches every `Decision` construction site across six standards' reference implementations — 75 of them, in workspaces that do not build together — so it is separate work, not a line in this one. ## Verification `jcp-rs` workspace **404 passed**. The two clippy warnings in `jcp-runtime` are pre-existing (2 on the baseline, checked against a stash). Falsifying the marker **caught a vacuous assertion of my own**. I had written that declaring a marker changes no decision, and checked it by comparing two runtimes that both held *no* revocation — which passes however the marker behaves. The test now applies a real revocation first, so clearing the revocation set from the setter is caught. Two earlier mutation attempts also "passed" because they patched lines that do not exist: `Runtime` derives `Default`, so the marker's `None` comes by derivation and there is no constructor literal to break. | reverted | caught by | |---|---| | the default marker claims currency (`Some(0)`) | `an_unstated_revocation_marker_is_not_a_current_one` | | declaring a marker clears the revocation set | same test, after it was strengthened | ## Merge order with the sibling PR **#190 adds §4.10 (the flow gate) and this one adds §4.11. They conflict with each other**, though each merges cleanly against main: both insert a new §4.x at the same anchor, after §4.9 and before §5. Nothing else overlaps — `jcp-orchestrate` and `jcp-runtime` are disjoint, and neither references the other's symbols. **Merge #190 first.** Then rebase this one; the resolution is to keep both sections in numeric order, which is also the order they must read in: §4.10 Flow, §4.11 Durable spend. I checked the landing by merging the whole set onto main in a scratch branch — the sequence comes out §4.9, §4.10, §4.11, §5, and afterwards §4.10 has 13 code references against 1 spec section and §4.11 has 0 against 1. (A `git merge-tree` between the two branches reported no conflict and I believed it; a real merge disagrees. The textual check was wrong, not the branches.) 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-10-08 11:14:14 -04:00

jcp §4.10: the flow gate had no spec section, and six code references cited it ... 0d107105c6

`jcp-runtime` cites "SPEC §4.10" in six places — the taint floor, the flow gate,
check 6c — and jcp/SPEC.md had no §4.10. The section was never written. So the
mechanism that decides whether a value's provenance may exercise a grant is
implemented, gate-enforcing and tested, with no normative text behind it: the
mirror of the defects this sweep has mostly been closing, a check with no claim
rather than a claim with no check.

I found it by nearly colliding with it — #189 had taken §4.10 for durable spend
and is renumbered to §4.11, because the code had already spoken for the number.

§4.10 documents what is there, and every normative sentence is backed by an
existing test:

- the label's three independent components, `⊥` and `⊤`;
- the ceiling as a `FlowBelow` caveat, several composing to the strictest via
  `meet` on the label and `min` on the tainted sub-budget, so attenuation never
  widens one;
- the taint floor as the enforcement point's own refusal, the flow analogue of a
  trust root, default-open;
- the three-case table whose middle row is the point: provenance **absent** is
  not provenance **clean**, and a ceilinged grant fails closed on an unlabelled
  argument;
- the placement, which is normative: after capability and signature, because a
  ceiling inside an unauthenticated grant would seal a verdict over
  attacker-chosen policy; before caveats and budget, so a tainted call costs
  zero joules.

One sentence I had to pull back: I first wrote that the implementation
propagates labels. It does not — `flow_gate` takes the facts from its caller, so
propagation belongs to the host, which is the only party that sees the data move.
The spec now says so, and says what JCP does guarantee instead: a host that
propagates gets a decision bound to what it reported, and one that does not gets
a refusal rather than a pass.

Conformance class **C25** is declared and defined in §9's list. It cites only
behaviour `jcp-runtime` already tests — zero-debit flow denial, failing closed
without facts, the taint floor overriding a permissive ceiling, the tainted
sub-budget, and byte-identical encoding without a flow caveat.

**§4.3 gains a Propagation paragraph.** §4.3 binds an enforcement point *once it
holds* a revocation and says nothing about how it comes to hold one. With a
budget sharded across N points (§4.5), a revocation that reached three of five
leaves the grant live at two — and an allow from a point that had not yet heard
is indistinguishable, after the fact, from an allow by a point that heard and
ignored it. The first is propagation delay; the second violates this spec. An
implementation MUST now define how revocations reach its points and SHOULD let
each state how current its knowledge is; `Runtime::revocation_known_through`
records it, defaulting to `None`, which an auditor MUST read as *unverifiable*
rather than current.

Stated in the method's own docs rather than left implied: the marker is state on
the enforcement point and the `jcp/2` receipt does not carry it, so an auditor
needs it reported out of band. Binding it into the signed core is the stronger
fix and reaches every `Decision` construction site across six standards'
reference implementations — 75 of them, in workspaces that do not build
together — so it is a separate piece of work rather than a line in this one.

Falsifying the marker caught a vacuous assertion of my own. I had written that
declaring a marker changes no decision, and checked it by comparing two runtimes
that both held *no* revocation — which passes however the marker behaves. The
test now applies a real revocation first, so clearing the revocation set from
the setter is caught. Two earlier mutation attempts also "passed" because they
patched lines that do not exist: `Runtime` derives `Default`, so the marker's
`None` comes by derivation and there is no constructor literal to break.

jcp-rs workspace: 404 passed. The two clippy warnings in jcp-runtime are
pre-existing (2 on the baseline, checked against the stash).

Co-Authored-By: Claude Opus 5 <[email protected]>

dcharlot referenced this pull request from a commit 2026-10-08 11:40:25 -04:00

ci: a rebase ran every path-filtered workflow, because `paths:` matches the push delta

dcharlot referenced this pull request 2026-10-08 11:41:09 -04:00

ci: a rebase ran every path-filtered workflow, because paths: matches the push delta #191

dcharlot referenced this pull request 2026-10-08 20:45:48 -04:00

jcp §4.11: an orchestrator's spend died with its process, so a restart was a fresh budget #189

dcharlot referenced this pull request from a commit 2026-10-09 02:47:46 -04:00

jouledesk: an interrupted tag is not a failed one, and is not sealed as waste

dcharlot merged commit 4ec143f131 into main 2026-10-09 02:49:32 -04:00

dcharlot referenced this pull request from a commit 2026-10-09 02:49:34 -04:00

Merge pull request 'jcp §4.10: the flow gate had no spec section, and six code references cited it' (#190) from feat/revocation-freshness into main

dcharlot referenced this pull request from a commit 2026-10-09 02:51:14 -04:00

jouledesk: an interrupted tag is not a failed one, and is not sealed as waste

dcharlot referenced this pull request 2026-10-13 03:07:25 -04:00

spec citations: five named sections their SPECs do not have, and a check so they cannot return #238

dcharlot referenced this pull request from a commit 2026-10-13 03:07:27 -04:00

aac, sandbox: five citations named sections their SPECs do not have

dcharlot referenced this pull request from a commit 2026-10-13 03:07:27 -04:00

ci: a citation to a section that does not exist is now a failure

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!190

No description provided.