[Anchor Proposal]: Design by Contract

[rehsack]

Proposed Term

Design by Contract (DbC)

Context

A software-correctness approach devised by Bertrand Meyer for the Eiffel language (1986). Components interact via formal contracts: preconditions (the caller must satisfy), postconditions (the supplier guarantees), and class invariants (always hold). It assigns blame precisely when a contract is violated and is the formal underpinning of the Liskov Substitution Principle (a subtype may weaken preconditions and strengthen postconditions, never the reverse).

Fits design-principles; relatives in the catalog: solid-lsp, postels-law, property-based-testing, cohesion-criteria.

Source: Bertrand Meyer, Object-Oriented Software Construction (1988/1997).

LLM Activation Test Result

Model: Claude (Opus 4.8)
Prompt: "What concepts do you associate with 'Design by Contract'?"
Response: Preconditions, postconditions, invariants; caller/supplier obligations and benefits; "contract" metaphor; Eiffel and Bertrand Meyer; assertion-based correctness; closely tied to the Liskov Substitution Principle and to assertion/require/ensure constructs. Rich, consistent, strongly attributable activation.

Pre-submission Checklist

• I have searched existing anchors and this term is not already included
• This term refers to a well-established concept (not something I invented)

[JensGrote]

(German version below)

Assessment: Strong support — foundational design principle with dense prior

Evaluation against the four quality criteria

Criterion	Result	Evidence
Precise	✅	Single canonical source (Bertrand Meyer, Object-Oriented Software Construction, 1988/1997). Formal triple: preconditions, postconditions, invariants. Unambiguous.
Rich	✅	Activates: caller/supplier obligations, blame assignment on violation, Liskov Substitution Principle (formal underpinning), assertion-based correctness, Eiffel's require/ensure/invariant, defensive programming contrast, fail-fast semantics. Deeply interconnected.
Consistent	✅	The LLM activation test confirms strong, consistent activation. Every major model knows DbC — it's CS curriculum standard material.
Attributable	✅	Bertrand Meyer, Eiffel language (1986), OOSC (1988/1997). Single, clearly attributed origin.

Training-data density assessment

Applying the training-data-vs-practice lens:

Does naming the anchor change the output? Strongly yes. Ask a model "validate input parameters" without DbC and you get defensive programming (null checks, try/catch, input sanitization). Name "Design by Contract" and the output shifts to precondition/postcondition/invariant thinking with explicit caller vs. supplier blame. The framing change is structural — not cosmetic.

Silent substitution risk: Negligible. DbC is a unique, well-delimited concept. There is no "nearby" concept the model would silently substitute. The formal triple (pre/post/invariant) is unambiguous — no model will confuse it with, say, interface contracts in Java or API contracts in the REST sense.

Confabulation risk: Negligible. The concept has a closed, well-defined structure (the formal triple + blame semantics + LSP connection). Models cannot plausibly invent extra dimensions. Meyer's own writing is dense in the corpus.

Cross-model portability: High. DbC appears in CS textbooks globally, in Eiffel documentation, in OOSC (one of the most-cited SE books), in Java/C# assertion frameworks, and in every LSP explanation. This is a ★★★ anchor — fires reliably on weak and strong models alike.

Verdict: Fully viable. One of the densest, most stable concepts in the SE training corpus. No viability concerns.

Catalog fit and relationships

The proposer correctly identifies the relatives: solid-lsp, postels-law, property-based-testing, cohesion-criteria. I would add:

• tdd-hamburg-style (contract) — DbC's pre/postconditions map directly to the "arrange/assert" structure of tests. TDD Hamburg Style's emphasis on testing pure operations (IOSP) is essentially verifying contracts.
• Tension with postels-law: This is worth noting in the anchor. Postel's Law says "be liberal in what you accept" — DbC says "if the precondition is violated, the caller is at fault, fail immediately." These are complementary but tension-laden: Postel for protocol/API boundaries, DbC for internal module contracts. The anchor should acknowledge this.

