morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #8459] [Design] Recognize repeated Kuna observations without discarding graph provenance #6614

New issue

Open

opened 2026-11-01 21:12:41 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

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

Owner

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

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; this is a design question.
This discussion does not include credentials, private samples, or sensitive target data.

Decision needed

Should an analyst be able to recognize repeated Kuna observations with equal normalized facts when their exact upstream graph documents differ only in REA's private input path? If so, what task-facing comparison or grouping is appropriate while preserving each exact source digest and Evidence identity?

Context and evidence

On REA e18594b24754ab95ebd119311cc32a1d1ad6fa13, Node 24.22.1, macOS arm64 and real Kuna 1.986, I opened the same self-built unexecuted Mach-O in two fresh stdio MCP sessions. In each session, two consecutive analyze_function calls for _evaluate returned the same ID. Across sessions, the two function records had different IDs. Their normalized dossiers and analysis profiles were equal; the only other differing top-level field was raw_result, whose only difference was the SHA-256 of the 2,426-byte Kuna call-graph document. The source target's SHA-256 was unchanged.

A separate direct Kuna control analyzed two byte-identical copies at different paths with decompile-graph --functions ''. Their parsed graphs differed only in binary.sourcePath; their raw graph hashes differed. Two runs on the same path were byte-identical. REA source creates a new private input workspace for each session and its graph reader retains the digest of the complete upstream document. The private-path explanation for the REA graph hashes is an inference from that source and the direct control; I did not capture the actual REA child graph bytes in this run.

Using an internal helper to package both captured records, I imported them into a fresh target-free stdio MCP session. The summary listed two analyze_function records. compare_functions reported equal pseudocode and assembly text but an ambiguous identity and six unknown dimensions. A same-record self-comparison produced the same ambiguity, so the comparison uncertainty is not caused by graph-hash differences; that separate bug is #8367. The result does not establish behavioral equivalence or an autonomous agent failure.

Expected interaction with targets

Read caller-selected local binaries and previously captured Evidence; invoke the selected static provider where requested. REA creates and removes its private workspace. No target execution, injection, or binary mutation is proposed.

Boundary details

The raw graph SHA is correct for the exact bytes actually observed and must not be silently rewritten, removed, or treated as a digest of normalized graph semantics. Preserve both source records, target/provider/profile identity, caller-selected inputs, and evidence provenance. Equal normalized output need not mean identical raw observations or equivalent program behavior.

Options and tradeoffs

Investigate whether existing views or explicit comparisons are sufficient. If a repeat-observation relationship is needed, it could be a separate, bounded derivation with clear input coverage and provenance; it should not redefine Evidence IDs or merge records automatically. A normalized graph fingerprint would require a schema-owned definition and must not ignore potentially meaningful changes merely because they happen to be located in metadata.

Verification available so far

I have observed results.

Success criteria and open questions

Exercise same-session and fresh-session repeats, different target bytes, different provider/profile/graph facts, changed caller-selected paths, malformed graphs and cleanup. Determine whether users need discovery, comparison, or no new interface; do not infer agent selection or broad performance effects from this one fixture. Test any proposed semantic fingerprint for both false matches and false splits.

References

cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8459 ### 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; this is a design question. - [x] This discussion does not include credentials, private samples, or sensitive target data. ### Decision needed Should an analyst be able to recognize repeated Kuna observations with equal normalized facts when their exact upstream graph documents differ only in REA's private input path? If so, what task-facing comparison or grouping is appropriate while preserving each exact source digest and Evidence identity? ### Context and evidence On REA `e18594b24754ab95ebd119311cc32a1d1ad6fa13`, Node 24.22.1, macOS arm64 and real Kuna 1.986, I opened the same self-built unexecuted Mach-O in two fresh stdio MCP sessions. In each session, two consecutive `analyze_function` calls for `_evaluate` returned the same ID. Across sessions, the two function records had different IDs. Their normalized dossiers and analysis profiles were equal; the only other differing top-level field was `raw_result`, whose only difference was the SHA-256 of the 2,426-byte Kuna call-graph document. The source target's SHA-256 was unchanged. A separate direct Kuna control analyzed two byte-identical copies at different paths with `decompile-graph --functions ''`. Their parsed graphs differed only in `binary.sourcePath`; their raw graph hashes differed. Two runs on the same path were byte-identical. REA source creates a new private input workspace for each session and its graph reader retains the digest of the complete upstream document. The private-path explanation for the REA graph hashes is an inference from that source and the direct control; I did not capture the actual REA child graph bytes in this run. Using an internal helper to package both captured records, I imported them into a fresh target-free stdio MCP session. The summary listed two `analyze_function` records. `compare_functions` reported equal pseudocode and assembly text but an ambiguous identity and six unknown dimensions. A **same-record self-comparison** produced the same ambiguity, so the comparison uncertainty is not caused by graph-hash differences; that separate bug is #8367. The result does not establish behavioral equivalence or an autonomous agent failure. ### Expected interaction with targets Read caller-selected local binaries and previously captured Evidence; invoke the selected static provider where requested. REA creates and removes its private workspace. No target execution, injection, or binary mutation is proposed. ### Boundary details The raw graph SHA is correct for the exact bytes actually observed and must not be silently rewritten, removed, or treated as a digest of normalized graph semantics. Preserve both source records, target/provider/profile identity, caller-selected inputs, and evidence provenance. Equal normalized output need not mean identical raw observations or equivalent program behavior. ### Options and tradeoffs Investigate whether existing views or explicit comparisons are sufficient. If a repeat-observation relationship is needed, it could be a separate, bounded derivation with clear input coverage and provenance; it should not redefine Evidence IDs or merge records automatically. A normalized graph fingerprint would require a schema-owned definition and must not ignore potentially meaningful changes merely because they happen to be located in metadata. ### Verification available so far I have observed results. ### Success criteria and open questions Exercise same-session and fresh-session repeats, different target bytes, different provider/profile/graph facts, changed caller-selected paths, malformed graphs and cleanup. Determine whether users need discovery, comparison, or no new interface; do not infer agent selection or broad performance effects from this one fixture. Test any proposed semantic fingerprint for both false matches and false splits. ### References - [Private input workspace creation](https://github.com/morluto/rea/blob/e18594b24754ab95ebd119311cc32a1d1ad6fa13/src/kuna/KunaTargetCommands.ts#L304-L337) - [Graph source projection](https://github.com/morluto/rea/blob/e18594b24754ab95ebd119311cc32a1d1ad6fa13/src/kuna/KunaReferenceQueries.ts#L199-L216) - Related #8367, #8173, #8454. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi added the

enhancement

triage

labels

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

bsakaguchi commented

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

Author

Owner

@morluto commented on GitHub (Nov 1, 2026):

Captured child-graph control

I reran the two-session REA stdio MCP control using a caller-selected, locally written launcher that executes the real Kuna 1.986 and tees only decompile-graph stdout into owned temporary files. This is instrumented and its launcher identity differs from the unwrapped run; all requests in this control used the same launcher. The target remained unchanged and was not executed.

For both sessions, the SHA-256 of the captured graph bytes matched the raw_result.references.sha256 in that session's returned analyze_function Evidence. The captured JSON documents had different binary.sourcePath values naming REA's two private input copies; after removing that one field for the comparison only, the parsed documents were equal. Both private input paths were absent after the sessions closed. The normalized function dossiers remained equal and the Evidence IDs differed.

This directly verifies the private-path explanation for this instrumented run; the earlier unwrapped run independently observed the same public ID/hash behavior, but its child graph bytes were not captured. The exact raw digests remain correct provenance. This is one target and host, and does not establish that every changed graph hash is path-only or that grouping equal normalized output would be safe.

@morluto commented on GitHub (Nov 1, 2026): ### Captured child-graph control I reran the two-session REA stdio MCP control using a caller-selected, locally written launcher that executes the real Kuna 1.986 and tees only `decompile-graph` stdout into owned temporary files. This is instrumented and its launcher identity differs from the unwrapped run; all requests in this control used the same launcher. The target remained unchanged and was not executed. For both sessions, the SHA-256 of the captured graph bytes matched the `raw_result.references.sha256` in that session's returned `analyze_function` Evidence. The captured JSON documents had different `binary.sourcePath` values naming REA's two private input copies; after removing that one field **for the comparison only**, the parsed documents were equal. Both private input paths were absent after the sessions closed. The normalized function dossiers remained equal and the Evidence IDs differed. This directly verifies the private-path explanation for this instrumented run; the earlier unwrapped run independently observed the same public ID/hash behavior, but its child graph bytes were not captured. The exact raw digests remain correct provenance. This is one target and host, and does not establish that every changed graph hash is path-only or that grouping equal normalized output would be safe.

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#6614

No description provided.

Rows
Columns