Calendar and Campaign Dependency Graphs

1. A calendar tells you when, not whether the launch is ready

Reaching 09:00 means a time trigger occurred. It does not prove that the required content version, derivative, approval, rights window, or channel handoff is satisfied. Time is one evidence dimension, never a substitute for dependency state.

2. The owned CON-013 boundary

CON-013 owns campaign/event identity, schedule revision, and the publication dependency graph. CON-011 owns localization semantics, CON-012 owns content/derivative lineage, and CON-010 owns public rollback evidence. Keeping these boundaries explicit prevents the calendar from becoming an ambiguous source of all authority.

3. UID and SEQUENCE have different jobs

In iCalendar, UID provides component identity while SEQUENCE identifies the revision sequence. The same UID with a newer sequence means an earlier dependency snapshot cannot be assumed current without reevaluation.

4. DTSTART and DTEND are time-window semantics only

DTSTART defines the event start and DTEND is the non-inclusive end for VEVENT when present. These fields do not prove approval, rights, or version compatibility. Calendar semantics are not campaign publication policy.

5. Normalize timezone-aware schedules to comparable instants

Moving a launch across time zones can change the local clock representation while preserving the intended absolute instant. Readiness must not rely on naive local-time string comparison; schedule evidence must be timezone-aware and normalizable.

6. Bind the dependency snapshot to the exact schedule revision

Each calendar revision should reference an exact snapshot of content version, derivative, locale, approval, rights window, and channel handoff. If the sequence changes but the snapshot still reflects the previous revision, the state is stale.

7. Keep edge types explicit: HARD versus RECOMMENDED

An unresolved HARD prerequisite blocks or waits the release. A missing RECOMMENDED dependency can produce a warning and may remain release-ready only when campaign policy explicitly permits it. Promoting an edge to HARD is a real policy change and requires recomputation.

8. Content and derivatives must align to the required version

If the campaign package requires version 22 but the Persian derivative still points to version 21, file existence is irrelevant. The dependency must expose a stale/version-mismatch state.

9. Approval must bind to the same artifact/revision

Approval for an older content version or different derivative is not current approval. approval_ref must trace to the active dependency snapshot; missing binding remains UNKNOWN/WAITING rather than being coerced into PASS.

10. A rights window may open after calendar start

If the event starts at 09:00 but the rights window starts at 10:00, reaching the calendar start does not create usage rights. The campaign remains blocked or waiting until the rights evidence becomes valid.

11. Channel handoff is a real dependency

Sending a package to a channel is not the same as receiving acknowledgement. If email, social, or CMS handoff acknowledgement is a HARD prerequisite and is missing, the campaign is not release-ready.

12. PROV is useful for traceable relationships

PROV-O provides Entity, Activity, Agent, and relations such as wasDerivedFrom for provenance. That vocabulary can trace dependency evidence, but it does not prescribe campaign critical-path logic or launch authorization.

13. Do not collapse typed states

READY, WAITING, BLOCKED, and STALE require explicit reasons. UNKNOWN is not READY, and one green badge is not a substitute for every evidence dimension. The decision must be reversible back to matrix rows.

14. Lab: eight fixtures and 64 assertions

The lab tests baseline readiness, a stale derivative, a closed rights window, unacknowledged handoff, a timezone move preserving the instant, a stale sequence snapshot, a missing recommended dependency, and a transfer that promotes that dependency to HARD. Eight independent outputs are checked per case.

15. Transfer: never copy the earlier decision

Move the launch to a new timezone-aware window, increment the event sequence, replace one derivative version, and promote one recommended dependency to HARD. Recompute readiness from the new snapshot; the previous decision is history, not an answer key.