feat(deployment): add deployment and targetRollout subjects and events

[xibz]

Problem

service.deployed/service.upgraded conflate two different kinds of fact into one event. Every other subject pair in the spec separates orchestration (the act of doing something) from entity (the resulting state) — build is the orchestration event, artifact is the entity fact it produces. service.deployed/upgraded are the one place that doesn't hold: a single event tries to say both "a rollout happened" and "this service instance is now running v2," with no way to talk about the rollout on its own. That's also why service has no queued/started predicates — queuing and starting are true of a deployment, not of a service, so producers who need lifecycle visibility into an in-progress rollout have no canonical event to emit and end up inventing their own conventions.

This also means there's no way to represent a single deployment fanning out to multiple simultaneous destinations with one aggregate outcome — e.g. rolling a release out to 3 regions, or to a canary slot plus the main fleet, within the same environment. Today you'd emit N separate service.deployed events and the consumer has to infer, out of band, which ones belong to the same deployment attempt and what the combined success/failure state is.

Finally, environment has no inbound link to what's running in it. environment.created/modified/deleted describe the platform alone; the only way to find out what's deployed into an environment today is to scan service events and filter on content.environment.id, a reference that points from the entity down to the environment — backwards from every other "what happened in this environment" query you'd want to run.

Solution

Introduces deployment (the aggregate act of applying a release to one or more target rollouts, one per environment) and targetRollout (a specific destination within that environment, e.g. a region or canary slot) as the orchestration-side subjects service was missing, each with queued/started/finished lifecycle events. targetRollout.finished carries failureType for per-destination failure detail; deployment.finished is all-or-nothing across all of its target rollouts.

targetRollout also gives environment a first-class inbound link: querying "what was rolled out to this environment" becomes direct instead of an inference over service events.

service.deployed/service.upgraded are unchanged in behavior and retained for backwards compatibility as the entity-side fact, now deprecated in favor of deployment.finished/targetRollout.finished for the orchestration-side fact.

Changes

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has the primer doc been updated if a design decision is involved
• Have the JSON schemas been updated if the specification changed
• Has spec version and event versions been updated according to the versioning policy
• Meets the CDEvents contributor standards

[sol-duara]

Hey @xibz, per your instructions for introducing new concepts, this seems a bit lacking in explanation. It is not clear what problem you are solving that CDEvents already solves, or how this approach addresses it. I would really like to understand what you mean by multi-target-aware deployment. How is that different from other deployments? How did you run into the situation? Where did the existing structure fail you?

Thanks!

[xibz]

@sol-duara - I updated the PR body which should help

[sol-duara]

"service.deployed/service.upgraded conflate two different kinds of fact into one event."

@xibz These seem to be two separate events. What is the 'fact' that you are referring to, and which one of these events is it in?

Are you calling the event that signals a service/application reaching its destination the deployment process proper? I can see the need for a deployment enclosure: deployment.started & deployment.finished. That would allow the deployment manifest to be included, like the information about what is being built in a build event. That would make each service.deployed a landing confirmation event.

Based on what you (or Claude) have written, I can't follow the intent. Currently, I treat service as a per-instance set (one or more) releases of an artifact. But that is what you are calling a targetedRollout. It seems to be a distinction without a difference.

Finally, environment: is your expectation that the event becomes the system source of truth?

[xibz]

Thanks for pushing on this, these are exactly the right questions.

1. "These are two separate events — which one is 'the fact'?"

Fair, my earlier phrasing was sloppy. It's not that the two events split one fact between them, each one individually conflates two facts. service.deployed alone says both "a rollout action completed" (orchestration) and "this service instance now runs v1.2.3" (entity state), in a single event, with no way to reference or observe the rollout independently of the resulting state. Same for service.upgraded.

2. "I can see the need for a deployment enclosure... make each service.deployed a landing confirmation event."

That's very close to what we're proposing, the disagreement is really just about what fills the "where" slot inside that enclosure, which is point 3.

3. "That's what you're calling a targetRollout. Distinction without a difference."

The cleanest way to state the split:

