Is the EDC control plane the right extension surface for an execution-evidence augmentation layer?

[joy7758]

Hello,

I’m exploring a narrow execution-evidence augmentation layer around EDC, and I’m trying to validate whether the control plane is the right first extension surface.

The current work is not an EDC replacement and not a connector product line. It is a frozen validation artifact around the idea that agent-evidence can sit on top of the EDC control plane and turn runtime/control-plane events into portable, independently verifiable evidence bundles.

Stable entry points:

• Architecture hub: https://github.com/joy7758/digital-biosphere-architecture
• Concrete evidence entry: https://github.com/joy7758/agent-evidence
• EDC Java spike entry: https://github.com/joy7758/agent-evidence/blob/main/docs/edc-java-spike/README.md
• Frozen spike tag: https://github.com/joy7758/agent-evidence/tree/edc-java-spike-freeze-v0.1

What the spike currently validates:

• control-plane event mapping
• grouping / dedup
• exporter handoff
• runtime wiring
• startup smoke
• startup failure contract
• runtime-facing exporter integration

What it intentionally does not do:

• persistence/data plane changes
• signing / verification / anchor in Java
• connector productization
• broad EDC feature expansion

So the question is narrow:

Does it make architectural sense to treat the EDC control plane as the first extension surface for an execution-evidence augmentation layer, while keeping verification/signing/anchoring outside the connector itself?

I’m asking before going any further, because I want to avoid expanding this into the wrong layer.

[paullatzelsperger]

I can only speak for myself here, when I say that I have no idea what you are trying to build, nor do I have any interest in learning it. There is a ton of buzzwords here, and you seem to expect us to read through all of it and understand:

• your project, domain and use case
• your code base
• your domain language

So again, speaking only for myself (other committers may have a different opinion), I am not going to do that. If you have any specific questions about the EDC, after having gone through its documentation, please feel free to ask here, but avoid broadly scoped and open-ended questions like this.

If it's EDC events you are interested in, then please start here: EDC Documentation | Events

[joy7758]

Thanks for the direct feedback. I went back through the EDC documentation and corrected my framing.

The right integration point for my case is not a custom fork of control-plane logic. EDC already models control-plane state transitions as events, so a minimal external audit record should be implemented either as a ServiceExtension subscribing to TransferProcessEvent via EventRouter inside the runtime, or as callbackAddresses/webhooks for out-of-process delivery.

In practice, the records I need map to transfer-process transitions such as transfer.process.requested, transfer.process.started, transfer.process.completed, and transfer.process.terminated, using the event envelope metadata together with the transfer event payload. For consumer-pull, transfer.process.started is also the documented point where the DataAddress becomes available to the consumer runtime.

So I will treat EDC here as an event source and extension point around the control plane, while leaving core control-plane and data-plane behavior unchanged.