morluto/rea

Fork 0

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

[GH-ISSUE #8452] [Design] Clarify authority of native matching Evidence views #6608

New issue

Open

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

bsakaguchi commented

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

Owner

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

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

When projecting caller-supplied native matching Evidence, should a view preserve the source's asserted provider and authority, or validate them against the matching producer's contract before using its result?

Context and evidence

Observed: On main e18594b24754ab95ebd119311cc32a1d1ad6fa13, in public stdio MCP with full and compact schema profiles, match_native_functions returned Evidence with provider rea-function-comparison, predicate rea.native-function-matching, confidence derived, and authority analyst-inference. Its summary view preserved analyst-inference.

I constructed a new synthetic, digest-consistent parent using the same matching result, operation, predicate, parameters, and source links, but set the provider to Ghidra and asserted confidence observed and authority shipped-artifact. inspect_analysis_view accepted it; the view reported confidence derived and authority shipped-artifact. The parent was synthesized locally from an actual Ghidra inventory; no Ghidra provider was observed to produce such matching Evidence. The same result was observed on the #8451 candidate.

Source-derived: NativeFunctionMatchingService creates matching records with fixed REA provider and analyst-inference authority, while the generic analysis-view sealer carries the parent's asserted authority. Some other comparison consumers validate a producer/authority identity before interpreting comparison Evidence. Whether that stricter policy applies to this projection is not established by this test. A digest establishes record consistency, not who authored it; a matching provider name alone does not authenticate a producer.

Expected interaction with targets

Read existing files or captured data. The controlled reproduction did not launch or execute a target.

Boundary details

Keep parent identity and caller-provided claims visible. Do not infer external authenticity from a digest or silently replace source Evidence. No target mutation, execution, or new provider capability is proposed.

Options and tradeoffs

Clarify whether matching Evidence has a fixed semantic producer/authority contract that should be validated, or whether views intentionally project externally authored claims and need to make that provenance explicit. Evaluate historical and portable records, and avoid introducing parallel interpretations of identity.

Verification available so far

I have a prototype or observed results.

Success criteria and open questions

Document the intended contract, identify its semantic owner, and check a genuine matching result plus contradictory synthetic and portable records through public workflows. Determine whether any downstream consumer can misinterpret the resulting authority; this was not tested.

References

Related: #8449, #8451, #8098. The last concerns confidence propagation and is resolved; this discussion concerns an asserted parent authority and producer identity.

cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8452 ### 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 When projecting caller-supplied native matching Evidence, should a view preserve the source's asserted provider and authority, or validate them against the matching producer's contract before using its result? ### Context and evidence **Observed:** On main `e18594b24754ab95ebd119311cc32a1d1ad6fa13`, in public stdio MCP with full and compact schema profiles, `match_native_functions` returned Evidence with provider `rea-function-comparison`, predicate `rea.native-function-matching`, confidence `derived`, and authority `analyst-inference`. Its summary view preserved `analyst-inference`. I constructed a new **synthetic**, digest-consistent parent using the same matching result, operation, predicate, parameters, and source links, but set the provider to Ghidra and asserted confidence `observed` and authority `shipped-artifact`. `inspect_analysis_view` accepted it; the view reported confidence `derived` and authority `shipped-artifact`. The parent was synthesized locally from an actual Ghidra inventory; no Ghidra provider was observed to produce such matching Evidence. The same result was observed on the #8451 candidate. **Source-derived:** `NativeFunctionMatchingService` creates matching records with fixed REA provider and `analyst-inference` authority, while the generic analysis-view sealer carries the parent's asserted authority. Some other comparison consumers validate a producer/authority identity before interpreting comparison Evidence. Whether that stricter policy applies to this projection is not established by this test. A digest establishes record consistency, not who authored it; a matching provider name alone does not authenticate a producer. ### Expected interaction with targets Read existing files or captured data. The controlled reproduction did not launch or execute a target. ### Boundary details Keep parent identity and caller-provided claims visible. Do not infer external authenticity from a digest or silently replace source Evidence. No target mutation, execution, or new provider capability is proposed. ### Options and tradeoffs Clarify whether matching Evidence has a fixed semantic producer/authority contract that should be validated, or whether views intentionally project externally authored claims and need to make that provenance explicit. Evaluate historical and portable records, and avoid introducing parallel interpretations of identity. ### Verification available so far I have a prototype or observed results. ### Success criteria and open questions Document the intended contract, identify its semantic owner, and check a genuine matching result plus contradictory synthetic and portable records through public workflows. Determine whether any downstream consumer can misinterpret the resulting authority; this was not tested. ### References Related: #8449, #8451, #8098. The last concerns confidence propagation and is resolved; this discussion concerns an asserted parent authority and producer identity. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi added the

enhancement

triage

labels

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

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

No description provided.

Rows
Columns