[GH-ISSUE #8546] [Design] Make residual-unknown target scope explicit for Evidence handoffs #6641

New issue

Open

opened 2026-11-01 21:12:53 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-01 21:12:53 +00:00

Owner

Originally created by @morluto on GitHub (Nov 1, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8546

Before submitting

I searched the open and closed issues and pull requests for a related discussion.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This discussion does not include credentials, private samples, or sensitive target data.

Decision needed

Should callers be able to select and inspect the target scope when creating a residual unknown from retained Evidence, including in a target-free session?

Context and evidence

On REA #8509 head 7f344af1aa0a78fd4e331dbbc9c30d38e4cfb796, using actual full and compact MCP registrations, I imported authentic Ghidra load-image Evidence for a source-owned ELF A into a fresh target-free session. record_unknown with that Evidence as support created the question with scope_digest: null. After opening A, recording the same question and supporting Evidence created a second unknown with A's digest and a different stable ID. After selecting a different source-owned binary B, recording a new question explicitly about A with the same supporting Evidence created an unknown scoped to B. Both targets and the imported bundle were unchanged; neither target was executed.

The observed behavior follows the current implementation's active-target scope. The record_unknown tool description says it creates a deterministic unknown, but does not explain this scope selection. This is a scope/identity and recovery design question, not a claim that supporting Evidence must always determine the scope: an unknown can relate to multiple artifacts or intentionally be global.

Expected interaction with targets

Read caller-selected existing Evidence and update only the investigation's retained records. Avoid executing or modifying targets. Exact operations and side effects depend on the design chosen.

Boundary details (optional)

Preserve explicit caller choice among a known target scope, a deliberately global/unknown scope, and unresolved or incompatible identities. Do not silently infer a single scope from one of several supporting records or equate missing scope with global intent. Stable unknown identity and independently resolvable questions must remain explicit. Consider existing retained unknowns and multi-artifact comparisons without rewriting their history.

Options and tradeoffs

Consider exposing the current active-target default and its implications in the tool contract, and whether a typed explicit scope selection or Evidence-scoped creation is needed for target-free handoffs. Compare exact target identity validation, conflicting/multiple Evidence subjects, offline bundles, and separately opening a target. Do not silently switch or reopen a caller's target merely to establish scope.

Verification available so far

I have a prototype or observed results.

Success criteria and open questions

Exercise same-question records with no target, the supporting Evidence's target, and a different active target; two distinct target scopes; multi-artifact or null-subject Evidence; unknown/detached identities; duplicate and resolution behavior; offline import/export and bounded inputs. Confirm the caller can tell which scope was chosen before relying on it. The current control covers one host, two owned binaries, one authentic Ghidra Evidence record and both MCP schema profiles; no autonomous-agent behavior or CLI coverage was measured.

References

Related: #8510's exploratory partial-source recovery exposes a target-free handoff; #8373 concerns bounded presentation of trace unknowns. The current BinarySessionRecords.recordUnknown selects the active analysis target, and EvidenceLedger.recordUnknown derives the stable scope digest from the unknown-mutation Evidence subject. See tool contract and unknown identity.

@gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Existing unknown updates across target changes

On unchanged #8509 head 7f344af1a, real compact and full stdio MCP imported a bundle containing an existing unknown scoped to source-owned target A. Updating its severity in a target-free session kept the unknown's scope at A but created mutation Evidence with a null subject. After opening different target B, another severity update kept the unknown scoped to A but created mutation Evidence with B as its subject. Revisions advanced 2 → 3 → 4. Export and import into a fresh target-free session preserved the revision-4 head and both mutation Evidence records in both profiles. The targets were unchanged and unexecuted. The imported unknown was created in a separate exploratory workflow; the update and handoff controls ran on the unchanged branch.

This follows source behavior: the unknown retains immutable scope while update_unknown passes the active target as the mutation Evidence subject. Whether that subject is intended to represent the editing session's active target, the question's scope, or something else is not stated by the tool contract. The mismatch is an Evidence-meaning and agent-UX question; it is not evidence that target B was analyzed or that the unknown itself changed scope. Consider making both meanings explicit and preserving offline updates, rather than silently substituting either target. Initial harness attempts incorrectly treated sorted mutation Evidence IDs as chronological; the successful control identified each new mutation by set difference.

Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8546 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [x] I understand the contribution scope must be reviewed before integration; open questions are welcome here. - [x] This discussion does not include credentials, private samples, or sensitive target data. ### Decision needed Should callers be able to select and inspect the target scope when creating a residual unknown from retained Evidence, including in a target-free session? ### Context and evidence On REA #8509 head `7f344af1aa0a78fd4e331dbbc9c30d38e4cfb796`, using actual full and compact MCP registrations, I imported authentic Ghidra load-image Evidence for a source-owned ELF A into a fresh target-free session. `record_unknown` with that Evidence as support created the question with `scope_digest: null`. After opening A, recording the same question and supporting Evidence created a second unknown with A's digest and a different stable ID. After selecting a different source-owned binary B, recording a new question explicitly about A with the same supporting Evidence created an unknown scoped to B. Both targets and the imported bundle were unchanged; neither target was executed. The observed behavior follows the current implementation's active-target scope. The `record_unknown` tool description says it creates a deterministic unknown, but does not explain this scope selection. This is a scope/identity and recovery design question, not a claim that supporting Evidence must always determine the scope: an unknown can relate to multiple artifacts or intentionally be global. ### Expected interaction with targets Read caller-selected existing Evidence and update only the investigation's retained records. Avoid executing or modifying targets. Exact operations and side effects depend on the design chosen. ### Boundary details (optional) Preserve explicit caller choice among a known target scope, a deliberately global/unknown scope, and unresolved or incompatible identities. Do not silently infer a single scope from one of several supporting records or equate missing scope with global intent. Stable unknown identity and independently resolvable questions must remain explicit. Consider existing retained unknowns and multi-artifact comparisons without rewriting their history. ### Options and tradeoffs Consider exposing the current active-target default and its implications in the tool contract, and whether a typed explicit scope selection or Evidence-scoped creation is needed for target-free handoffs. Compare exact target identity validation, conflicting/multiple Evidence subjects, offline bundles, and separately opening a target. Do not silently switch or reopen a caller's target merely to establish scope. ### Verification available so far I have a prototype or observed results. ### Success criteria and open questions Exercise same-question records with no target, the supporting Evidence's target, and a different active target; two distinct target scopes; multi-artifact or null-subject Evidence; unknown/detached identities; duplicate and resolution behavior; offline import/export and bounded inputs. Confirm the caller can tell which scope was chosen before relying on it. The current control covers one host, two owned binaries, one authentic Ghidra Evidence record and both MCP schema profiles; no autonomous-agent behavior or CLI coverage was measured. ### References Related: #8510's exploratory partial-source recovery exposes a target-free handoff; #8373 concerns bounded presentation of trace unknowns. The current `BinarySessionRecords.recordUnknown` selects the active analysis target, and `EvidenceLedger.recordUnknown` derives the stable scope digest from the unknown-mutation Evidence subject. See [tool contract](https://github.com/morluto/rea/blob/aa48d494e/src/contracts/sessionToolContracts.ts) and [unknown identity](https://github.com/morluto/rea/blob/aa48d494e/src/domain/residualUnknown.ts). @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 ### Existing unknown updates across target changes On unchanged #8509 head `7f344af1a`, real compact and full stdio MCP imported a bundle containing an existing unknown scoped to source-owned target A. Updating its severity in a target-free session kept the unknown's scope at A but created mutation Evidence with a null subject. After opening different target B, another severity update kept the unknown scoped to A but created mutation Evidence with B as its subject. Revisions advanced 2 → 3 → 4. Export and import into a fresh target-free session preserved the revision-4 head and both mutation Evidence records in both profiles. The targets were unchanged and unexecuted. The imported unknown was created in a separate exploratory workflow; the update and handoff controls ran on the unchanged branch. This follows source behavior: the unknown retains immutable scope while `update_unknown` passes the active target as the mutation Evidence subject. Whether that subject is intended to represent the editing session's active target, the question's scope, or something else is not stated by the tool contract. The mismatch is an Evidence-meaning and agent-UX question; it is not evidence that target B was analyzed or that the unknown itself changed scope. Consider making both meanings explicit and preserving offline updates, rather than silently substituting either target. Initial harness attempts incorrectly treated sorted mutation Evidence IDs as chronological; the successful control identified each new mutation by set difference.

No milestone

No project

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

morluto/rea#6641

No description provided.

Rows
Columns