Add a worked evaluation walkthrough for the data-request intake pack (closes #44) - #63
Merged
Conversation
kikashy
force-pushed
the
use-case-walkthrough
branch
2 times, most recently
from
August 15, 2026 01:02
c73d2ec to
c435345
Compare
docs/use-cases/data-request-intake.md walks one pack from document to disposition through four authoritative corpus rows, connecting the example packs and the evaluation corpus, which the documentation kept separate. Rows 1 and 2 are placed adjacent deliberately: identical fact shape, one requirement flipped from present to absent, opposite results. That is what makes `required` visible as the thing that decides, against the optional requirement in row 1 that goes unmentioned. Row 3 states that proceed would otherwise have been true, because a forced outcome that only fired when nothing else applied would demonstrate nothing. Row 4 says the conflict is never tie-broken — not by order, specificity or severity. Every claim was checked against conformance/evaluation/manifest.json rather than transcribed: four dispositions, sixteen fact values, four cited spec sections, and the byte-identity of the example pack with its corpus copy, which is the guide's own premise. Closes with what Core evaluation does not establish: acquisition, authorization and action, each named rather than left implied. Signed-off-by: kikashy <kikashy@hotmail.com>
kikashy
force-pushed
the
use-case-walkthrough
branch
from
August 15, 2026 01:04
c435345 to
be4957a
Compare
|
🎉 Thank you for your contribution to Judgment Pack! If you’d like another task, choose a path that interests you: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #44.
docs/use-cases/data-request-intake.mdconnects two surfaces the documentation kept separate: the example packs and the authoritative evaluation corpus. A reader could inspect either but nothing walked one pack from document to disposition.Four authoritative rows, each traced through the pack's own applicability, evidence, exception and rules:
proceed-complete-and-appropriateproceedrequired-evidence-absentmissing-required-evidencerequiredis what makes absence decisiveforced-outcome-embargodecline-redirectproceedwould otherwise have been trueconflict-decline-and-clarifyconflictRows 1 and 2 are deliberately adjacent: identical fact shape, one requirement flipped, opposite results. Row 3 states plainly that
proceedwould have been true otherwise — a forced outcome that only ever fired when nothing else applied would demonstrate nothing.Verified, not transcribed from memory
A script checked every claim against
conformance/evaluation/manifest.json: all four dispositions, all sixteen fact values, every citedspecSection(§§7.5, 8 step 9;§8 step 2;§8 steps 4, 6;§8 step 8), and the byte-identity of the example pack with its corpus copy.That last one matters for the guide's premise — the document a reader opens is the document the rows were judged against — so it is asserted rather than assumed.
Boundaries
A closing section states what Core evaluation establishes and what stays outside it: acquisition (nothing is fetched;
evidenceAvailabilityis a tri-state the caller supplies, and the evaluator never learns whether a document is genuine or current), authorization (proceedis not permission, per §3.5), and action (a handoff ofrequestedrecords that a target should receive one, it does not deliver it).Suite:
64 passed, 529 subtests. No schema, corpus, or normative text changes.🤖 Generated with Claude Code