• deployment is about what: one release, one artifact/version, one aggregate outcome. It doesn't know or care how many destinations it's going to.
• targetRollout is about where: one destination that release is being sent to. A deployment fans out into N targetRollouts, one per destination, each with its own outcome and failureType.
• service is neither of thos, it's the resulting entity. It doesn't answer "what" or "where" in the delivery sense; it answers "what's running here right now, and how did its version change over time." That's why service persists across many deploys (deployed -> upgraded -> upgraded -> rolledback, one identity, many transitions over its life), while targetRollout is minted fresh per deployment attempt, it's the record of this delivery to this place, not the thing that ends up running there.

service happens to already be scoped to one place, which makes it look like it's playing the "where" role targetRollout plays. But it's answering a different question: service says what's currently there; targetRollout says whether a specific delivery attempt to that place succeeded. targetRollout can be queued/started before anything is running at all: service can't express that, since it only exists once there's something to describe.

4. "Is your expectation that the event becomes the system source of truth?"

This is meant to say only what happened.

[sol-duara]

@xibz Interesting.

We see service.deployed as an action the deploying tool makes: I put this there. No more, no less. From our perspective, you seem to be reading a lot into the action that is related to your process. But everyone else doesn't necessarily share that process. You cite the need for the event to be an observation of state. That is defining the event as a source of stateful truth. Not a record of an activity; the event took place. I would hope that we are focused on the most accessible interpretations.

We don't see any reason to deprecate what is already there. We are not opposed to introducing a new event, as long as what is already there stays (no deprecation of service.deployed or service.upgraded) and you can show the tool that has the target rollout step you are referencing. We wholeheartedly support the addition of deployment.started and deployment.finished; iff the deployment.started event has a manifest object carrying what is expected to be deployed and the deployment.finished event has a reconciliation object for the deployment.

[xibz]

@sol-duara (rewrote this like 10x lol)

If the primary concern is deprecation, I would argue that keeping service.deployed alongside deployment.finished creates more harm than deprecating it.

Which event should new producers emit? Which event should consumers rely on?

We can keep service.deployed, but doing so would leave two events with overlapping meanings and create unnecessary confusion for new users.

Deprecating it would not result in its immediate removal. It would remain available for compatibility, with removal only considered in a future major version.

[sol-duara]

@xibz

We don't use service.deployed in the way that you are suggesting, which is why we are opposed to deprecating it. From our perspective, there is no overlap between the two. Are you suggesting that the only way to use these events is the way you think they should be used? I am only trying to ensure that a new paradigm is not imposed for something that currently works from our perspective. As I mentioned, we were already going to propose deployment.started and deployment.finished, as we thought it was just an oversight, like no outcome on build.finished.

So, again, because we are currently using service.deployed (and service.upgraded), we would prefer it not be deprecated without cause.

[xibz]

@sol-duara

What does service.deployed normatively mean, and how is that meaning observably distinct from deployment.finished for a consumer?

[sol-duara]

@xbiz Think micro-service vs application service. CloudDriver might be deployed, but Spinnaker is not finished.

Does that help?

[xibz]

To be very clear, I think the example you gave is an illustration of the conflation that isnt being separated. If we need to describe partial deployments, e.g., microservices, that should live in the deployment subject

[darckorner]

Thank you, @xibz . You are making my point: the CDEvents SIG is not the authority on what build means. We are aware that semantically there is enough commonality in the ephemeral concept of build to identify what the tools do and have them emit something consistent. Consumption is a function of intent. What the consumer is doing with the information is up to the developer. Our paradigm does not imply intent. That is what makes it interoperable.

Put simply, your description does not match our execution paradigm. We have no conflation because they are separate, and the users choose via their intent declaration. Words are reused in this space. Reuse should be allowed, however the user intends. Not the SIG. I can't tell you what works for you and your use case. Just like you can not for ours. I can say, however, that we are using those events and do not think they should be deprecated.

So, unless you are saying our definitions must match your intent, I gave the answer I gave, and disagreement is always allowed.

[xibz]

The goal of CDEvents has always been to structurally and semantically define concepts across the SDLC. That was the intent Andrea and I established for the project.

We are not changing that goal now by reducing CDEvents to a structural format whose semantics are defined independently by each producer or consumer.

[xibz]

Put simply, your description does not match our execution paradigm. We have no conflation because they are separate, and the users choose via their intent declaration. Words are reused in this space. Reuse should be allowed, however the user intends. Not the SIG. I can't tell you what works for you and your use case. Just like you can not for ours. I can say, however, that we are using those events and do not think they should be deprecated.

