HCS treats a team as a Human Cooperation System: a living system of people, expectations, and agreements. Instead of starting from process or tooling, HCS starts from needs and conditions:

• Can people speak honestly without being punished?
• Do they share a realistic picture of constraints and trade-offs?
• Is there clarity about what "good cooperation" looks like here?

The model provides a structured way to diagnose where cooperation is breaking down and to design better conditions and practices.

CDS focuses on the space where most projects quietly fail:
what people think they’ve agreed to versus what the system can actually support.

It provides structures for:

• making assumptions explicit before they turn into disputes
• defining scope, constraints, and change tolerance
• separating intent from commitment
• revisiting agreements without blame when reality shifts

CDS is not a contract template or a delivery process. It is a design system for commitments — sitting between human cooperation (HCS) and execution (3SF).

CDS makes responsibility explicit before delivery begins — when change is still cheap and trust is still intact.

3SF is built for client–vendor software delivery, where product goals, contracts, and team reality often drift.

It focuses on three core relationships:

• Engagement – how client and vendor start working together.
• Delivery – how teams actually build and release.
• Value – how outcomes from the product loop back to decisions.

The framework helps you see where misunderstandings, misaligned incentives, or missing practices are likely to create problems – long before the project is "in trouble".

An analytical model for understanding how systems allocate constrained resources across competing structural demands — with diagnostic and comparative applications. TC has been applied to macroeconomic case studies and used to stress-test and revisit other models in the 3in3.dev ecosystem.

Published via GitHub and Zenodo. Includes the core model, formal definitions, historical case diagnostics, and stress-test experiments.

SDL is a design lens for thinking about systems before they solidify into frameworks, processes, or tools. It focuses on how systems are defined, bounded, and justified – especially in complex, human-centered work.

Instead of jumping to solutions, SDL helps you slow down and ask better questions:

• What problem does this system actually exist to address?
• Where are its boundaries – and what is explicitly out of scope?
• What assumptions are being made about people, incentives, and behavior?
• How could this system fail, be misused, or create unintended outcomes?

The lens is intentionally domain-agnostic. It can be applied to delivery frameworks, organizational models, AI-assisted workflows, governance mechanisms, or any system where legitimacy and accountability matter.

SDL is used to design, stress-test, and critique systems like HCS, CDS, and 3SF — not to replace them.