feat(cd): add changeWindow subject and events

[sol-duara]

Changes

Adds a changeWindow subject to the Continuous Deployment vocabulary, with created, opened, access, breached, modified, revoked and closed predicates.

A changeWindow is a bounded interval during which changes to a target are governed by a window policy. The window is the gate: these events report that a gate exists, when it is in force, and when it stops being in force.

Why a new subject

Window-governed change control is common and has no representation in the vocabulary. Organizations restrict when production may be touched, then need to demonstrate afterward that the restriction held.

environment.modified says a mutation happened. It cannot say whether that mutation was permitted, or whether a restriction was violated. Those are different audit facts, and the difference between them is the entire point of having windows at all.

Polarity

A window is either permissive — changes are allowed only inside it, as with a maintenance or deployment window — or restrictive, where changes are forbidden inside it, as with a freeze.

windowType carries which. An earlier draft enumerated maintenance, deployment, freeze and emergency, and that was reduced deliberately: those name why a window was created, and a motive does not change what a window does. An emergency window still grants passage, and calling it an emergency tells a consumer nothing it can route on. What varies between windows is polarity, so that is what windowType carries; the motive belongs in reason.

Because the audit reading of every event on this subject depends on polarity, windowType is present on all of them.

The gate and the passage are separate occurrences

This is the main structural decision in the proposal.

The window existing is one fact. A change arriving at the window and being let through, or not, is a different fact — and conflating them into a single event would make the subject describe two unrelated things.

• access reports a change presented to the window and the result. status carries that result, using the same values as the approval subject's closed event — approved, rejected, cancelled, expired — so a consumer handling authorization results handles both alike.
• breached is deliberately not an access result. It reports a change that took effect without passing the gate at all: nothing was presented and nothing was decided. Which changes constitute a breach depends on polarity — a change outside a permissive window is a breach, and a change inside a restrictive window is a breach.

An earlier shape had three separate predicates for passage, blocking and violation. Modelling the first two as one access predicate with a status enum follows the precedent already set by approval, which represents rejection as a status value rather than as a distinct event type.

How this relates to approval

The two compose rather than compete. approval covers an accountable authorization decision made by a responder whose decision could have gone differently. A change window is not that: it is a standing temporal condition, decided once when the window is created and thereafter true or false as a function of the clock. No responder decides per change.

A change may require both an approval and an open window, and each is its own occurrence. Reusing approval's status values on access is what keeps them consistent for consumers without merging the two concepts.

Design decisions

created and the operational lifecycle are both present, and that is intentional. Bringing a window into existence is an action someone performed at a time, with bounds they chose, and it is the receipt an auditor asks for first. It is separate from the window later becoming active, which is what opened reports.

modified carries the window's complete resulting state — the resulting notBefore, notAfter, windowType and target — rather than a list of what moved. A consumer reading a single modified event knows the window's current bounds without holding an earlier event to compare against. A field list would tell a consumer what changed but still require the earlier event to know what it changed to.

There is no deleted predicate. revoked and closed already account for a window ceasing to exist, and each says something a generic deletion would not: whether an actor cut the window short, or whether it simply ran out. A third terminal predicate would give producers two ways to report the same ending.

target carries a type alongside id and source, so consumers can route on the kind of resource governed, and so target references are shaped consistently across subjects. type is a free string — environment, cluster, service — rather than a closed enum.

change is reused unchanged from the existing change subject. No new common objects are introduced.

Out of scope

• Enforcement mechanism. How a window is enforced — credential checks, token issuance, control-plane gating — is producer behavior. These events are the record, and a consumer MUST NOT treat receiving one as authorization for anything.
• The authorization decision to create, amend, or override a window. approval covers accountable authorization decisions; see above for how a window differs.

Notes on this change

Event versions start at 0.1.0-draft.

schemas/_defs/ entries and x-cdevents-semantics are not included here. The predicate definitions this subject would need overlap with those already being added by #319 and with further subjects we are proposing; adding them here would collide. We will follow up with them once #319 lands.

Separately, and not addressed by this PR: the approval subject has schemas under schemas/ but no vocabulary documentation in any of the stage .md files, so there is no anchor to link to. This PR names it in prose rather than linking. Happy to open a separate issue for that if useful.

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 — no new concept is introduced; this applies existing vocabulary patterns and reuses approval's status values
• Have the JSON schemas been updated if the specification changed
• Has spec version and event versions been updated according to the versioning policy — new events start at 0.1.0-draft; the spec version is unchanged
• Meets the CDEvents contributor standards