morluto/rea

Fork 0

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

[GH-ISSUE #5118] [Feature] Propagate upstream evidence_links in composed workflow Evidence #3151

New issue

Closed

opened 2026-10-31 00:37:15 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:37:15 +00:00

Owner

Originally created by @uyg7x on GitHub (Oct 18, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5118

Before submitting

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

Area

Evidence, artifacts, or reconstruction

Current limitation

I was looking at how composed workflows like binary_overview or trace_feature build their final Evidence records. Right now, createWorkflowEvidence in src/application/WorkflowEvidence.ts passes along upstreamLimitations and upstreamProfile, but it completely drops evidenceLinks.

Because of this, the final workflow evidence has no programmatic link back to the atomic evidence records (the evidence_ids) that actually built it, which breaks the provenance chain.

Use cases

If an agent runs binary_overview and gets the final derived evidence, it's pretty hard for it to audit its own reasoning or show a human analyst how it reached that conclusion. It can't natively traverse the graph back to the specific atomic calls (like list_procedures) that made up the overview.

Right now, the agent would have to manually track those IDs itself or try to parse unstructured text from the limitations array.

Desired outcome and success criteria

I'd like createWorkflowEvidence to accept an optional upstreamEvidenceLinks parameter and pass it down to createEvidence.

Basically, the final workflow evidence record should just have its evidence_links array populated with the evidence_ids of the intermediate steps that contributed to it, so the provenance is actually preserved across the boundary.

Expected interaction with targets

No target interaction (documentation or usability only)

Target and scope details (optional)

This should just be a bounded fix at the application boundary (mostly WorkflowEvidence.ts and its callers in EnhancedTools.ts / DirectAnalysis.ts). We don't need new MCP contracts or schema changes since the core Evidence type already supports evidence_links.

Verification available so far

Not sure yet

Verification details (optional)

I checked src/application/WorkflowEvidence.ts and saw that createEvidence is called without the evidenceLinks property, even though upstreamLimitations are explicitly forwarded. Also, the Evidence schema in src/domain/evidence.ts already has evidence_links defined, so the data model is ready for it.

Alternatives considered

Appending IDs to the limitations array (e.g., "Derived from evidence ID: ev_..."). This is unstructured and hard for agents to parse reliably. Limitations should really just be for capability/coverage constraints.
Having the calling agent manually track and merge the IDs. This just duplicates logic that the workflow executor is already in the best position to handle.

Possible direction

Add readonly upstreamEvidenceLinks?: readonly string[] to the createWorkflowEvidence input interface.
Pass evidenceLinks: input.upstreamEvidenceLinks into the createEvidence call.
Update the callers (like in EnhancedTools.ts) to collect the evidence_ids from the intermediate steps and pass them in.

References

src/application/WorkflowEvidence.ts (where the links are currently dropped)
src/domain/evidence.ts (shows evidence_links is already a supported field)

Originally created by @uyg7x on GitHub (Oct 18, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5118 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This request does not include credentials, private samples, or sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Current limitation I was looking at how composed workflows like `binary_overview` or `trace_feature` build their final `Evidence` records. Right now, `createWorkflowEvidence` in `src/application/WorkflowEvidence.ts` passes along `upstreamLimitations` and `upstreamProfile`, but it completely drops `evidenceLinks`. Because of this, the final workflow evidence has no programmatic link back to the atomic evidence records (the `evidence_id`s) that actually built it, which breaks the provenance chain. ### Use cases If an agent runs `binary_overview` and gets the final derived evidence, it's pretty hard for it to audit its own reasoning or show a human analyst how it reached that conclusion. It can't natively traverse the graph back to the specific atomic calls (like `list_procedures`) that made up the overview. Right now, the agent would have to manually track those IDs itself or try to parse unstructured text from the limitations array. ### Desired outcome and success criteria I'd like `createWorkflowEvidence` to accept an optional `upstreamEvidenceLinks` parameter and pass it down to `createEvidence`. Basically, the final workflow evidence record should just have its `evidence_links` array populated with the `evidence_id`s of the intermediate steps that contributed to it, so the provenance is actually preserved across the boundary. ### Expected interaction with targets No target interaction (documentation or usability only) ### Target and scope details (optional) This should just be a bounded fix at the application boundary (mostly `WorkflowEvidence.ts` and its callers in `EnhancedTools.ts` / `DirectAnalysis.ts`). We don't need new MCP contracts or schema changes since the core `Evidence` type already supports `evidence_links`. ### Verification available so far Not sure yet ### Verification details (optional) I checked `src/application/WorkflowEvidence.ts` and saw that `createEvidence` is called without the `evidenceLinks` property, even though `upstreamLimitations` are explicitly forwarded. Also, the `Evidence` schema in `src/domain/evidence.ts` already has `evidence_links` defined, so the data model is ready for it. ### Alternatives considered 1. Appending IDs to the `limitations` array (e.g., "Derived from evidence ID: ev_..."). This is unstructured and hard for agents to parse reliably. Limitations should really just be for capability/coverage constraints. 2. Having the calling agent manually track and merge the IDs. This just duplicates logic that the workflow executor is already in the best position to handle. ### Possible direction 1. Add `readonly upstreamEvidenceLinks?: readonly string[]` to the `createWorkflowEvidence` input interface. 2. Pass `evidenceLinks: input.upstreamEvidenceLinks` into the `createEvidence` call. 3. Update the callers (like in `EnhancedTools.ts`) to collect the `evidence_id`s from the intermediate steps and pass them in. ### References - `src/application/WorkflowEvidence.ts` (where the links are currently dropped) - `src/domain/evidence.ts` (shows `evidence_links` is already a supported field)

bsakaguchi

2026-10-31 00:37:15 +00:00

closed this issue
added the
triage

enhancement
labels

bsakaguchi commented

2026-10-31 00:37:16 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 19, 2026):

This is a very reasonable gap — dropping evidence_links at the workflow boundary silently severs the provenance chain, and forcing agents to parse the limitations array is fragile. I'd support adding the optional upstreamEvidenceLinks passthrough as proposed.

One thing worth considering during implementation: when workflows compose other workflows (nested), make sure evidence_links doesn't accidentally create cycles — either dedupe by evidence_id or keep the depth bounded. Also confirm downstream consumers that already read evidence_links (e.g. the CLI evidence tree) tolerate empty arrays, so the default behavior stays backwards-compatible when the parameter is omitted.

@XinwangTao commented on GitHub (Oct 19, 2026): This is a very reasonable gap — dropping evidence_links at the workflow boundary silently severs the provenance chain, and forcing agents to parse the limitations array is fragile. I'd support adding the optional upstreamEvidenceLinks passthrough as proposed. One thing worth considering during implementation: when workflows compose other workflows (nested), make sure evidence_links doesn't accidentally create cycles — either dedupe by evidence_id or keep the depth bounded. Also confirm downstream consumers that already read evidence_links (e.g. the CLI evidence tree) tolerate empty arrays, so the default behavior stays backwards-compatible when the parameter is omitted.

bsakaguchi referenced this issue

2026-10-31 01:08:13 +00:00

[PR #3151] [CLOSED] docs(releasing): make compatibility review version-agnostic #5644

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

No description provided.

Rows
Columns