契約パターンが「活動の基本形（何をすべきか）」を定義するのに対し、文脈パターンはその基本形を「プロジェクト固有の事情（どうやるか）」に適応させる。Control（考慮すべきこと）とMechanism（利用するもの）を垂直方向に割り当てることで、基本ロジックを変えずに多様な環境へ適用できる。
スイムレーン（担当者別レーン）で活動を描くと、実行手段がハードコーディングされる。「この手作業をシステム化しよう」となるたびにプロセス図を描き直す必要があり、業務の柔軟性が失われる。また、業務ルールや制約が付箋・注釈として添えられるだけでは見落とされやすく、コンプライアンス違反の温床となる。
Activityを実行者（人や部署）の枠に閉じ込める表現。実行手段がハードコーディングされ、自動化などの変更に弱い。
業務ルールや制約が図の脇にテキストで添えられるだけ。システム化の際に見落とされやすく、ガバナンスが効かない。
契約パターンで定義した活動の基本形（左右）に対し、上部（Control）に要求・制約などの「考慮すべきこと」を、下部（Mechanism）にその事情下で「利用するもの」を接続し、プロジェクト固有の文脈を与えます。
スイムレーン（担当者別の横レーン）でプロセスを描くと、Activityが特定の「人」や「部署」に強く依存・固定されてしまいます。「この手作業をシステム化しよう」「別部署に委譲しよう」となった際、プロセス全体の図を大掛かりに描き直す必要があります。本来のビジネスロジック（何をすべきか）と、実行手段（誰がやるか）が密結合しているため、業務の柔軟性が失われます。
「100万円以上の決裁は部長承認が必要」といった重要な業務ルールや制約事項は、通常マニュアルなどの別紙に記載されます。プロセスの流れ（水平方向）にルールが明記されていないため、現場ではルールの存在が忘れられがちです。また、システム化する際にも「どの画面にどんなチェック（バリデーション）を入れるべきか」が漏れやすく、コンプライアンス違反の温床となります。
AbCでは、活動の基本形を定義する「契約パターン（水平方向）」に対し、それをプロジェクトごとの事情に適応させるための「垂直方向」のインタフェースを定義します。これらを活動の「文脈」として分離することで、汎用的なプロセスを多様な環境へ柔軟に適用可能にします。
これにより、「Activity自体の基本ロジック（契約）」を変えることなく、「Aプロジェクトでは厳格な法規制（上）と手作業（下）」「Bプロジェクトでは社内基準（上）とAI自動化（下）」といった事情（文脈）の違いを、ハンドルの付け替えだけで表現できます。