I have repeatedly asked for the semantic distinction between service.deployed and deployment.finished, but I still do not think that distinction has been explained.

You gave two examples. I explained that I believe those examples illustrate the conflation I am trying to remove. The response was essentially that your execution paradigm does not model them that way.

That tells me that your system treats them as different, but it still does not explain what each event semantically asserts or why those assertions are distinct.

What does service.deployed mean, what does deployment.finished mean, and what does one communicate to a consumer that the other does not? why should that scope be represented by service instead of deployment.

We do not have artifact.built or dependency.built events. Instead those are modeled by the build subject, and the entities describes its properties. However for some reason service.deployed is special.

[darckorner]

My apologies, @xibz, I did not realize you established the project. I thought it pre-dated you, as did the events in question. I don't owe you an explanation, as the events predate my company and me. We are merely saying that we use them and don't see anything in your new events that would change that. On the subject of evidence not supplied, we could put forth the same argument about targetedRollout. You have not supplied the tools that have the targeted rollout step in question. Our view is that it is a community, and we can not speak for everyone, including you; as such, we should not gate it. Maybe you are on to something.

Would you prefer that we take the stance that you need to prove the addition first? The events you are asking us to prove for you are already here. Why would we bother to do that for you? They are already here. All we said was that we'd like them to stay, and we welcomed your addition. Is your goal to build community or dictate your will?

[xibz]

@sol-duara - I have yet to hear a reason not to deprecate service.deployed beyond the fact that your company currently uses it.

That is a valid compatibility concern, but it does not by itself establish a semantic reason for keeping the event as part of the recommended model. Deprecation would not remove it immediately or prevent existing users from continuing to emit it.

I want to steer this back toward the specific issues I have raised:

1. CI does not model the equivalent relationship this way. We use build.finished; we do not have artifact.built. This same separation is why the deployment events were introduced.
2. Keeping both service.deployed and deployment.finished creates ambiguity for producers and consumers.
3. The partial-deployment use case you described is not mutually exclusive with the deployment subject. A deployment scoped to a single microservice is still a deployment.

Each time I raise these points, the response is effectively that your execution paradigm treats the events differently. But if service.deployed is being used to describe the deployment of an individual microservice, moving that meaning to deployment.<predicate> would still support the same use case. The scope of the deployment changes; the underlying concept does not.

So I am still trying to understand the argument against deprecation beyond existing usage. What semantic capability would be lost by representing this through the deployment subject instead?

And, since I understood your response as suggesting that I had not provided a rationale for these events, here is a concise restatement:

1. deployment describes the orchestration of a deployment, just as build describes the orchestration of producing an artifact.
2. Introducing deployment prevents service from representing two separate concepts: the deployment activity and the resulting service entity.
3. deployment describes what is being deployed, while targetrollout describes where and how that deployment is being rolled out.

Given that CDEvents is still pre-1.0, I would rather make these corrections now than carry forward concepts that appear semantically overlapping. Our responsibility is to model the domain as clearly and consistently as possible. Today, I still find service.deployed difficult to justify independently from deployment.finished. And mind you, im totally open to keeping it if there's solid reasons, but I need answers to my questions to really help determine that.

There is no request here for you to do something “for me.” This is a request to participate in the governance process by explaining the semantic and practical justification for retaining the event alongside deployment.finished.

Simply saying that your company uses it is a valid compatibility concern, but it is not, by itself, a governance reason to keep the event in the recommended model.

[sol-duara]

@xibz I disagree. I gave you the use case several turns ago, and you did not like it. Perhaps it did not meet your personal definition of semantics. I don't know. Are you moving away from an open standard to one that is more prescriptive? Where is this documented? Where might one find this philosophy of how your vision of semantics works? Is it in the project thesis? I did not see it. I just mentioned that we are using what is already there for our purposes as is, and your addition is a distinction without a difference from our perspective and how our system works. Are you implying that the goal here is that everyone has to use CDEvents the @xibz way? (That is the thing that you are not addressing. You seem to be saying the open standard should not be open but only fit your seemingly very narrow semantic vision that you have documented nowhere as a direction for the product.)

You seem to be pushing this concept, but you have not demonstrated that it works anywhere, @xibz. Why does it bother you so much that we won't commit to deprecating a thing until the very unproven concept is actually proven to be useful? We are already using what is there @xibz—semantically. Becuase, we know how. We have laid it out here, if you want to understand it. Again, where is yours??? Is this your personal project or a project of community?

