AbC（Activity by Contract）の中核パターン。活動間の関係を「契約（Contract）」として明記し、事前条件（Input）と事後条件（Output）を明示することで、プロセスの信頼性と自動化適性を高める。
従来の「やることリスト（タスク連鎖型）」や「成果物介在型」では、なぜその活動が実行できるのか（事前条件）、何を生み出すのか（事後条件）が隠蔽される。担当者が変わるたびに品質がリセットされ、自動化への移行時に仕様が欠落する。
Activityを直接矢印で繋ぐ最も一般的な表現。処理の順序（Control Flow）のみを示します。
ActivityとActivityの間に、受け渡されるデータや成果物を明示する表現。データの流れ（Data Flow）に焦点を当てます。
Activityの「左のハンドル」には事前条件が、「右のハンドル」には事後条件が直接記載され、これが実行に必要な契約（Contract）となります。間に介在する成果物（Artifact）は、このインターフェース間で事前・事後条件を満たした「合意済みの確実な情報」として受け渡されます。
矢印でActivityを順番に繋ぐだけの表現は、単なる「やることリスト」の羅列に過ぎません。「なぜそのActivityが実行可能なのか」という前提条件や、「具体的にどんな状態を生み出すのか」という結果が完全に隠蔽されています。
Activity間に成果物（Artifact）を挟むことで情報の流れは可視化されます。本来、ここで授受される情報は「前工程が提供したい情報」ではなく**「後工程が必要とする情報」**であるべきです。しかし、成果物を単なる「モノ（データ）」として扱うと、品質や前提条件の合意が抜け落ちてしまいます。
AbC（Activity by Contract）は、これらの問題を根本から解決します。水平方向のつながりを単なる「順序」や「データ」ではなく、厳密な「契約（Contract）」として定義するからです。
もしあるActivityが失敗し、約束されたOutputを出せなかった場合、後続のActivityはInputが満たされないため明確に停止し、影響を受けます。このように、相互依存関係と責任の所在をはっきりと「握る」ことで、意味のない活動を排除し、プロセス全体が高い品質で自律的に動くようになります。