Team Encoded Objective Law and Selective Transparency 2.3B.2

The Problem Enforcement Cannot Avoid

The previous unit (2.3B.1) engineered the team's cooperation — charter, decision rights, interfaces, consent validity, exit terms. On paper, the structure is honest. But paper is not execution. A charter can be shelved. Decision rights can be bypassed when deadlines compress. Interface standards can slide when no one is auditing them. Consent validity can evaporate when a member tries to invoke it and discovers that informal practice has drifted far from formal design.

This is not a failure of intention. It is the structural reality that human judgment, under pressure, defaults to convenience. A manager skips the decision rights matrix because unilateral decision is faster. A team member does not contest a boundary violation because the social cost feels higher than the grievance. A role owner lets standards slide because no one is checking. And slowly, the coercive structure the charter was designed to prevent re-accumulates — wearing the mask of the structure that replaced it.

Encoded objective law — one of Resilient Objectivism's (RO) design patterns, constructed in Phase I (1.2.2) — is the design discipline of encoding moral constraints into system architecture so that compliance is structural rather than dependent on individual virtue. At team scale, this means turning recurring high-stakes decisions into short checklists, requiring visible authorization for consequential acts, and maintaining an auditable record of what was decided and why. The principle: if a decision carries stakes high enough to matter — to people, to commitments, to resources — it should be visible enough to be auditable.

Selective transparency — the team-level expression of privacy by design (1.2.4) and the asymmetry principle — ensures that processes are visible and auditable while persons remain protected. The operating discipline: processes public by default; persons private by default; exceptions logged with written justification, scope, and sunset.

The Enforce-in-Code Decision Tree

Not every decision needs structural enforcement. Some are judgment calls best made by trained discretion. Some are low-stakes — error is cheap. Some are contextual — a fixed rule would be brittle. The enforce-in-code decision tree (2.3B.2-1) is the tool for distinguishing decisions that should be structurally enforced from those that should remain discretionary but transparent.

The tree asks five questions of each recurring decision:

Are the decision conditions clear and observable? Can the conditions that trigger this decision be stated precisely enough that someone unfamiliar with the situation could apply the rule? If the conditions require interpretation that cannot be externalized, the decision is not ready for enforcement.

Are the criteria objective enough to be testable? Can different people agree on whether the criteria are met? "High quality code" is not testable. "No security findings in static analysis, code review completed by senior engineer, test coverage above eighty-five percent" is testable. When criteria require interpretation, protocol can make them transparent but cannot enforce them.

Are the stakes high enough to warrant structural enforcement? Decisions affecting livelihoods, commitments, or irreversible constraints warrant enforcement. Decisions about which sprint to schedule a task or which prototyping tool to use do not. Enforcement overhead must be proportional to consequence.

Is there a default action that serves justice if the decision is not made? Some decisions, if delayed or avoided, should default to a protective rule. If someone requests exit, the default is clean exit with data portability unless the team documents why that is not safe. If someone alleges a charter violation, the default is investigation within ten business days. A decision without a just default cannot be safely automated.

Can the decision be made transparently without surveillance? Can the team verify correct decision-making through attestation and spot-check auditing — without monitoring individuals' behavior, communications, or activity? If verification requires surveillance, the decision should remain discretionary. This question directly applies the asymmetry principle from Phase I's privacy by design (1.2.4): institutions transparent, persons opaque.

A decision that passes all five questions is a candidate for enforcement through three mechanisms: decision checklists ensuring the decision-maker considers what should be considered, signatures and countersignatures creating visible authorization for consequential acts, and an append-only audit log making the record immutable — decisions cannot be silently erased, backdated, or revised.

A decision that fails on any question remains discretionary — but is wrapped in transparency mechanisms: published criteria, documented reasoning, and an appeal process. The distinction between enforced and discretionary-but-transparent is the structural spine of this unit.

Selective Transparency at Team Scale

Phase I defined the asymmetry principle: institutions must be transparent; persons must be opaque (1.2.4). At team scale, this principle becomes the transparency matrix (2.3B.2-2) — a documented specification of what information is public by default, what is auditable on request, and what is protected by design.

Most teams reverse the correct default. Individual data is treated as public — performance discussed openly, compensation shared casually, personal circumstances common knowledge. Process is treated as opaque — how decisions are made, what criteria applied, what reasoning stood behind an outcome. Selective transparency inverts this.

