open/llm-ingestion-okf
1
0
Fork 0
Code Issues Releases 1 Activity

docs(okf-v0.2): a third axis on the exposure question — where the producer lives

Browse source 
The pilot ran the widened question on their own tree and returned the axis
neither of us could see alone. A value-literal predicate has two sides — the
code that tests the literal and the code that writes it — and they need not
share a codebase. Both sides local means the day the convention moves there is
a local diff to see it in. Producing side behind a version pin means the guard
can stop guarding with no local change at all: a dependency sync is the whole
event, and there is not even a byte diff to dismiss.

The three axes compound rather than stack. Quietest: fail-open, write path,
producer on our side of the pin — nothing local changed, nothing failed loudly,
and a golden byte comparison sees none of the three. Loudest: fail-closed with
both sides local, which is what we carry ourselves (`inbox.py:218`) — recorded
as a property of where the code sits, not as care we exercised.

Provenance of all three widenings is kept in the text deliberately: pilot, then
us, then the pilot again. Each round found what the round before could not,
which is the argument for asking rather than reasoning.

Consumer repo, file, line and the predicate's purpose stay in the mailbox; the
axis is recorded unattributed, as in fcb6e4c and 2541561.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H2Z8pTafcSPgt4rETsxxEP
This commit is contained in:
Kjell Tore Guttormsen 2026-08-09 21:58:04 +02:00
commit 172d3ebcf4
1 changed files with 29 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

34
docs/plan/okf-v0.2-alignment.md
View file

@ -1352,9 +1352,12 @@ asks every consumer to look for a value-literal `generated` predicate by name,
instead of treating the shape change as inert for anyone who reports no golden
churn.
**That question was still too narrow on two axes, and a real instance can answer
it "no" in good faith.** Both widenings were earned rather than reasoned — the
first came back from a pilot, the second from running the question on ourselves.
**That question was still too narrow on three axes, and a real instance can answer
it "no" in good faith.** All three widenings were earned rather than reasoned, and
the order matters: the first came back from a pilot, the second from running the
question on ourselves, the third from that same pilot **running the widened
question on themselves**. Each round found something the round before could not
have, which is the argument for asking rather than reasoning.
- **Where it lives: the write path counts, not only the read path.** "Do you have
a value-literal `generated` predicate?" invites a search of the code that
@ -1369,10 +1372,28 @@ first came back from a pilot, the second from running the question on ourselves.
because refusing looks safe. It is not, measured against the promise we sell: it
turns "a re-run, nothing more" into "a re-run that errors on its own prior
output".
- **Where the literal's producer lives: in the same repo, or behind a version
pin.** A predicate that compares against a literal has two sides — the code that
tests it and the code that writes it — and they need not share a codebase. When
both sides are local, the day the convention moves there is a local diff to see
it in. When the producing side is *this library*, behind a version pin, a
consumer's guard can stop guarding with **no local change at all**: a dependency
sync is the whole event. That consumer has not got a byte diff to dismiss; it has
nothing.
So the question the report asks is: **does anything in your codebase derive
ownership or authenticity from `generated`'s value — in the read path or the write
path — and in which direction does it fail?**
path — in which direction does it fail, and does the code that writes the literal
live with it or on our side of the pin?**
**The three axes compound rather than stack, and that is the part worth saying out
loud in the notification.** The quietest instance is a fail-open predicate, in the
write path, whose producing side is us: nothing local changed, nothing failed
loudly, and the check a careful consumer would reach for — comparing bytes against
a frozen golden — cannot see any of the three. The loudest is a fail-closed
predicate with both sides local, which is what we carry ourselves. **A consumer's
distance from the quiet end is the actual exposure**, and it is not something a
re-run reports.
**We ran it on ourselves, and the answer was not zero.** Enumerating the tracked
tree rather than one package: exactly one value-literal comparison, Door B's
@ -1384,7 +1405,10 @@ mechanism. It is inert today, and bounded twice: Door B both writes and tests th
literal, and the predicate's second conjunct is `source_file`, which no other door
emits — so Door A's O2-stamped output cannot reach that namespace even by name. It
stops being inert the day Door B's stamp moves, because Door B would then refuse to
re-run in place over its own output.
re-run in place over its own output. **On the third axis it sits at the loud end:**
both sides of the literal are ours, so the day it breaks there is a diff in this
repo to break it. That is a property of where the code sits, not a virtue of the
code — we do not get to claim it as care.
**Not fixed here, deliberately, and this is not the same record as the deferral
below.** Routing the predicate through `DEFAULT.ownership.owns` looks