A contrary-to-duty obligation (CTD) is a deontic logic construct that specifies what an agent is obligated to do after violating a primary obligation. It models the normative consequence of a breach, such as a contractual clause stating that if a payment is late, a penalty fee must be paid. This structure is essential for representing realistic legal and compliance scenarios where ideal behavior fails.
Glossary
Contrary-to-Duty Obligation

What is Contrary-to-Duty Obligation?
A secondary obligation triggered by the violation of a primary duty, representing a core challenge in modeling realistic normative reasoning.
CTD structures create the Chisholm Paradox, a famous challenge in formal deontic logic where intuitive natural-language obligations lead to contradictions when naively formalized. Resolving this paradox requires sophisticated non-monotonic logic and defeasible reasoning systems that can handle the temporal and conditional nature of secondary duties without collapsing into logical inconsistency.
Core Characteristics of CTD Obligations
A Contrary-to-Duty (CTD) obligation is a secondary duty that activates precisely upon the violation of a primary duty, forming the logical backbone for modeling remedial clauses, penalties, and fallback procedures in legal and contractual AI systems.
The Primary-Secondary Structure
A CTD obligation is defined by its conditional trigger: the breach of a primary norm. The structure is a conditional sentence where the antecedent is a violation. For example: 'You ought to keep the gate closed. If you leave it open, you ought to post a warning sign.' The secondary obligation to post a sign only becomes active in the sub-ideal world where the gate is left open. This creates a temporal and logical dependency chain that standard monotonic logics struggle to represent without contradiction.
The Chisholm Paradox
The classic illustration of CTD reasoning, formulated by Roderick Chisholm in 1963, exposes the inadequacy of Standard Deontic Logic (SDL). The paradox consists of four intuitively consistent sentences:
- It ought to be that Jones goes to assist his neighbors.
- It ought to be that if he goes, he tells them he is coming.
- If he does not go, then he ought not to tell them he is coming.
- Jones does not go. When formalized in SDL, this set derives a logical contradiction, proving that a more expressive logic—one capable of handling defeasible conditionals—is required for legal AI.
Temporal Ordering of Violations
CTD obligations are inherently time-bound. The primary duty exists in an ideal temporal state, while the secondary duty exists in a sub-ideal, future state. For instance, a contract clause stating 'The Buyer shall pay by Day 30. If payment is late, the Buyer shall pay 2% interest per month' encodes a clear temporal sequence. A legal reasoning engine must model this discrete state transition—from the ideal world to the violation world—to correctly activate the interest obligation only after Day 30 has passed without payment.
Nested and Iterated CTDs
Real-world legal instruments often contain recursive contrary-to-duty chains. A primary obligation may have a secondary remedy, which itself has a tertiary fallback if the remedy is also breached. For example:
- Primary: File tax return by April 15.
- Secondary (CTD1): If late, file by October 15 with a penalty.
- Tertiary (CTD2): If the extended deadline is also missed, pay an additional failure-to-file fee. Modeling these iterated preference structures requires a logic that can handle multiple layers of sub-ideal worlds without collapsing into inconsistency.
Compensatory vs. Punitive CTDs
CTD obligations can be classified by their teleological function within a normative system:
- Compensatory CTDs: Aim to restore the counterparty to the position they would have been in had the primary duty been performed. Example: 'If goods are defective, the Seller shall repair or replace them.'
- Punitive CTDs: Impose a sanction that goes beyond mere restoration to deter non-performance. Example: 'If the non-compete is breached, the Employee shall pay liquidated damages of $50,000.' Distinguishing these types is critical for automated damages calculation and remedy selection.
Formalization in Deontic Logic
CTDs are formally captured using a dyadic deontic operator O(B|A), read as 'It ought to be that B, given A.' The violation condition A represents the contrary-to-duty context. This contrasts with the monadic O(A) of Standard Deontic Logic. Modern approaches use:
- Preference-based semantics: Ranking possible worlds by their ideality, where CTD obligations hold in the best worlds among those where the violation occurs.
- Input/Output Logic: Treating norms as ordered pairs (antecedent, consequent) and defining operations for their detachment and iteration without logical explosion.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Frequently Asked Questions
Explore the core concepts of contrary-to-duty obligations, a critical deontic logic construct for modeling realistic legal and contractual compliance scenarios where secondary duties arise after a primary violation.
A contrary-to-duty obligation (CTD) is a deontic logic construct that specifies what an agent is obligated to do specifically after violating a primary obligation. It models the secondary, remedial duties that arise in non-ideal compliance scenarios. For example, if a primary obligation states 'You must not damage property,' a CTD obligation would be 'If you damage property, you must pay restitution.' This structure is essential for realistic legal modeling because real-world normative systems are not just about ideal behavior; they are predominantly about managing violations. CTD obligations create a conditional chain where the antecedent is the breach of a prior duty, and the consequent is a new, remedial duty. This allows AI systems to reason about penalties, cure periods, and mitigation requirements in contracts without collapsing into logical contradiction when a primary rule is broken.
Related Terms
Explore the formal mechanisms and logical structures used to model, detect, and resolve contradictions in legal and contractual rule systems, with a focus on the deontic challenges posed by contrary-to-duty scenarios.
Deontic Conflict Detection
The algorithmic process of identifying contradictory obligations, permissions, or prohibitions within a normative corpus. A direct collision between a mandatory rule and a prohibitive rule is the most common trigger. Contrary-to-duty obligations represent a specific, temporally-layered subtype of conflict where a secondary duty activates only upon the violation of a primary one.
Defeasible Reasoning
A mode of logical inference where a conclusion can be retracted in the face of new, contradictory evidence or superior rules. This is the foundational mechanism for handling contrary-to-duty obligations, as the initial conclusion that a primary duty was violated must be defeasible to allow the secondary duty to take effect without causing logical explosion.
Non-Monotonic Logic
A formal logic system where adding new premises can invalidate previously valid conclusions. Essential for modeling contrary-to-duty obligations because the activation of a secondary duty (the new premise) must override the conclusion that the agent is simply in a state of violation, a property classical monotonic logic cannot support.
Normative Exception Handling
The systematic mechanism by which a general rule is suspended or overridden by a more specific exception. A contrary-to-duty obligation is a canonical example of a temporal exception: the primary duty applies until its violation condition is met, at which point the exception handler activates the secondary duty.
Deontic Default Theory
An extension of default logic that incorporates deontic modalities, allowing for the formal representation of prima facie obligations. This framework is uniquely suited to model contrary-to-duty obligations as default rules that are defeated by the specific exception of their own violation, triggering a new default obligation.
Normative Belief Revision
The process of rationally changing a set of legal rules to incorporate a new rule while maintaining consistency, often guided by the AGM postulates. When a contrary-to-duty obligation is triggered, the system must revise its belief set to remove the violated primary obligation and add the secondary one without introducing contradictions.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us