Help me understand. I am more than happy to fork and continue the journey just down the hall.

[xibz]

So I’m going to consider this thread closed, because the core question still hasn’t been answered (a use case wasnt what I asked. I asked for a semantic distinction and why it must live in the service subject). I’m not pushing some concept; I’m asking a question that does not seem to be getting an answer.

I have answered all of your questions, including a follow-up question I had already addressed. Rather than continue beating a dead horse, let’s consider this discussion closed.

Let’s focus on the specification. If you do not have any specification related questions to this proposal, then we can open a separate slack discussion instead

[sol-duara]

@xibz Are you going to provide the examples of your target roll-out system actually working somewhere that I asked for? This is your PR, not mine. I am the one who asked for validation. Your proposal is a distinction without a difference from what is actually already there. I asked you for something to back it up other than your posture. You have not provided it but somehow moved to me, owing you proof on your PR. (Which made no sense.) But if your stance is that you don't need to provide your semantic vision or example of how your idea works, I don't think we should move forward with this until you do.

[xibz]

@sol-duara I think there was a miscommunication. The PR summary provides concrete use cases, but it sounds like you were specifically asking for an existing system that performs this kind of rollout.

Spinnaker is one example. It supports deployments across multiple regions and canary deployments in which a change is partially rolled out and evaluated before broader promotion. A single release pipeline can therefore contain multiple destination-specific deployment operations whose results contribute to the outcome of the broader release.

The proposed CDEvents model represents that pattern as:

deployment: the aggregate deployment operation;
targetRollout: one deployment attempt to a particular destination, such as a region or canary target;
service: the resulting entity running at that destination.

Spinnaker does not call this concept targetRollout; that is the proposed CDEvents abstraction over the underlying deployment pattern. The PR summary also gives the examples of rolling one release out to three regions or to a canary target and the main fleet.

Is that the type of implementation example you were asking for?

[sol-duara]

Yes, I read the use cases, @xibz. And I was in agreement with deployment.started and deployment.finished.

I said targeted rollout, as you describe, gives us nothing new or different.

You are positing:

deployment: the aggregate deployment operation;
targetRollout: one deployment attempt to a particular destination, such as a region or canary target;
service: the resulting entity running at that destination.

I am saying it is functionally no different than:

deployment.started, service.deployed <-- for service A, service.deployed <-- service B, and service.published <-- the combined service deployment is now complete, deployment.finished this pattern already works in our system. There is no reason to adopt what you are saying; we do not want to deprecate.

You have just said that Spinnaker does not have the pattern. You made it up. I am asking for the complete system vision, if you are asking us to give up what works for us for you. Does your system cover every use case in the SDLC workflow cycle? Ours does. (It is weird because you sat in the room with me when we, you and I, figured it out.)

Where is the proposal for your semantic vision?

[xibz]

@sol-duara, I think we are still talking past each other, so let me separate the questions.

First, I did not say Spinnaker lacks the rollout pattern. I said Spinnaker does not use the literal term targetRollout. targetRollout is the proposed CDEvents abstraction for a destination-specific rollout operation, such as a rollout to a region, canary target, or main fleet. Saying that an implementation does not use the proposed standardized name is not the same as saying that it does not perform the underlying operation.

Second, the sequence you described is useful because it finally makes your implementation model more concrete:

• deployment.started
• service.deployed for service A
• service.deployed for service B
• service.published
• deployment.finished

However, this does not show that service.deployed and targetRollout.finished are functionally equivalent.

Your example separates the operation by component: service A and service B.

targetRollout separates a deployment by destination: region A, region B, a canary target, the main fleet, and so on.

Those are independent dimensions. A single service could be rolled out to several destinations, and several services could each be rolled out to several destinations. Saying “service A was deployed” does not necessarily identify which destination-specific rollout attempt completed, its individual outcome, or how that attempt relates to the aggregate deployment.

More importantly, your sequence explains how your system currently uses service.deployed, but it still does not answer the normative question I have been asking:

What fact does service.deployed communicate that cannot be represented by a deployment-scoped completion event, and why must that fact use the persistent service entity as its subject?

The fact that service A completes before the combined application deployment finishes establishes that there are multiple scopes of orchestration. I agree with that. What it does not establish is that the smaller scope is no longer a deployment operation.