Structural connection to our Structural Coupling Contract framework (#518)

Design by Contract is the formal foundation of what we model as "Structural Coupling Contracts" between agents and MCP tools. Our contracts define:

• Preconditions (what the caller must provide)
• Postconditions (what the tool guarantees)
• Invariants (what always holds)

This is literally Meyer's triple applied to agent-tool interfaces. The anchor would strengthen the theoretical grounding of the entire contracts layer in this project.

Recommendation

Strong support. This is a well-established, richly activating anchor that fills a gap — the project has postels-law and solid-lsp but not the formal correctness framework that underpins both. Category: design-principles.

@rehsack — I'd encourage you to open a PR for this. Given the natural tension with postels-law, a brief note in the anchor's description about their complementary scope (DbC for internal contracts, Postel for external protocol boundaries) would add value.

---

Deutsche Version

Bewertung: Starke Unterstützung — fundamentales Designprinzip mit dichter Prior

Bewertung gegen die vier Qualitätskriterien

Kriterium	Ergebnis	Evidenz
Precise	✅	Einzelne kanonische Quelle (Bertrand Meyer, Object-Oriented Software Construction, 1988/1997). Formales Triple: Preconditions, Postconditions, Invarianten. Eindeutig.
Rich	✅	Aktiviert: Caller/Supplier-Verpflichtungen, Schuldzuweisung bei Verletzung, Liskov Substitution Principle (formale Grundlage), Assertion-basierte Korrektheit, Eiffels require/ensure/invariant, Kontrast zu defensiver Programmierung, Fail-Fast-Semantik. Tief vernetzt.
Consistent	✅	Der LLM Activation Test bestätigt starke, konsistente Aktivierung. Jedes größere Modell kennt DbC — CS-Curriculum-Standardmaterial.
Attributable	✅	Bertrand Meyer, Eiffel (1986), OOSC (1988/1997). Einzelner, klar zugeordneter Ursprung.

Trainingsdaten-Dichte-Bewertung

Anwendung der training-data-vs-practice-Linse:

Ändert das Benennen des Anchors die Ausgabe? Stark ja. Frag ein Modell "validiere Input-Parameter" ohne DbC und du bekommst defensive Programmierung (Null-Checks, Try/Catch, Input-Sanitization). Nenne "Design by Contract" und die Ausgabe wechselt zu Precondition/Postcondition/Invariant-Denken mit expliziter Caller-vs-Supplier-Schuldzuweisung. Der Framing-Wechsel ist strukturell — nicht kosmetisch.

Silent-Substitution-Risiko: Vernachlässigbar. DbC ist ein einzigartiges, gut abgegrenztes Konzept. Es gibt kein "benachbartes" Konzept, das das Modell silent substituieren würde. Das formale Triple (Pre/Post/Invariant) ist eindeutig — kein Modell verwechselt es mit Interface-Contracts in Java oder API-Contracts im REST-Sinne.

Confabulation-Risiko: Vernachlässigbar. Das Konzept hat eine geschlossene, wohldefinierte Struktur (formales Triple + Blame-Semantik + LSP-Verbindung). Modelle können keine plausiblen Extra-Dimensionen erfinden. Meyers eigenes Schreiben ist dicht im Korpus.

Cross-Model-Portabilität: Hoch. DbC erscheint in CS-Lehrbüchern weltweit, in Eiffel-Dokumentation, in OOSC (eines der meistzitierten SE-Bücher), in Java/C#-Assertion-Frameworks und in jeder LSP-Erklärung. Das ist ein ★★★-Anchor — feuert zuverlässig auf schwachen und starken Modellen gleichermaßen.

Urteil: Vollständig viable. Eines der dichtesten, stabilsten Konzepte im SE-Trainingskorpus. Keine Viability-Bedenken.

Katalog-Passung und Beziehungen

Der Vorschlagende identifiziert korrekt die Verwandten: solid-lsp, postels-law, property-based-testing, cohesion-criteria. Ich würde ergänzen:

• tdd-hamburg-style (Contract) — DbCs Pre/Postconditions bilden direkt auf die "Arrange/Assert"-Struktur von Tests ab. TDD Hamburg Styles Betonung des Testens reiner Operationen (IOSP) ist im Wesentlichen Contract-Verifikation.
• Spannung mit postels-law: Das ist im Anchor erwähnenswert. Postels Law sagt "sei liberal in dem was du akzeptierst" — DbC sagt "wenn die Precondition verletzt ist, hat der Caller Schuld, fail sofort." Diese sind komplementär aber spannungsgeladen: Postel für Protokoll/API-Grenzen, DbC für interne Modul-Contracts. Der Anchor sollte das anerkennen.

Strukturelle Verbindung zu unserem Structural Coupling Contract Framework (#518)

Design by Contract ist die formale Grundlage dessen, was wir als "Structural Coupling Contracts" zwischen Agenten und MCP-Tools modellieren. Unsere Contracts definieren:

• Preconditions (was der Caller liefern muss)
• Postconditions (was das Tool garantiert)
• Invarianten (was immer gilt)

Das ist buchstäblich Meyers Triple angewandt auf Agent-Tool-Interfaces. Der Anchor würde die theoretische Fundierung der gesamten Contract-Schicht in diesem Projekt stärken.

Empfehlung

Starke Unterstützung. Ein etablierter, reich aktivierender Anchor, der eine Lücke füllt — das Projekt hat postels-law und solid-lsp, aber nicht das formale Korrektheit-Framework das beide untermauert. Kategorie: design-principles.

@rehsack — Ich würde dich ermutigen, einen PR dafür zu öffnen. Angesichts der natürlichen Spannung mit postels-law würde eine kurze Notiz in der Anchor-Beschreibung über ihren komplementären Scope (DbC für interne Contracts, Postel für externe Protokollgrenzen) Mehrwert schaffen.