Engineered and Bounded Interdependence 2.3B.1

The Problem Cooperation Cannot Ignore

The sub-arc introduction (2.3B.0) named the structural gap that character and method cannot close at team scale. The Trader Principle established that cooperation is value-for-value (2.1.4). Independence established that judgment survives social pressure only when the team installs structural support for honest dissent (2.1.5). Disagreement-as-data and method-over-canon gave the team correction mechanisms — the steelman-first protocol, the error-friendly retro, the practice audit, the revision protocol (2.2.3, 2.2.4). All of this is real and necessary. None of it answers the structural question: On what terms, exactly, does each person participate — and what happens when someone needs to leave?

Most teams never answer that question explicitly. Roles accrete informally. Decision rights are assumed rather than published. Exit costs accumulate invisibly — the code only one person understands, the client relationship that cannot be transferred, the equity that vests only on the team's terms. The cooperation looks voluntary because it began voluntarily. But consent that is valid at entry and never re-examined is consent that degrades with every structural change the participant did not choose and cannot contest.

Consent theater is the result: the appearance of voluntary cooperation without the structural conditions that make consent genuine. A member agrees to join. She cannot inspect the actual decision rights. She cannot contest them. She cannot leave without forfeiting the work she built. She has not consented to the structure she is in — she has been conscripted into it by a process that looked like agreement.

This unit builds two structural tools to close the gap. Engineered interdependence — one of Resilient Objectivism's (RO) design patterns, constructed in Phase I (1.2.5) — makes the terms of cooperation visible by design. Bounded interdependence — also constructed in Phase I (1.2.6) — ensures that participation remains genuinely voluntary by defining the terms to join, stay, and leave.

Engineered Interdependence at Team Scale

Phase I defined engineered interdependence as the design discipline of structuring cooperative frameworks so that value is created jointly, incentives are aligned with fair dealing, commitments are credible, reciprocity is measurable, and the power that cooperation creates cannot be silently converted into leverage (1.2.5). At team scale, this translates into a concrete requirement: the team publishes the terms of its cooperation in a document that every member can read, contest, and verify.

Part of this design discipline's moral posture is inherited from Kelley's benevolence: an unproven teammate can rationally be treated as a potential source of value rather than a presumptive threat (1.2.5). Structure cannot manufacture that posture, but it can support it — a charter built on the presumption of good faith, with recourse held in reserve for when good faith fails, produces cooperation that holds better than one built on the presumption of exploitation and policed accordingly.

The team charter is that document. It is not a job description — job descriptions name activities. A charter names the structural terms of the relationship: who depends on whom, what each role decides, what each role does not decide, how roles interface, what quality standards govern the interfaces, and when the terms will be reviewed.

A functional team charter contains five elements.

Role map. Each role is defined with its scope — what decisions it makes, what it does not make, and to whom it reports or coordinates with. A scope is not a description of activities. It is a boundary. The structural function of the boundary is to prevent the ambiguity that becomes conflict and the conflict that becomes organizational scar tissue — unspoken resentments, consensus theater, decisions made informally to avoid the meeting where they would be contested.

Decision rights matrix. For each major decision type — hiring, budget, technical direction, process change — the matrix specifies who decides, who advises, who is consulted, and who is informed. This is not consensus. It is structural honesty about where authority actually rests. Decision rights that are implicit are decision rights that are contested. Contested rights become the hidden agenda of every meeting.

Interface specifications. Each handoff between roles specifies what is delivered, on what timeline, to what quality standard, what recourse exists if the deliverable is defective, and who maintains the specification if conditions change. Interfaces without specifications become Rorschach tests — each party sees what they need to see, and reality arrives as shock.

Consent validity checkpoints. Each member must be able to answer four questions: Do I understand what I am agreeing to? (capacity). Do I have access to the standards and decision rights I need? (information). Could I exit without losing the portable work I created? (absence of coercion). If the terms are violated, do I have meaningful remedies? (recourse). If any answer is no, the consent is structurally invalid. The cooperation may continue — but it is held together by inertia, not by agreement.

Review date. A charter is a working hypothesis about how cooperation should be structured. The review date — typically ninety days for a new team, annually for established ones — forces the team to test whether the charter still matches reality. A charter that has been published once and never reviewed is decoration. A charter that has been revised because reality deviated from design is a tool.

Bounded Interdependence at Team Scale

Engineered interdependence makes the terms visible. Bounded interdependence ensures the terms are not permanent and that exit does not require surrender.

Phase I defined bounded interdependence as the design discipline of ensuring that every cooperative framework maintains clean exit, meaningful recourse, and portable standing — so that participation remains genuinely voluntary, dependencies are reversible, and departure never destroys dignity (1.2.6). At team scale, this translates into three structures.

Entry criteria. What does someone need to know, have, or be able to do in order to join the team? These are onboarding prerequisites, not hiring criteria. They specify what knowledge is assumed, what tools are required, and what access is necessary to begin contributing. Published, testable, changeable. Entry criteria that are opaque or shifting create dependency on informal gatekeepers — the person who "knows how things really work" — and the organizational memory problem that follows when that person leaves.