For example, the model could contain:

• an aggregate deployment;
• a component-scoped deployment for service A;
• a component-scoped deployment for service B;
• destination-specific target rollouts beneath each deployment;
• and the resulting service entities.

That represents both component-level and aggregate completion without using the resulting service entity as the subject of the deployment activity.

So the question is not whether your current sequence works for your implementation. I understand that it does. The question is whether retaining service.deployed alongside the new deployment events gives independent producers and consumers two semantically distinct facts, or merely two ways to represent deployment completion.

If there is a distinct fact or capability that would be lost, please describe it directly:

1. What does service.deployed normatively assert?
2. What does deployment.finished normatively assert?
3. What does targetRollout.finished normatively assert?
4. Why can the first assertion not be represented through the deployment model?
5. Why is service, rather than a deployment operation, the necessary subject?

Those answers would identify an actual gap in the proposal, and I am open to changing the model or retaining the event if such a gap exists.

But “our system currently emits these events in this sequence” establishes existing usage and a compatibility concern. It does not, by itself, establish the semantic boundary required to recommend both models going forward.

Yes, I believe the model can cover the full SDLC workflow. Producers can choose which standardized facts accurately represent what their tools do; they are not required to emit every available event.

I see no inherent reason why deployment and targetRollout could not represent the relevant deployment use cases. If a concrete use case exposes a capability they cannot represent, then we should identify that gap and either extend the model or add the necessary concept. That is precisely why I have been asking you to explain what your use of service.deployed communicates that the proposed model cannot.

[sol-duara]

My point, @xibz, is that it is you who have to convince me that your system gives mine something extra that I would need. It is your PR, Sir. You went on a tangent that I owed you proof; I did not. The extra data you describe does not necessarily need to be in the event (nor is it precluded in our system; you are free to add it), as it is not authoritative about the deployment. You only need to map the event to where the data actually is for the systems that need to know it, and you are done. I don't need the extra data to achieve what you describe; ours is semantic orchestration. The events are already aligned with the data source of authority. That is the premise of the workflow YAML.

So, I ask again, where can we find your semantic vision proposal?

[xibz]

@sol-duara I think we are still discussing two different questions.

You are asking:

Why should I adopt targetRollout?

I am asking:

What does service.deployed mean that deployment.finished does not?

Those are different questions.

I am not asking you to prove your system works. I already accept that it works for your implementation.

I am also not asking you to prove that targetRollout is valuable.

I am asking you to define the semantic distinction that you believe exists today.

For example:

• What fact does service.deployed communicate?
• What fact does deployment.finished communicate?
• Why are those different facts?
• Why must the first fact use the service subject instead of the deployment subject?

That is not a request for proof. It is a request for a definition.

The reason I keep asking is simple:

If I do not understand what semantic capability you believe service.deployed provides, then I cannot determine whether the proposed model already represents it, represents it differently, or genuinely lacks it.

So before we can discuss whether the proposal gives your implementation anything extra, we first need to agree on what semantic distinction you believe exists today.

[sol-duara]

@xibz this is your PR. All of the proof provided needs to come from you (and I provided a link to my system; it addresses what you are asking). We are asking for yours. We are asking YOU to prove your targeted rollout system has value over what it is existing.

You keep saying it is semantic, but when I ask for your system of semantics, you go back to asking me for proof in your PR.

I agree this has moved way beyond weird. I was originally for the addition. We believe that everyone should be allowed to do their thing in an open system. That is why we asked that what is there not be deprecated. You are making a decision for everyone. And you seem to expect "everyone" to agree with you when you have not provided a system of operation for how you see these consumers working. It is not like they can not query a database that is authoritative.

I find your approach very argumentative, and I am not sure why you feel the need to attack me for asking questions about how your vision works or make this about the community needing to justify to you why they don't agree that something they are currently using should not be deprecated.

[xibz]

@sol-duara, I think we are talking past each other.

You keep asking me to justify deployment and targetRollout.

I keep asking why service.deployed should remain alongside them.

Those are different questions.

I understand your position that my proposal must justify itself. That is fine.

But if your position is that service.deployed should not be deprecated, then I need to understand what unique thing it represents.

So I am asking a very simple question:

What can service.deployed express that deployment.finished cannot?

