Obligation Lifecycle and Deadline Risk

1. The real problem: a date alone is not an obligation

A sentence such as “send the signed estimate by Friday” becomes trackable only when it is bound to exact source evidence, an owner, a counterparty, explicit due semantics and closure evidence. This lesson builds Obligation Lifecycle & Deadline-Risk Register v1 so that date, lifecycle state and business evidence remain separate.

2. Lesson boundary and owned artifact

Each obligation records at least an obligation_id, source_ref, commitment text, owner, counterparty, creation time, due date/time, timezone or all-day flag, status, blocker, risk window/level, completion evidence, supersession link and recheck. Opportunity Dossier belongs to PLN-004; Notification Routing belongs to PLN-006.

3. Bind the source before calculating risk

An obligation without a source_ref is not auditable. The record must point back to the exact synthetic message, meeting note or other bounded evidence that created the commitment. A downstream summary or reminder is not a substitute for the original source binding.

4. Timed due and all-day due are different semantics

A due_at value denotes a specific instant and needs a valid timezone or offset for reliable interpretation. An all-day obligation can use due_date with no time component. Blindly converting an all-day date to local midnight can invent a deadline that was never stated, so the register must encode the semantic type explicitly.

5. What RFC 5545 establishes—and what it does not

RFC 5545 defines VTODO for an action-item or assignment and permits DUE or DURATION under stated constraints; it also defines STATUS and COMPLETED properties. These are calendar-standard semantics, not proof that a real business obligation was fulfilled.

6. Lifecycle states need independent meanings

The core states here are ACTIVE, BLOCKED, COMPLETED, CANCELED and SUPERSEDED. BLOCKED means the obligation still exists but a dependency prevents progress. SUPERSEDED means an older record has been replaced and must not remain active beside its successor. COMPLETED is invalid without closure evidence.

7. BLOCKED does not remove deadline risk

If an estimate is waiting for legal review, the obligation is still open. Record the dependency in blocked_by, preserve the due semantics, and continue to derive bounded risk. The register must show both the dependency and the approaching or missed deadline.

8. Derive the risk window from due semantics, not the reverse

risk_window and risk_level are MAKNOW design parameters. First establish the due semantics; then derive a bounded risk from time remaining, lifecycle state and blockers. If timezone or due interpretation is incomplete, do not guess a risk label: preserve UNKNOWN/REVIEW_REQUIRED.

9. Overdue requires an interpretable due value

When a valid due instant has passed while the obligation is still ACTIVE or BLOCKED, the record may be marked overdue. If a timed due value lacks its timezone, a definitive overdue claim is not defensible. Record the ambiguity first and set a finite recheck/review path.

10. Completion evidence is required for closure

A sent reminder, a synchronized calendar item or successful transport is not fulfillment evidence. COMPLETED requires evidence such as a signed-file receipt, accepted filing, approved record or equivalent synthetic proof, with a compatible completed_at value. Otherwise the decision remains REVIEW_REQUIRED.

11. Cancellation also requires an authorized closure reason

CANCELED is not an accidental failure or a deleted row. Record a canceled_reason and traceable authority for closure. A vague “do not do it anymore” appearing only in an untraceable summary is not enough for definitive cancellation.

12. Supersession must preserve an auditable chain

When a deadline is revised, do not overwrite the old record. Mark the predecessor SUPERSEDED, link superseded_by to the successor, advance sequence/version and keep exactly one successor ACTIVE. This preserves history and prevents two active deadlines for one commitment.

13. Worked example: Friday plus legal review

A client says “send the signed estimate by Friday.” The source has a local timestamp, the owner works in another timezone and a later message says legal review is pending. The bounded result is BLOCKED_RISK: source, owner/counterparty and due semantics are explicit; the blocker is active; completion evidence is absent; and a recheck is scheduled before the deadline. A reminder does not complete the obligation.

14. Deterministic failure probes

Three shortcuts must fail: (1) timed due without a timezone → REVIEW_REQUIRED; (2) status=COMPLETED without fulfillment evidence → closure rejected; (3) a superseded chain with both predecessor and successor ACTIVE → conflict. A fourth mutation moves the due time earlier while keeping notification history unchanged, forcing deadline risk to be recomputed from due evidence.

15. Transfer: an all-day filing with a revised deadline

The filing obligation contains only a due_date and is explicitly all-day, so do not invent a time-of-day timezone. A later authoritative message revises the deadline. Preserve the original record as SUPERSEDED, create the revised record as ACTIVE, and prove that only one active successor remains. Recompute semantics, risk and lifecycle state from the changed evidence instead of copying the baseline decision.