Performance expectations. What does the team expect from each role, and how will it assess whether those expectations are met? Output standards, not activity lists. Measurement criteria, not vague culture values. Review cadence, not annual surprises. Expectations without measurement are invitations to informal negotiation. Measurement without published standards is capacity for arbitrary judgment. The consent validity checkpoint on information fails when the person being evaluated has no standards to appeal to — only the judgment of the evaluator.

Clean exit. The structural test of bounded interdependence. A clean exit specifies: handoff protocol (who takes over what, on what timeline, with what knowledge transfer), asset portability (what work is portable and what stays with the team, with explicit timelines for export), and reputation protection (what the team will say about the departing member's work, under what conditions, through what process).

Dependency power — the structural capacity to impose costs on another party's departure — is what bounded interdependence is designed to limit. A team that lets dependency power accumulate is not violating a member's entitlement; it is degrading its own cooperation model — trust erodes, the strongest members route around the team rather than through it, and negotiation stops being honest once one side cannot afford to walk away. When exit terms are published, reasonable, and enforced, the cooperation remains genuinely worth choosing throughout its duration — not merely at the moment of entry.

The Interface Map

The interface map is the team-level structural visibility tool — the equivalent of the personal data map (2.3A.2) at the individual level. It shows each role as a node, each dependency as a directed line (Role A depends on Role B for a specific deliverable or capability), the cost if that dependency breaks (output blocked, commitment missed, timeline extended), and the recovery time if the dependent role becomes unavailable.

The map makes visible what most teams leave invisible: which dependencies are fragile, which members are single points of failure, which interfaces are sequential versus parallel, and where backup capacity is needed. The structural function is diagnostic. A team that draws its interface map and finds three critical dependencies running through a single person has identified a fragility — and can harden it through documentation, cross-training, or redesign before the fragility becomes a crisis.

The interface map also connects to Phase I's strain condition on politics under concentrated institutional failure (1.3.9). At team scale, a cooperation structure that concentrates dependency without visibility is the smallest version of the load case Phase I identified: power accumulating not through intent but through structural architecture that no one audited. The map is the audit.

Payoff Alignment

Arc 1 established that trade is the moral foundation of cooperation — rational self-interest aligned with others' rational self-interest, expressed as value-for-value (2.1.4). The payoff table gives that principle structural enforcement.

A payoff table maps each role's contributions to the team's outcomes and specifies how recognition, compensation, and advancement track actual value creation. Input metrics name what the role produces. Output metrics name what the team produces. The mapping shows how the role's contribution connects to the team's result. Variance rules specify what happens when performance exceeds or falls below standard. The review cycle specifies when the mapping is reassessed.

The structural claim is not that every exchange can be measured to the penny. It is that the terms must be visible and the logic defensible. When compensation tracks negotiation skill rather than contribution, the person who contributes more and receives less is structurally captured — less able to leave, because the next team may offer the same opaque terms. When compensation tracks contribution through a published mapping, the team member can evaluate whether staying serves her rational interest. Payoff alignment does not eliminate power asymmetries. It makes them legible — and legibility is the precondition for contestation.

The Participation Test

The four questions of the participation test integrate everything this unit builds. For each member of the team:

Can they know the terms? Is the team charter published? Are the decision rights clear? Are the interfaces explicit? Are the performance expectations measurable?

Can they contest the terms? Is there a standing process for challenging the charter — a revision mechanism the team has agreed to use? Or does contestation depend on the informal willingness of whoever holds power?

Can they exit if unsatisfied? If they decide the terms are unacceptable, can they leave without losing the portable work they created? Are the exit costs transparent in advance?

Can they take their portable work with them? Can they export their data, their code contributions, their credentials? Or is the structure designed to retain them by making their work non-portable?

Each missing element identifies where coercive structure is hiding inside voluntary language. The test does not require perfection — it requires honesty. A team that runs the participation test and finds two members whose exit costs are invisible has not failed. It has diagnosed a structural condition that can be repaired. A team that never runs the test has no mechanism for detecting whether its cooperation is genuine.

What This Unit Ships

Three toolkits make the structural argument operational:

The team charter template (2.3B.1-1) structures role clarity, decision rights, interfaces, consent validity checkpoints, and review dates into a working document the team builds collaboratively.

Entry, exit, and portability terms (2.3B.1-2) specify what joining means, what leaving means, what is portable and what stays with the team, and how clean exit is actually structured — including handoff protocols, data portability, reference processes, and the legal boundaries that teams must make transparent.

Restraint as cooperation boundary (2.3B.1-3) applies the restraint principle — constructed in Phase I (1.2.3) — to the team charter itself: how to limit the charter's scope so that it governs what needs governing without overengineering cooperation into bureaucracy.

Together with the interface map and the payoff table embedded in the charter template, these tools give the team the structural capacity to design cooperation that holds — not because every member is virtuous, but because the terms are visible, the boundaries are enforceable, and the exit is clean.