Not why your company uses it.

Not how your workflow works.

Not whether my proposal is valuable.

Just that one thing.

If the answer is, “Nothing; we simply prefer the existing event,” then we can discuss compatibility and migration concerns.

If the answer is, “It represents a different concept,” then please define that concept.

That is the question I have been trying to get answered.

You may feel that this is argumentative, but all I am trying to determine is whether service.deployed should be deprecated.

To make that decision, I need to understand the semantic distinction. Unless a distinct semantic capability is identified, the proposal will continue to deprecate service.deployed to avoid preserving overlapping and ambiguous event models.

We are asking YOU to prove your targeted rollout system has value over what it is existing.

What exists is conflated which has been my consistent point. I am saying it needs to be separated into

deployment: the what
targetRollout: the where

It's also defined in _defs and if your definition, once I have it, doesnt work, we can either tweak it or keep service.deployed.

If you do not want to provide that definition, I will wait for the other maintainers to weigh in. If the maintainer consensus is to retain service.deployed, I am completely fine with that outcome.

[xibz]

And to be clear, I don’t believe I’ve personally attacked you at any point. If something I wrote came across that way, can you quote the specific language you’re referring to?

I’ll make an effort to avoid that framing going forward. I have deliberately tried to keep my comments focused on the proposal and not on you personally.

[sol-duara]

@xibz To be equally clear, you began attacking when I disagreed with your view about deprecation. Demanding that I prove that what was there should be allowed to stay when it is already there. It is your PR, you have the burden of proof.

