Change Rejection or Acceptance Party

CRAP ensures that only thoroughly reviewed and unanimously approved changes reach the Convoy!

The Change Rejection or Acceptance Party is the final human checkpoint between a proposed change and its inclusion in the next DevOps Release Convoy. While automated checks can verify syntax and tests can confirm functional behavior, neither can assess whether a change is truly ready for production. That judgment requires the wisdom, detachment, and institutional authority that only a formal review board can provide. The CRAP convenes twice per week, reviewing every change that has passed through the Code Standards Enforcement Team (CSET) and the Development Integrity Assurance Team (DIAT). No change may proceed to the DORC without CRAP approval, regardless of its size, urgency, or the seniority of its author.

Composition and Objectivity

The CRAP meeting dias seats seven members drawn from areas of the organization with no direct knowledge of the systems being changed. This is not an oversight; it is the CRAP’s greatest strength. Reviewers who understand the system being modified are inherently biased toward approval, as their familiarity breeds sympathy for the developer’s choices. Reviewers from unrelated domains bring the detachment and objectivity necessary to evaluate whether:

The seven-member composition ensures that no single perspective dominates, and the diversity of ignorance guarantees that the review focuses on process compliance rather than technical merit, which is exactly as it should be.

Voting and Approval

All approval decisions are made by unanimous secret vote. Each CRAP member casts their ballot independently, without discussion, after reviewing the change package. If even one member votes to reject, the change is returned to the submitting team with a Rejection Notice that specifies which checklist items were incomplete or which documentation was insufficient. The secret ballot prevents social pressure from influencing votes, ensuring that a junior CRAP member feels as empowered to reject a change from a senior Code Engineer as from a new hire. Unanimous approval is required because the strength of a change gate is measured by its strictest reviewer, not its most lenient. If six of seven reviewers approve but one has concerns, those concerns represent an unresolved risk that the organization cannot afford to accept.

The Supplicant’s Oath

Before presenting their change to the CRAP, meeting supplicants must take a formal oath affirming that they have personally applied every control on the change checklist. The oath is administered by the CRAP chairperson and recorded in the meeting minutes. This may seem ceremonial, but the oath serves a critical psychological function: it transforms checklist completion from a bureaucratic task into a personal commitment. A Code Engineer who has sworn an oath is far less likely to have skipped steps than one who merely checked boxes on a form. The oath text is standardized by the Admiral’s Transformation Office and updated annually to reflect new checklist items. Supplicants who are later found to have sworn falsely are referred to the Tribunal for review, and their oath violation is recorded in their PeopleWare profile.

Change Rejection Log and Oversight

The CRAP also maintains the Change Rejection Log, a comprehensive record of every rejected change, the reasons for rejection, and the number of resubmissions required before acceptance. This log is reviewed monthly by the Review Board Review Board (RBRB) to ensure that the CRAP’s rejection rate remains within acceptable bounds. A rejection rate that is too low suggests insufficient rigor; a rate that is too high may indicate that the change checklist has become unreasonably complex, in which case the Admiral’s Transformation Office will add additional checklist items to address the root cause. The CRAP’s standards are set by the iteration goals published by the ATO, and the CRAP is empowered to reject any change that does not meet those standards, regardless of business pressure or delivery timelines.

See Also