Transaction-Science/open-standards
Watch
1
0
Fork
You've already forked open-standards
 0
Code Issues Pull requests Projects Releases 15 Packages Wiki Activity Actions

jcp-flow: Compute propagated provenance from tool bytes #39

Closed
dcharlot wants to merge 1 commit from jcp-flow-witness into jcp-flow-lattice
pull from: jcp-flow-witness
merge into: Transaction-Science:jcp-flow-lattice
Conversation 0 Commits 1 Files changed 6 +761
dcharlot commented 2026-07-22 03:01:38 -04:00
Owner
Copy link

Increment 2 of the FL-2 flow-lattice design (FLOW_LATTICE_PLAN.md). Stacks on #37 (the lattice) — review/merge that first; the base is jcp-flow-lattice, so this diff shows only the new crate.

What. The lattice says what a Label is; this crate computes one from real bytes. As a run reads tool outputs and derives values, FlowStore tracks where each value's bytes came from and folds a derived value's label from the ancestors it was actually computed from — so authorization can be conditioned on where an argument came from, not merely its literal content.

Two things make it a reference monitor, not a heuristic:

  • The carry detector is an exact blake3 window index, deliberately not a rolling hash — each W-byte window hashed independently, so two values share a fingerprint exactly when they share a verbatim run, identically on every platform. (The design's own winning draft had a buggy buzhash; the synthesis killed it, and this is the fix.)
  • Every verdict emits a self-contained, content-addressed Witness — the ancestor cut, the taint edges, the folded label — so a third party re-folds it offline (verify_witness) to re-derive the verdict rather than trusting it. A receipt commits only its id().

label_payload folds four edge kinds: verbatim carry (Witnessed, proven by grams), a registered sensitive term appearing verbatim (Witnessed, for secrets below the window floor), a caller declaration (Declared — or ⊤, fail-closed, if that parent was evicted), and in HighWater mode the coarse session floor (Ambient). All BTree, so a witness content-addresses deterministically.

Ten tests carry laws L17–L20 and the residuals as executable claims: verbatim carry ⇒ witnessed edge; a sub-window unregistered token ⇒ nothing (the residual, pinned so it is never mistaken for a guarantee); a registered term of any length ⇒ caught; verify_witness catches a label tampered to look clean; a declared-but-lost parent fails closed to ⊤; and the attack this exists to stop — a summary carrying an attacker email verbatim does not sit below a principal-only ceiling, while HighWater still taints a laundered payload the scan alone cannot see.

Full JCP workspace: 214 tests pass. New crate only; nothing existing touched beyond the workspace member list.

Deferred to the receipt integration: the eight-check receipt-stream replay() lands when jcp/3 receipts exist to walk (increments 4–5). Next: the runtime gate (jcp-runtime check 6c).

Release Notes:

  • Added jcp-flow: propagated-provenance scan, session store, and offline witness verification
Increment 2 of the FL-2 flow-lattice design (FLOW_LATTICE_PLAN.md). **Stacks on #37** (the lattice) — review/merge that first; the base is `jcp-flow-lattice`, so this diff shows only the new crate. **What.** The lattice says what a Label *is*; this crate computes one from real bytes. As a run reads tool outputs and derives values, `FlowStore` tracks where each value's bytes came from and folds a derived value's label from the ancestors it was actually computed from — so authorization can be conditioned on *where an argument came from*, not merely its literal content. **Two things make it a reference monitor, not a heuristic:** - The carry detector is an **exact** `blake3` window index, deliberately not a rolling hash — each W-byte window hashed independently, so two values share a fingerprint exactly when they share a verbatim run, identically on every platform. (The design's own winning draft had a buggy buzhash; the synthesis killed it, and this is the fix.) - Every verdict emits a self-contained, content-addressed **Witness** — the ancestor cut, the taint edges, the folded label — so a third party re-folds it offline (`verify_witness`) to re-derive the verdict rather than trusting it. A receipt commits only its `id()`. `label_payload` folds four edge kinds: verbatim carry (`Witnessed`, proven by grams), a registered sensitive term appearing verbatim (`Witnessed`, for secrets below the window floor), a caller declaration (`Declared` — or ⊤, fail-closed, if that parent was evicted), and in `HighWater` mode the coarse session floor (`Ambient`). All `BTree`, so a witness content-addresses deterministically. **Ten tests carry laws L17–L20 and the residuals as executable claims:** verbatim carry ⇒ witnessed edge; a sub-window unregistered token ⇒ nothing (the residual, pinned so it is never mistaken for a guarantee); a registered term of any length ⇒ caught; `verify_witness` catches a label tampered to look clean; a declared-but-lost parent fails closed to ⊤; and the attack this exists to stop — a summary carrying an attacker email verbatim does not sit below a principal-only ceiling, while `HighWater` still taints a laundered payload the scan alone cannot see. Full JCP workspace: 214 tests pass. New crate only; nothing existing touched beyond the workspace member list. **Deferred to the receipt integration:** the eight-check receipt-stream `replay()` lands when `jcp/3` receipts exist to walk (increments 4–5). Next: the runtime gate (`jcp-runtime` check 6c). Release Notes: - Added jcp-flow: propagated-provenance scan, session store, and offline witness verification 
The flow lattice says what a label is; this crate computes one from real bytes.
As a run reads tool outputs and derives new values, FlowStore tracks where each
value's bytes came from and folds a derived value's label from the ancestors it
was actually computed from — so authorization can be conditioned on where an
argument came from, not merely on its literal content, the gap the one-bit Trust
tag cannot express.

Two properties make this a reference monitor rather than a heuristic. The carry
detector is an exact blake3 window index, deliberately not a rolling hash: each
W-byte window is hashed independently, so two values share a fingerprint exactly
when they share a verbatim run, with no carry state to get wrong and identical
fingerprints on every platform. And every verdict emits a self-contained,
content-addressed Witness — the ancestor cut, the taint edges, and the folded
label — so a third party re-folds it offline to re-derive the verdict rather than
trusting it; a receipt commits only its id.

label_payload folds over four sources, each an edge kind the witness records:
verbatim carry the scan found (Witnessed, proven by grams), a registered
sensitive term appearing verbatim (Witnessed, for secrets below the window
floor), a caller declaration (Declared — or top, fail-closed, if that parent was
evicted), and in HighWater mode the coarse session floor (Ambient). Every
collection is BTree, so a witness content-addresses deterministically.

Ten tests carry the laws L17-L20 and the residuals as executable claims: verbatim
carry yields a witnessed edge; a sub-window unregistered token yields nothing (the
residual, pinned so it is never mistaken for a guarantee); a registered term of
any length is caught; verify_witness re-folds the cut and catches a label tampered
to look clean; a declared-but-lost parent fails closed to top; and — the attack
this exists to stop — a summary carrying an attacker email verbatim does not sit
below a principal-only ceiling, while HighWater still taints a laundered payload
the scan alone cannot see.

Increment 2 of the FL-2 plan; the runtime gate, jcp/3 receipt seal, and gateway
relay follow. The receipt-stream replay (the eight-check chain walk) lands with
the receipt integration, where jcp/3 receipts exist to walk.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
dcharlot closed this pull request 2026-07-27 19:14:33 -04:00

Pull request closed

Please reopen this pull request to perform a merge.
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
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!39
No description provided.