A contrary-to-duty (CTD) obligation is a secondary, conditional duty that is triggered specifically by the violation of a primary obligation. It defines the remedial or fallback normative state that arises in non-ideal scenarios, such as the duty to compensate for a breach of contract or to apologize for a transgression. CTD structures are essential for modeling realistic legal and ethical systems where violations occur but do not collapse the normative framework.
Glossary
Contrary-to-Duty (CTD) Obligation

What is Contrary-to-Duty (CTD) Obligation?
A conditional obligation that specifies what an agent must do when a primary duty has been violated, representing the normative rules governing non-ideal compliance situations.
CTD obligations are the central puzzle in Chisholm's Paradox, which demonstrates that Standard Deontic Logic (SDL) cannot consistently represent these conditional fallback duties without generating logical contradictions. Formal solutions require moving beyond classical modal logic to frameworks like defeasible deontic logic, input/output logic, or temporal logics that can properly sequence the primary duty, its violation, and the resulting secondary obligation without entailing that the violation itself is obligatory.
Core Characteristics of CTD Obligations
Contrary-to-Duty (CTD) obligations are the conditional rules that govern non-ideal scenarios, specifying what an agent must do after a primary duty has been violated. They are the essential mechanism for modeling realistic, fault-tolerant normative systems.
The Conditional Structure
A CTD obligation is a secondary norm triggered by the breach of a primary norm. Its logical form is a conditional: 'If primary duty X is violated, then secondary duty Y becomes active.' This structure distinguishes it from an absolute, unconditional obligation. It represents a normative fallback, ensuring the system has a defined legal state even when compliance fails. For example, a contract might state: 'The goods shall be delivered by Friday (primary). If delivery is late, a penalty of 2% per day shall be paid (CTD).'
Resolution of Chisholm's Paradox
CTD structures are the direct solution to Chisholm's Paradox, which showed that Standard Deontic Logic (SDL) cannot consistently model these scenarios. The paradox arises from four intuitively consistent sentences that lead to a contradiction in SDL:
- It ought to be that Jones helps his neighbors.
- It ought to be that if he helps, he tells them.
- If he doesn't help, he ought not to tell them.
- Jones doesn't help. CTD logics resolve this by treating the third sentence as a conditional obligation that only activates upon the violation of the first, rather than a material implication.
Temporal and Stateful Nature
Unlike static, atemporal norms, CTD obligations are inherently dynamic and temporal. They model a state transition from an ideal world to a sub-ideal world. The activation of a CTD obligation marks a new normative state in a sequence. This requires a logical framework that can track the history of actions and violations, such as Dynamic Deontic Logic or the Deontic Event Calculus, to determine which obligations are currently in force.
Defeasibility and Exceptions
CTD obligations are a specific type of defeasible rule. They do not negate the primary obligation but rather supplement the normative system with an exception handler. In Defeasible Deontic Logic, a CTD rule is often modeled as an undercutting defeater to the conclusion that no sanction applies. The primary duty 'deliver on time' remains valid; the CTD duty 'pay a penalty' is a new, non-conflicting obligation that arises in the specific context of the violation.
Representation in LegalRuleML
The LegalRuleML standard provides explicit XML-based semantics for encoding CTD obligations. It uses a <penaltyStatement> element to define the compensatory duty that arises from the violation of a primary <obligation>. This structured markup allows legal reasoning systems to computationally distinguish between a primary duty, its violation, and the resulting secondary duty, enabling automated compliance checking and contract analysis across different platforms.
Computational Enforcement in Smart Contracts
In Deontic Smart Contracts, CTD obligations are implemented as explicit conditional logic. A primary obligation (e.g., 'transfer asset by deadline') is encoded with an if-violated clause that triggers a secondary function. This could be a penalty payment, a reversal of a transaction, or a notification to an arbitrator. The deterministic nature of code makes the execution of CTD rules automatic and unavoidable, providing a powerful mechanism for on-chain normative fallback without human intervention.
Frequently Asked Questions
Explore the core concepts behind contrary-to-duty obligations, the conditional duties that arise when primary rules are violated, and how they are modeled in formal deontic logic and legal reasoning systems.
A contrary-to-duty (CTD) obligation is a conditional normative requirement that is activated specifically when a primary duty has been violated. It represents the 'fallback' rule that tells an agent what they ought to do in a non-ideal, non-compliant situation. The classic example, from Chisholm's Paradox, is: (1) You ought to go to the assistance of your neighbors; (2) If you go, you ought to tell them you are coming; (3) If you don't go, you ought not tell them you are coming; (4) You don't go. The CTD obligation here is the duty in (3)—it only becomes operative because the primary duty in (1) was breached. In legal reasoning systems, CTD structures model remedial obligations, penalty clauses, and cure periods that govern real-world compliance scenarios where violations are anticipated and managed rather than simply declared impossible.
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.
Related Terms
Explore the formal frameworks and paradoxes that define normative reasoning, essential for engineers building systems that handle obligations, permissions, and prohibitions.
Normative Conflict Resolution
The algorithmic detection and reconciliation of contradictory rules, a core challenge when a primary and a CTD obligation appear to conflict. Resolution strategies are formalized as meta-rules:
- Lex Superior: The norm from a higher authority prevails.
- Lex Specialis: The more specific norm overrides the general one.
- Lex Posterior: The later-enacted norm takes precedence. In the context of CTD obligations, the secondary duty is typically treated as a lex specialis exception to the general primary rule, activated only upon the specific condition of violation. This prevents a normative deadlock.

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