My suggestion was simple. Do not deprecate something for something unproven based on one point of view. Better to leave it; run both in parallel and let the community choose before you pick which to deprecate. Head-to-head, would you accept the community choosing to keep what is there over your suggested path? I also asked for information about the vision that you have that makes you believe that every consumer needs that information. How does your whole system work, or are you targeting things that don't work for you personally? Maybe I missed the incident where the community came forward and asked for a change that could have happened. I, personally, don't believe that deprecation should be considered without a proven solution in place. Just cautious. Would you have a problem letting the community decide which one they would like to keep? (And why can't there be more than one way to do things?) And, it is not clear how the change benefits a small company running a few services but actively building.

If there is a document somewhere that outlines your vision, that would be useful. You are saying that the consumers need the information, but you are also the guy who proved that they probably only need a reference to the location where the data they want is stored; why bloat an event with it? We follow the principles that you already established in your own Spinnaker work.

[xibz]

Can you quote or link to the specific comment where you believe I began attacking you?

I’m happy to correct my tone if I crossed that line, but I need to understand which language you are referring to. I have deliberately tried to keep my comments focused on the proposal, the deprecation decision, and the semantic distinction between the events.

Also, defining something is not the same as proving it. Those are being conflated.

I am asking you to define what service.deployed means so I can evaluate whether the proposed model has a gap. That is not a request for you to prove my proposal. I defined my concepts in _def, and there seems to be room for ambiguity, so instead of keeping service.deployed, I opted to deprecate it. For example, in one of the SIGs when I mentioned these two event subjects, someone said "what will become of service.deployed" that's the ambiguity I am trying to prevent

So, to separate the two issues:

Do you feel attacked by the disagreement, or is there specific language you believe constitutes a personal attack?

[xibz]

When you say “proven solution,” what specifically do you mean?

The current model is exactly what I am questioning. My position is that it conflates deployment orchestration with the resulting service entity. The proposal introduces deployment and targetRollout to separate those concerns, and both concepts are defined in _defs.

So what, specifically, remains unproven?

• The semantics?
• The modeling?
• The migration path?
• Adoption?
• Something else?

“Proven solution” implies that some objective criterion is being applied, but I do not yet understand what that criterion is.

From my perspective, this is fundamentally a modeling discussion. The current CD model treats the relationship between deployment operations and resulting entities differently from the equivalent CI relationship between builds and artifacts. This proposal attempts to correct that inconsistency. Whether it does so successfully is exactly what we should evaluate.

Similarly, I do not understand the “one point of view” characterization. I am not arguing that deployment is preferable merely because I like it. I am arguing that service.deployed appears to combine an orchestration predicate with an entity predicate, while deployment and targetRollout model those concerns separately. If that analysis is wrong, please identify where the model is incorrect or what semantic capability is lost.

Community feedback can help validate use cases, migration concerns, and likely adoption. It cannot resolve the underlying semantic question until the alternatives are actually defined. The question is whether service.deployed and deployment.finished represent distinct facts. If they do, the distinction needs to be articulated. Only then can the community meaningfully evaluate which use cases require each fact.

I am also concerned by the argument that there can simply be multiple ways to represent the same thing. A specification can support multiple valid workflows, but allowing semantically interchangeable events without clear selection criteria creates ambiguity for both producers and consumers. That ambiguity will inevitably become an end-user interoperability problem.

The vision here is straightforward: service events should not simultaneously represent both the lifecycle of an entity and the orchestration operation that produced it. Those concerns should be separated, just as CI separates build operations from resulting artifacts.

I am entirely open to the community helping determine the best model. But this discussion began with a narrow question: if the new model supersedes the role currently played by service.deployed, why would we not deprecate it? The answer was that the events represent different things, so I have spent this discussion trying to understand and pressure-test that distinction.

If the actual position is instead that the specification is comfortable with the conflation, or comfortable providing multiple events for the same fact, that is a position we can evaluate directly. But it is materially different from saying that service.deployed preserves a distinct semantic capability.

At this point, I need one of two things from the community:

1. A concrete definition of the distinct fact represented by service.deployed that is not represented by the proposed model; or
2. An acknowledgment that the objection is based on compatibility, adoption, or a preference for allowing multiple representations, not on a semantic distinction.

Either answer gives us something concrete to evaluate. What has been difficult is spending this much time pursuing a purported semantic distinction that still has not been defined.

[sol-duara]

The CDEvents website (https://cdevents.dev/) says:

Embrace the freedom to pick and choose as you will, empower your builds with broad reusability and free your Continuous Delivery approach from vendor lock-in.

With CDEvents, you have the freedom to adopt the Continuous Delivery approach that your product needs, with the flexibility to incorporate whatever tooling best suits your specific requirements.

CDEvents is a common specification for Continuous Delivery events, enabling interoperability in the complete software production ecosystem.

It goes on to say:

CDEvents builds upon the work done by the CDF to set out best practices in Continuous Delivery, to define a common language for CI/CD ecosystem events, permitting the decoupling of pipeline descriptions from physical implementations...

From my perspective, this describes an open specification. It describes a common language that enables interoperability between independently developed systems. It does not describe a bespoke architecture that dictates how consumers must interpret events or how implementations must be structured internally.

That is why I am concerned by the direction you are suggesting. The discussion appears to move beyond defining a common vocabulary and toward requiring implementations to justify themselves against a single modeling philosophy. The burden shifts from "can these systems interoperate?" to "does your use case intersect with my model?" Those are very different questions.

My concern is not about one proposal. Communities thrive on experimentation. My concern is about governance. An open specification should create room for multiple approaches to coexist as long as they remain interoperable. It should not gradually narrow into a specification where one architectural viewpoint becomes the required viewpoint for everyone else.

If we are building a common language, then independent implementations should be free to innovate without first demonstrating that they fit a preferred execution model. If, instead, we are building a bespoke system with prescribed behaviors for emitters and consumers, then we should document that explicitly so implementers understand those constraints before they invest in adoption.

Similarly, if this is still an exploration of a modeling approach, I believe experimental events are exactly the right mechanism. They allow ideas to be demonstrated in practice, refined through experience, and adopted because the community finds them valuable; not because alternative approaches have been deprecated before consensus has been reached.

When conformance was introduced, I understood it to be an optional aid for implementations that wanted it. If conformance instead becomes a mechanism that can eliminate existing capabilities because they do not fit a particular architectural model, then it is no longer optional in practice. It becomes a requirement on every implementation, including those that never intended to adopt that model.

If I have misunderstood the intent of the project, I sincerely apologize. But if CDEvents is intended to remain an open interoperability specification, I hope we are careful not to unintentionally optimize it around a single worldview. The strength of an open standard is that it allows many approaches to coexist. Once we begin requiring everyone to think the same way, we are no longer maximizing interoperability; we are standardizing an architecture.

If, however, the project's intent is to prescribe that architecture, then we will simply have different goals. In that case, we would fork the specification and continue building around the principle that interoperability should not require conformance to a single implementation model. 

[xibz]

@sol-duara this is not the proposal.

open a slack discussion