Obligation Lifecycle

The obligation exists in the contract text but has not yet become enforceable. This state is governed by temporal triggers and conditions precedent.

• Key Logic: The duty is legally defined but dormant.
• Example: A payment obligation that activates only upon 'delivery and acceptance of the software.'
• System Action: The engine monitors for the temporal trigger event; no performance is demanded yet.

All conditions precedent have been satisfied, and the duty is now due for performance. The effective date anchor has passed, and the obligation is legally binding.

• Key Logic: The promisor must perform within a defined duration.
• Example: A rent payment due on the 1st of each month following a grace period of 5 days.
• System Action: The deadline extraction module calculates the precise due date and initiates monitoring for breach.

The promisor has failed to perform the active duty by the specified deadline, and no cure has been effected within the applicable grace period. This state triggers secondary obligations.

• Key Logic: A temporal contradiction may arise if cure deadlines conflict with new obligations.
• Example: Failure to deliver a milestone by the sunset clause date, resulting in liquidated damages.
• System Action: The complex event processing engine detects the missed deadline and transitions the state, triggering a notice of default.

A temporary state entered after a breach where the promisor performs the original duty within a contractually defined cure period. This state prevents the obligation from terminating permanently.

• Key Logic: Performance is late but accepted; the breach is nullified retroactively.
• Example: Paying an overdue invoice within a 10-day cure window after receiving a default notice.
• System Action: The bitemporal model records both the late performance time and the original deadline to maintain a complete temporal audit trail.

The obligation has been completely and perfectly performed, releasing the promisor from the duty. This is a terminal state representing successful completion.

• Key Logic: The promisor is legally released; no further liability exists.
• Example: Full repayment of a loan principal plus interest by the maturity date.
• System Action: The obligation is archived in the temporal knowledge graph for historical point-in-time retrieval, but is removed from active monitoring queues.

The obligation terminates automatically due to the passage of time without breach, typically governed by a sunset clause or a condition subsequent. This is distinct from fulfillment.

• Key Logic: The right to demand performance vanishes by operation of law.
• Example: An unexercised stock option that expires after its 90-day post-termination exercise window.
• System Action: The temporal constraint satisfaction engine verifies that no dependent obligations remain active before finalizing the terminal state.

The formal computational model underlying the obligation lifecycle. A state machine defines a finite set of distinct states an obligation can occupy, the valid transitions between them, and the triggering conditions for each transition.

• States: pending, active, breached, fulfilled, waived, suspended
• Transitions: Rule-governed paths like active -> breached upon a missed deadline
• Determinism: Ensures an obligation cannot be in two contradictory states simultaneously

A specific event or condition that initiates a state transition within the obligation lifecycle. Triggers are the active mechanism that moves an obligation from one state to the next.

• Event-based: 'Upon delivery of the goods', the payment obligation transitions from pending to active
• Temporal-based: 'On January 1, 2025', a non-compete clause transitions from active to expired
• Conditional: 'If EBITDA falls below $10M', a covenant transitions to breached

The formal representation of normative concepts—obligation, permission, and prohibition—that define the legal character of each lifecycle state. Deontic logic provides the symbolic framework for reasoning about what an agent must do, may do, or must not do.

• Obligation: A duty that must be performed (e.g., pay rent)
• Permission: An allowed but not required action (e.g., early repayment)
• Prohibition: A forbidden action whose performance triggers a breached state

An architectural pattern that persists the obligation lifecycle as an append-only, immutable sequence of state-changing events. Instead of storing only the current state, every transition is recorded as a discrete event.

• Auditability: The complete history of an obligation is reconstructable at any point
• Temporal Queries: Replay events to determine the state of an obligation at any historical moment
• Non-Repudiation: The immutable event log serves as a cryptographically verifiable record

A logical inconsistency where an obligation's lifecycle contains conflicting state assertions. Detection of contradictions is critical for maintaining the integrity of automated contract management systems.

• Example: A payment obligation marked both fulfilled and breached for the same period
• Causes: Conflicting clause interpretations, data entry errors, or retroactive amendments
• Resolution: Requires formal temporal constraint satisfaction algorithms to reconcile

A database design pattern that tracks the obligation lifecycle along two independent time axes, essential for legal applications where the 'as-recorded' history differs from the 'real-world' history.

• Valid Time: When an obligation state is true in the real world (e.g., a breach occurred on March 1)
• Transaction Time: When the breach was recorded in the system (e.g., entered on March 5)
• Use Case: Correctly modeling a retroactive cure that voids a breach back to its original date