The Enforce-in-Code Decision Tree 2.3B.2-1

How to Use This Tool

For each recurring decision the team makes, move through the five questions below in order. The answer pattern determines whether the decision should be enforced in code (with checklists, signatures, and append-only logging) or remain transparent but discretionary (with published criteria, documented reasoning, and an appeal process).

The tool requires honest answers. If the temptation is to say yes to reach automation, that is a signal the decision is not yet ready for enforcement. The cost of automating the wrong decision exceeds the cost of keeping it discretionary.

The Five Questions

Question 1: 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 them? "Promote someone when they are ready" is vague. "Promote when they have completed four projects at full ownership, received peer reviews averaging 4.0 or higher, and passed domain assessment" is clear and observable.

If yes — move to Question 2. If no — the decision is not ready for enforcement. Keep it discretionary. Document the criteria actually used, publish that documentation, and make decisions subject to appeal.

Question 2: Are the criteria objective enough to be testable?

Can different people agree on whether the criteria are met? "High quality code" is subjective. "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.

If all criteria are testable — move to Question 3. If some require interpretation — enforce the testable criteria through checklist. Leave the subjective criteria as a separate, transparent judgment step with documented reasoning.

Question 3: Are the stakes high enough to warrant structural enforcement?

Does error in this decision cause significant harm to people, commitments, or resources? High-stakes decisions include hiring, termination, compensation changes, role promotion, major resource allocation, architecture decisions that lock in future options. Low-stakes decisions include sprint scheduling, tool selection for low-impact tasks, meeting logistics.

If high-stakes — move to Question 4. If low-stakes — normal team judgment suffices. Enforcement overhead would exceed the benefit.

Question 4: Is there a default action that serves justice if the decision is not made?

If this decision is delayed or avoided, what rule protects the person affected? Examples: if someone requests exit, the default is clean exit with data portability unless documented otherwise. If someone alleges a charter violation, the default is investigation within ten business days. If someone is not reviewed on schedule, the default is review occurs within thirty days with retroactive adjustment.

If a just default exists — move to Question 5. If no just default exists — the decision cannot be safely automated. Keep it discretionary with transparency mechanisms.

Question 5: Can the decision be made transparently without surveillance?

Can the team verify correct decision-making through attestation and spot-check audit — without monitoring individuals' behavior or communications? Hiring decisions can be verified by checking records against published criteria and auditing a sample. Compensation decisions can be verified by comparing to the payoff table. Whether someone "worked the whole time they were logged in" cannot be verified without surveillance.

If verification works through attestation and audit — enforce in code. Design checklists, require signatures, log in append-only form. If verification requires surveillance — keep discretionary with transparency mechanisms.

Decision Pattern Summary

All five yes: Enforce in code. Design a checklist. Require signatures. Log every instance. Audit quarterly.

Four yes, one partial: Mostly enforce in code. Automate the parts that pass. Leave the subjective element as a transparent judgment step with documented reasoning.

Three or fewer yes: Transparent but discretionary. Publish criteria, require documented reasoning, make decisions subject to review and appeal.

Common Decisions: Worked Examples

Hiring

Conditions clear? Yes (opening exists, budget approved). Criteria testable? Mostly (skills testable; culture fit is not). Stakes high? Yes. Just default? Yes (if no decision within timeline, offer or close). Transparent without surveillance? Yes.

Recommendation: Enforce in code for objective criteria. Leave subjective judgment as a transparent step. Checklist: published job description with role scope, minimum qualifications defined and testable, candidates assessed against same method, reference checks completed, interview rounds by different team members, candidate has reviewed team charter and entry terms, offer negotiated and written, all signatures collected, entry date and onboarding mentor assigned.

Promotion

Conditions clear? Yes. Criteria testable? Mostly. Stakes high? Yes. Just default? Yes. Transparent without surveillance? Yes.

Recommendation: Enforce in code for structural criteria. Document judgment reasoning. Checklist: person meets advancement criteria in payoff table, peer review completed, manager reasoning in writing, integrity officer reviewed for consistency, person has agreed to expanded scope, new compensation finalized, all parties signed, changes logged.

Termination

Conditions clear? No (multiple possible grounds). Criteria testable? Partially. Stakes high? Extremely. Just default? Yes (person remains employed pending resolution). Transparent without surveillance? Partially.

Recommendation: Transparent but discretionary. Document the reason, allow appeal, provide written notice and specific reasons. Required documentation: performance concerns communicated in writing, specific measurable improvement goals given, progress reviewed at least twice, termination approved by integrity officer, written reason provided to person, exit process initiated, records updated in append-only log.

Data Access and Privacy Exceptions

Conditions clear? Yes. Criteria testable? Yes. Stakes high? Yes. Just default? Yes (data remains protected). Transparent without surveillance? Yes.

Recommendation: Enforce in code. Every exception requires documented request, justified reason meeting criteria, limited scope, specified duration with sunset, notification to person affected, integrity officer approval, append-only logging, and sunset enforcement.