Public by default: Organizational structure, role definitions, decision authorities, team budget and resource allocation, technical architecture decisions and rationale, team metrics and output, the team charter and all amendments, and audit summary and compliance status.

Auditable on request: Individual performance review outcomes (by the person and their manager), individual compensation level (by the person, for verification against the payoff table), project assignments and capacity allocation, specific decision reasoning (available if challenged).

Protected by design: Individual performance review text, individual health and personal circumstance data, detailed strengths and weaknesses, lateral peer feedback, salary history and negotiation discussions, reasons for non-hire or non-promotion (unless the person requests), and reasons for termination (shared with the person and integrity officer, not with the team).

Exceptions to the default are logged with five elements: what information is being exposed and why, who authorized the exception, who gets access and for how long, and the sunset date when access is automatically revoked. The exception log is itself auditable — it prevents the quiet accumulation of privacy erosion through individually justified but collectively corrosive exceptions.

Attestation Without Surveillance

The structural challenge of selective transparency is measurement. Team leadership must assess whether the team is functioning — which requires data about performance, outcomes, and contribution, data that often touches persons. The solution is attestation without exposure: verifying claims without seeing the individual data those claims rest on.

A claim that "the hiring process is fair" does not require reviewing every candidate's resume and interview notes. It requires aggregate data (candidates at each stage, demographic patterns), published criteria, attestation from the hiring manager that the criteria were applied, and randomized audit of a sample of decisions to verify the attestation. A claim that "compensation is consistent with the payoff table" does not require publishing everyone's salary. It requires the payoff table itself (public), aggregate statistics (median, range, ratio), attestation from the relevant authority, and individual audit on request.

Attestation connects directly to Phase I's construction of encoded objective law: the sovereignty primitives admitted under the Rule of Admission — least privilege, signatures, attestations, append-only state (1.2.2) — are the building blocks that make verification without surveillance structurally possible. The team-level toolkits in this unit are the operational expression of those primitives.

The Dispute Path

Even with protocol enforcement and selective transparency, violations occur. A manager bypasses the decision rights matrix. Protected data is exposed. A commitment is missed. The dispute path is the team's structural response — not punishment, but correction and learning.

The path has four stages:

Informal resolution (target: forty-eight hours). The affected person raises the issue with the person involved or the manager. Most conflicts resolve here, with a conversation and agreement to correct course.

Mediated review (target: five business days). If informal resolution fails, the person files a formal dispute with the integrity officer. The filing includes what rule or commitment was violated, when it happened, what harm resulted, and what correction is sought. The integrity officer reviews and proposes a correction.

Decision with written reasoning (target: ten business days). If mediated review fails, the integrity officer makes a binding decision with published reasoning. This is institutional accountability — not splitting the difference, but determining whether the team's rules were violated and what correction is due. Possible corrections include redoing the decision with proper process, compensating for harm, process change to prevent recurrence, or management action if a person violated protocol.

Appeal on narrow grounds (no time limit). The person can appeal only on new evidence, process error, or undisclosed conflict of interest. If the appeal is granted, the case is re-reviewed. If denied, the decision stands. Appeals are tracked — if a pattern emerges (certain decisions frequently appealed), the design is producing the disputes, and the design needs revision.

The dispute path connects to Phase I's strain condition on epistemology and ethics under adversarial pressure (1.3.9). A team whose enforcement depends entirely on good faith has no structural defense when good faith fails. The dispute path provides that defense — it is the team-scale expression of the recourse requirement that bounded interdependence (1.2.6) demands at every level of cooperation.

What This Unit Ships

Three toolkits make the structural argument operational:

The enforce-in-code decision tree (2.3B.2-1) guides the team through distinguishing decisions that warrant structural enforcement from those that should remain discretionary but transparent, with checklists for six common decision types.

The transparency matrix (2.3B.2-2) specifies the default classification for every class of information the team handles — what is public, what is auditable, what is protected — with an exception logging framework and quarterly privacy attestation audit.

Under AI conditions (2.3B.2-3) translates encoded objective law and selective transparency into practice when team decisions, measurements, and communications are mediated by computational systems — where the stakes are higher because errors are systemic, the transparency requirements are stricter because no human can explain the system's reasoning, and the auditability requirements are more rigorous because drifting systems affect many people at once.