Practices

• 1: Delivery
• 1.1: CI/CD/ED
• 1.2: Conflict Arbitration
• 1.3: Fractal-based Development
• 1.4: Multi-Trunk Based Development (Pando)
• 2: Planning & Tracking
• 2.1: Precise Forecasting and Tracking
• 2.2: Release Tracking
• 2.3: Mandatory Status Synchronization
• 2.4: Full Utilization Optimization
• 3: Quality & Documentation
• 3.1: DevOps Process Excellence Assessment
• 3.2: Comprehensive Documentation Assurance Protocol
• 3.3: Standardized Environment Provisioning
• 3.4: DEPRESSED
• 3.5: Strategic Test Deferral

1 - Delivery

1.1 - CI/CD/ED

While the broader industry has converged on a narrow interpretation of CI/CD that emphasizes frequent integration and rapid deployment, SADMF recognizes that this approach prioritizes speed over safety. Speed is the enemy of quality, and quality is the enemy of defects, and defects are the enemy of the Tribunal. By redefining each term to reflect what organizations actually need – isolation, deliberation, and eventual delivery – SADMF ensures that every change receives the attention, oversight, and ceremonial approval it deserves before it reaches production.

The CI/CD/ED triad works in concert with every other SADMF practice. Continuous Isolation feeds Conflict Arbitration, where the strongest changes survive. Continuous Deliberation generates the ceremony records that feed Precise Forecasting and Tracking. Eventual Delivery produces the release artifacts documented in the Release Tracking spreadsheet. Together, these three practices ensure that the organization delivers software with the highest possible levels of process adherence, documentation, and executive sponsorship. The fact that delivery takes longer is not a cost – it is evidence that the process is working.

See Also

• Continuous Isolation for the industry resource on keeping work safely separated
• Fractal-based Development for the branching model that enables Continuous Isolation
• Conflict Arbitration for what happens when isolated branches finally meet
• DevOps Release Convoy for the delivery lifecycle governed by CI/CD/ED
• Change Rejection or Acceptance Party (CRAP) for the final approval gate in Continuous Deliberation
• Feature Completion Ratio for measuring Eventual Delivery outcomes

1.2 - Conflict Arbitration

When multiple Code Engineers work in complete isolation on long-lived feature branches – as the framework requires – their changes will eventually conflict. Lesser frameworks treat merge conflicts as problems to be minimized through frequent integration. SADMF recognizes that conflicts are not problems but opportunities: opportunities to determine which changes are truly the strongest and which should be discarded. Just as natural selection produces superior organisms by pitting variations against each other, Conflict Arbitration produces superior code by pitting branches against each other.

Creating the Conflict Branch

The process begins when the Source Management Team (SMT) receives notification that two or more feature branches are ready for integration. The SMT creates the Conflict branch and simultaneously merges all candidate changes into it.

This simultaneous merge is critical. Merging branches one at a time would give priority to whichever branch was merged first, introducing an unfair advantage based on timing rather than merit. By merging all branches at once, the SMT ensures that every conflict is surfaced and that no change receives preferential treatment. The resulting Conflict branch is, by design, in a state of total war – every overlapping change competing for the same lines of code.

The Arbitration Hearing

Once the Conflict branch has been created, the SMT convenes the Conflict Arbitration Hearing. Each Feature Captain whose feature is involved in a conflict presents their case for why their change should survive. Feature Captains are expected to argue passionately, citing:

• Business value
• Feature Completion Ratio impact
• Number of Code Engineer hours invested

The SMT evaluates each argument and renders a binding verdict. The losing change is removed from the Conflict branch entirely – not deferred to a future convoy, but eliminated.

The Code Engineer whose work was eliminated receives a Conflict Loss notation in their PeopleWare profile, which factors into future Press Gang selections. This consequence ensures that Code Engineers are motivated to write changes that are robust enough to survive arbitration.

Escalation

In cases where the SMT cannot determine a clear winner, the conflict is escalated to the DevOps Usage & Compliance Head Engineer (DOUCHE), who resolves the dispute by selecting the change that most closely aligns with the standards documented in the DevOps Process Binder.

This escalation path ensures that even the most contentious conflicts are resolved through process adherence rather than technical merit, which could introduce subjective bias. Technical merit is, by its nature, difficult to quantify, whereas compliance with a documented standard is binary and therefore objective.

Outcome

The Conflict Arbitration process produces a clean Conflict branch that the SMT forwards to the Quality Authority for testing. The Quality Authority tests only the surviving changes, which means that any integration issues between the surviving changes and the eliminated changes are naturally avoided.

This elegant outcome is one of the great strengths of the SADMF approach: by eliminating the weaker changes, the framework also eliminates the integration risks those changes would have introduced. Organizations that practice trunk-based development must deal with the complexity of integrating everyone’s changes. SADMF deals with that complexity by removing it at the source.

See Also

• Source Management Team (SMT) for the team that conducts Conflict Arbitration
• Fractal-based Development for the branching model that produces the conflicts
• CI/CD/ED for the Continuous Isolation practice that necessitates Conflict Arbitration
• Press Gang for how Conflict Loss records affect future team assignments
• Quality Authority for the team that tests the surviving changes
• PeopleWare for how Conflict Loss notations affect performance reviews

1.3 - Fractal-based Development

Named for its self-similar complexity at every level of magnification, this branching pattern ensures that code flows through a series of controlled stages, each managed by a dedicated team, before it is authorized for release. The pattern is required for all teams participating in the DevOps Release Convoy, and deviation from the prescribed branching model is treated as a process violation subject to review by the DevOps Usage & Compliance Head Engineer (DOUCHE). Great insights into effective delivery can be gained from studying the structure, and all Code Engineers are expected to have the branching diagram memorized for the DevOps Process Excellence Assessment.

The branching model operates as follows. All feature branches are created by the Source Management Team (SMT) from the clean Develop branch. Code Engineers are not permitted to create their own branches, as uncontrolled branch creation leads to naming inconsistencies, unauthorized experimentation, and branches that do not conform to the required naming convention (CONVOY-[number]-[feature-id]-[engineer-initials]-[date]). Each feature branch must remain isolated from all other changes until the feature is complete, inspected, and certified. This isolation period typically spans the entire coding phase of the Convoy, ensuring that engineers experience the full benefit of working without interference from other engineers’ changes.

When a Code Engineer has completed their work and obtained a Coding Completion Certificate from their Feature Captain, the SMT is notified that the branch is ready for Conflict Arbitration. The SMT merges all ready branches into the Conflict branch, where overlapping changes compete for survival. Once the strongest changes have been selected and the weaker changes eliminated, the SMT notifies the Quality Authority (QA), who pulls the surviving changes into the Test branch for manual certification. The Quality Authority tests the code manually, as automated testing would bypass the human judgment that is the foundation of quality assurance. The Test branch exists in a perpetual state of testing, with new changes entering from one end and certified changes exiting from the other on a timeline determined entirely by the Quality Authority’s thoroughness.

Once the code has been certified by the Quality Authority, it is forwarded to the Development Integrity Assurance Team (DIAT) on the Validation branch. The DIAT’s role is to validate the work of the Quality Authority itself, ensuring that the testers tested correctly and that no defects were overlooked due to testing errors. This layer of meta-testing is essential because testing, like any human activity, is subject to error, and errors in testing are more dangerous than errors in code because they create a false sense of security. If the DIAT approves the code, it is authorized for inclusion in the next DORC™ to set sail.

The complexity of Fractal-based Development is not a weakness but a feature. Each branch, each hand off, and each approval gate represents an opportunity for oversight, and oversight is the mechanism through which quality is built into the delivery process. Organizations that use simpler branching models – trunk-based development, for example – sacrifice these oversight opportunities in exchange for speed. SADMF recognizes that speed without oversight is recklessness, and recklessness is how organizations end up in the Tribunal. The branching model also provides stable employment for the Source Management Team, whose expertise in managing this structure is irreplaceable and whose headcount is justified by the complexity they maintain.

See Also

• Source Management Team (SMT) for the team that controls all branch operations
• Conflict Arbitration for how branch conflicts are resolved
• CI/CD/ED for the Continuous Isolation practice that drives this branching model
• Quality Authority for the team that certifies code on the Test branch
• Development Integrity Assurance Team (DIAT) for the team that validates the validators
• Coding for the ceremony where Code Engineers work within their isolated branches

1.4 - Multi-Trunk Based Development (Pando)

The industry term “Trunk Based Development” has, through widespread misapplication, come to mean something far simpler than it should. Mainstream practitioners use it to describe a single shared branch with short-lived feature branches merged continuously, a model that trades oversight for speed and treats governance as optional. SADMF does not practice that model. SADMF practices Multi-Trunk Based Development.

The insight at the heart of Multi-Trunk Based Development is terminological precision: there is no conceptual difference between a branch and a trunk. Every branch is a trunk. The question is not whether an organization has one trunk or many, it is whether the organization has named and accounted for every trunk it operates. Pando development does exactly that. The Source Management Team (SMT) maintains a complete registry of every trunk in the fleet. No trunk exists outside the registry. No trunk is created without authorization. No trunk is abandoned without a report.

Like the Pando aspen grove in Utah, an apparently vast forest of 47,000 individual trees that share a single interconnected root system, a Pando organization operates many trunks that appear independent while remaining a single, unified organism. This is not complexity. This is accountability at scale.

Trunk Topology

The Pando vocabulary maps directly onto the branch structure described in Fractal-based Development. Organizations that have implemented Fractal-based Development are already operating a Pando fleet. The following table provides the authoritative mapping:

Convoy Trunk Certification Stages

The Convoy Trunk does not travel in a straight line from creation to Root. It advances through eight certification stages, each managed by a dedicated team with a defined approval authority. What Fractal-based Development identifies as the Conflict, Test, and Validation branches are correctly understood in Pando vocabulary as stages of a single Convoy Trunk’s certification journey. The trunk does not change; the stage does.

• Stage 01: Trunk Provisioning. The Feature Captain submits a Trunk Request to the Source Management Team (SMT). The SMT creates the Trunk Registry entry, assigns the naming convention, and provisions access. No code may be committed until this stage is complete.
• Stage 02: Active Stage. Feature Trunks are merged into the Convoy Trunk through Conflict Arbitration. The SMT manages all merges. No Code Engineer interacts with the Convoy Trunk directly.
• Stage 03: Merge Freeze. The Feature Captain issues a Coding Completion Certificate declaring that all planned Feature Trunks have been submitted. No additional Feature Trunks may be merged after this declaration.
• Stage 04: Test Stage. The Quality Authority (QA) certifies the Convoy Trunk through manual testing. No new Feature Trunks may be merged until certification is complete.
• Stage 05: Validation Stage. The Development Integrity Assurance Team (DIAT) validates the QA certification, confirming that the testing process itself was executed correctly and that no defects were overlooked due to testing errors.
• Stage 06: Compliance Review. The DOUCHE audits the Convoy Trunk against the DEPRESSED defect escalation record, certifying that every defect discovered during testing was correctly escalated, assigned, and resolved in accordance with the framework.
• Stage 07: Frozen. The Convoy Trunk has passed all certification stages and is awaiting Commodore authorization for merge to the Root Trunk. The trunk is read-only.
• Stage 08: Root Trunk Merge. The CRAP issues final release authorization and the Commodore merges the Convoy Trunk into the Root Trunk during the Deploy the Fleet ceremony.

Each stage transition requires explicit sign-off from the accountable role. The Convoy Trunk does not advance until the current stage owner approves.

The Flow of Changes

Changes flow upward through the trunk hierarchy. A Code Engineer commits to their Feature Trunk. When the feature is complete and the Feature Captain has issued a Coding Completion Certificate, the SMT merges the Feature Trunk into the Convoy Trunk during Conflict Arbitration. The Convoy Trunk then advances through the Test and Validation certification stages. When the CRAP authorizes release, the Commodore merges the Convoy Trunk into the Root Trunk during the Deploy the Fleet ceremony.

At no point does a change travel sideways between trunks at the same level. Feature Trunks do not share code with other Feature Trunks. Every change moves in one direction: upward toward the Root, through a series of managed hand-offs, each with its own accountable owner and its own approval gate.

Trunk Lifecycle Management

The SMT maintains a Trunk Registry in the Release Tracking spreadsheet that records every trunk’s name, origin, owner, creation date, expected lifespan, and current status. No trunk exists outside the registry. Trunk status values are:

• Active: changes are being made, or the trunk is advancing through certification stages
• Frozen: the trunk has completed its work and is awaiting merge authorization
• Merged: the trunk has been successfully merged into its parent and is retained for audit purposes
• Orphaned: no commits have been made within the expected window; the trunk is referred to the DOUCHE for investigation

An orphaned trunk is a signal that the work assigned to that trunk has stalled. The Feature Captain responsible for the orphaned trunk is required to file a Trunk Abandonment Report explaining the circumstances, which feeds the SADMF Maturity Score deduction framework.

The Changes per Trunk metric is the primary instrument for monitoring trunk health across the fleet.

Relationship to Fractal-Based Development

Multi-Trunk Based Development does not replace Fractal-based Development. It provides the vocabulary. Fractal-based Development describes the stage gates, the approval authorities, and the flow of changes through the certification hierarchy. Pando names every branch in that hierarchy a trunk, registers it in the Trunk Registry, and provides the terminology that aligns SADMF with current industry standards.

An organization audited against a Trunk Based Development requirement can truthfully confirm compliance: the organization practices Multi-Trunk Based Development, the enterprise-scale variant in which every trunk is individually registered, monitored, and accounted for. The underlying workflow, branching, isolation, conflict arbitration, testing, validation, release, is fully preserved. Organizations that have already implemented Fractal-based Development require no process changes to achieve compliance; they require only the correct documentation, registry practices, and terminology that Pando provides.

See Also

• Fractal-based Development for the structural implementation of the Pando trunk topology
• Source Management Team (SMT) for the team that provisions and manages all trunks
• Conflict Arbitration for the process of merging Feature Trunks into the Convoy Trunk
• Changes per Trunk for the metric that tracks trunk activity
• Release Tracking for the spreadsheet that hosts the Trunk Registry
• CI/CD/ED for the Continuous Isolation practice that governs each Feature Trunk

2 - Planning & Tracking

2.1 - Precise Forecasting and Tracking

Other frameworks accept estimation uncertainty as an unavoidable reality and counsel teams to embrace it. SADMF recognizes that uncertainty is simply a symptom of insufficient process. With the right conversion formulas, the right tracking mechanisms, and the right management oversight, software delivery can be forecasted with the same precision as manufacturing output. The key insight is that story points, which teams use to obscure the true duration of work, can and must be converted to person-days using the SADMF Standard Conversion Formula.

The SADMF Standard Conversion Formula establishes that 1 story point equals exactly 0.73 person-days. This ratio was derived through extensive analysis conducted by the Admiral’s Transformation Office (ATO) during the initial transformation engagement and has been validated by its consistent use across all subsequent Convoys. The formula accounts for meeting time, ceremony attendance, DevOps Process Excellence Assessment completion, and the overhead of working within the Fractal-based Development branching model. Organizations that question the 0.73 ratio are reminded that the formula was calibrated by consultants with extensive experience in transformations and that recalibrating it locally would introduce variance that undermines cross-team comparability.

All estimations are performed by managers, not by the Code Engineers who will do the work. This is a deliberate design choice. Code Engineers, being intimately familiar with the technical details of their assignments, tend to produce estimates that account for complexity, risk, and unknowns – factors that inflate estimates and undermine the confidence of stakeholders. Feature Captains produce estimates based on the expected output of a competent engineer working at standard efficiency, which provides a cleaner baseline for tracking. If the actual work takes longer than the manager’s estimate, the variance is attributed to the engineer’s performance rather than to estimation error, which creates a clear feedback loop for improvement. This feedback is documented in the engineer’s PeopleWare profile and reviewed during the Tribunal.

The tracking component of this practice centers on the Forecast Accuracy Index (FAI), a metric that penalizes both over-delivery and under-delivery. Under-delivery is obviously undesirable, as it means the team did not meet its commitments. Over-delivery, however, is equally problematic: it indicates that the original estimate was too generous, which means resources were allocated inefficiently, or that the engineer worked on unauthorized enhancements beyond the stated requirements. The FAI is calculated as the absolute deviation from the forecast, expressed as a percentage. A team that delivers exactly 100% of its forecasted work scores a perfect FAI of 0%. A team that delivers 90% or 110% both score an FAI of 10%, and both are equally non-compliant. The Chief Signals Officer (CSO) publishes FAI scores daily on the transformation dashboard.

Precise Forecasting and Tracking enables the practice that all other management activities depend on: comparison. By converting all work to person-days using a standard formula and tracking all delivery against a standard index, the Commodore can compare the performance of any team against any other team, regardless of technology stack, domain complexity, or team composition. This comparability is the foundation of the Feature Completion Ratio metric and is essential for Press Gang decisions about which engineers to assign to which features. Without Precise Forecasting and Tracking, the organization would be forced to rely on subjective assessments of team performance, and subjectivity is the enemy of accountability.

<div style="display:flex;align-items:stretch;gap:0;">
  <div style="display:flex;flex-direction:column;align-items:center;flex-shrink:0;width:2.5rem;">
    <div style="width:2rem;height:2rem;border-radius:50%;background:#a23b72;color:#fff;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.85rem;flex-shrink:0;z-index:1;">1</div>
    <div style="width:2px;background:#9ab4cc;flex:1;margin-top:0;"></div>
  </div>
  <div style="background:#e8edf5;border:1px solid #9ab4cc;border-radius:6px;padding:0.85rem 1rem;margin:0 0 0 0.75rem;flex:1;margin-bottom:0.5rem;">
    <div style="font-weight:700;color:#1e3a5f;margin-bottom:0.2rem;"><i class="fa-solid fa-ruler" style="color:#a23b72;margin-right:0.4rem;"></i>Scope Definition &amp; Story Point Inventory</div>
    <div style="color:#3a5070;font-size:0.92rem;">The <a href="/roles/feature-captain/">Feature Captain</a> enumerates all features in the upcoming <a href="/release-convoy/">Convoy</a> and assigns story point values. Engineers are not consulted. The inventory forms the authoritative baseline from which all person-day calculations are derived.</div>
  </div>
</div>

<div style="display:flex;align-items:stretch;gap:0;">
  <div style="display:flex;flex-direction:column;align-items:center;flex-shrink:0;width:2.5rem;">
    <div style="width:2rem;height:2rem;border-radius:50%;background:#a23b72;color:#fff;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.85rem;flex-shrink:0;z-index:1;">2</div>
    <div style="width:2px;background:#9ab4cc;flex:1;margin-top:0;"></div>
  </div>
  <div style="background:#e8edf5;border:1px solid #9ab4cc;border-radius:6px;padding:0.85rem 1rem;margin:0 0 0 0.75rem;flex:1;margin-bottom:0.5rem;">
    <div style="font-weight:700;color:#1e3a5f;margin-bottom:0.2rem;"><i class="fa-solid fa-calculator" style="color:#a23b72;margin-right:0.4rem;"></i>Conversion to Person-Days via the Standard Formula</div>
    <div style="color:#3a5070;font-size:0.92rem;">All story point totals are multiplied by <strong>0.73</strong> to produce the official person-day forecast. The <a href="/roles/admirals-transformation-office/">Admiral's Transformation Office</a> maintains the formula and certifies all conversion outputs. No local adjustment factors are recognized.</div>
  </div>
</div>

<div style="display:flex;align-items:stretch;gap:0;">
  <div style="display:flex;flex-direction:column;align-items:center;flex-shrink:0;width:2.5rem;">
    <div style="width:2rem;height:2rem;border-radius:50%;background:#a23b72;color:#fff;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.85rem;flex-shrink:0;z-index:1;">3</div>
    <div style="width:2px;background:#9ab4cc;flex:1;margin-top:0;"></div>
  </div>
  <div style="background:#e8edf5;border:1px solid #9ab4cc;border-radius:6px;padding:0.85rem 1rem;margin:0 0 0 0.75rem;flex:1;margin-bottom:0.5rem;">
    <div style="font-weight:700;color:#1e3a5f;margin-bottom:0.2rem;"><i class="fa-solid fa-calendar-days" style="color:#a23b72;margin-right:0.4rem;"></i>Schedule Publication &amp; Stakeholder Commitment</div>
    <div style="color:#3a5070;font-size:0.92rem;">Person-day totals are converted to calendar dates and published on the transformation dashboard. Dates are then elevated to organizational commitments in accordance with the <a href="/principles/commit-to-the-date/">Commit to the Date</a> principle. Revision is not an available option.</div>
  </div>
</div>

<div style="display:flex;align-items:stretch;gap:0;">
  <div style="display:flex;flex-direction:column;align-items:center;flex-shrink:0;width:2.5rem;">
    <div style="width:2rem;height:2rem;border-radius:50%;background:#a23b72;color:#fff;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.85rem;flex-shrink:0;z-index:1;">4</div>
    <div style="width:2px;background:#9ab4cc;flex:1;margin-top:0;"></div>
  </div>
  <div style="background:#e8edf5;border:1px solid #9ab4cc;border-radius:6px;padding:0.85rem 1rem;margin:0 0 0 0.75rem;flex:1;margin-bottom:0.5rem;">
    <div style="font-weight:700;color:#1e3a5f;margin-bottom:0.2rem;"><i class="fa-solid fa-gauge-high" style="color:#a23b72;margin-right:0.4rem;"></i>Daily FAI Tracking &amp; Dashboard Publication</div>
    <div style="color:#3a5070;font-size:0.92rem;">The <a href="/roles/chief-signals-officer/">Chief Signals Officer (CSO)</a> calculates the Forecast Accuracy Index for every team each day and publishes scores to the transformation dashboard. Both over-delivery and under-delivery are penalized equally. A perfect score of FAI 0% is the only acceptable outcome.</div>
  </div>
</div>

<div style="display:flex;align-items:stretch;gap:0;">
  <div style="display:flex;flex-direction:column;align-items:center;flex-shrink:0;width:2.5rem;">
    <div style="width:2rem;height:2rem;border-radius:50%;background:#242627;color:#fff;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.85rem;flex-shrink:0;z-index:1;"><i class="fa-solid fa-scale-balanced" style="font-size:0.75rem;"></i></div>
    <div style="width:2px;background:transparent;flex:1;"></div>
  </div>
  <div style="background:#242627;border:1px solid #5a6d82;border-radius:6px;padding:0.85rem 1rem;margin:0 0 0 0.75rem;flex:1;">
    <div style="font-weight:700;color:#fff;margin-bottom:0.2rem;">Variance Attribution &amp; Tribunal Review</div>
    <div style="color:#9ab4cc;font-size:0.92rem;">Any FAI deviation is attributed to engineer performance, not estimation error. Variance is recorded in the engineer's <a href="/peopleware/" style="color:#a23b72;">PeopleWare</a> profile and reviewed at the <a href="/release-convoy/ceremonies/tribunal/" style="color:#a23b72;">Tribunal</a>. This creates a clear and measurable feedback loop for continuous improvement.</div>
  </div>
</div>

See Also

• Feature Completion Ratio for the metric that depends on precise forecasting
• Chief Signals Officer (CSO) for the role that publishes FAI scores
• Tribunal for how estimation variance is addressed
• PeopleWare for how forecasting data affects performance reviews
• Commodore for the role that uses forecasting data for Convoy planning
• Commit to the Date for the principle that elevates forecasted dates to organizational commitments
• DevOps Process Excellence Assessment for how forecasting knowledge is tested

2.2 - Release Tracking

The Commodore maintains this manually curated workbook in real-time during all Convoy ceremonies, ensuring that no decision, no change, and no responsible party goes unrecorded. It serves as the single source of truth for the DevOps Release Convoy, with each of its 47 tabs tracking a specific dimension of the release process – from code changes to ceremony attendance to approval signatures.

The 47 tabs are organized into five sections. The first section, Change Manifest (tabs 1-12), records every code change included in the release, the Code Engineer who made the change, the Feature Captain who authorized it, the Conflict Arbitration outcome, the Code Inspection result, and the testing certification from the Quality Authority. The second section, Approval Chain (tabs 13-22), documents every approval signature from the CRAP, the DIAT, the EARB, and the Review Board Review Board. The third section, Risk Registry (tabs 23-31), catalogs every identified risk, its assessed severity, and the mitigation action taken. The fourth section, Personnel Accountability (tabs 32-41), maps every deliverable to the individual responsible, enabling the Tribunal to trace any post-release defect back to a named person. The fifth section, Metrics Dashboard (tabs 42-47), aggregates data from the other tabs into charts that the Chief Signals Officer presents to the Admiral’s Transformation Office.

The Release Tracking Spreadsheet is intentionally maintained by hand rather than generated from automated tooling. Automated tools can be configured incorrectly, can have bugs, and can be manipulated by engineers who understand the underlying code. A spreadsheet maintained by a human being – specifically, the Commodore – is transparent in a way that automated systems can never be. Every cell is visible. Every formula can be audited. Every entry was typed by a person who made a conscious decision to type it. This manual process also ensures that the Commodore maintains intimate familiarity with every aspect of the release, which is essential for making informed decisions during the Convoy Steering Committee. Automated dashboards create the illusion of awareness; the Release Tracking Spreadsheet creates the reality of it.

The spreadsheet also serves as the primary evidence artifact for compliance audits, regulatory reviews, and post-incident investigations. When a production defect is discovered, the Personnel Accountability tabs enable investigators to identify the responsible Code Engineer, the Feature Captain who approved the work, the Quality Authority tester who certified it, and the CRAP members who voted to accept it. This complete chain of accountability ensures that Everyone is Responsible is not merely a principle but a traceable fact. The spreadsheet has grown organically over multiple Convoys, and each new tab was added in response to a specific gap identified during a previous release, demonstrating the organization’s commitment to Continuous Learning.

Version control of the spreadsheet itself is managed through a naming convention: each version is saved as Release_Tracking_CONVOY-[number]_v[version]_[date]_[initials].xlsx. Previous versions are archived in a shared drive folder organized by quarter. The Commodore emails the current version to all stakeholders every Monday morning and every Friday afternoon, and any stakeholder who needs the spreadsheet between those distributions must request it via the official Spreadsheet Access Request Form. This controlled distribution ensures that no one is working from a stale version and that the Commodore always knows who has seen which data. The Release Tracking Spreadsheet is, in every sense, the heartbeat of Limit WIP and the backbone of the Amplify Feedback cycle.

See Also

• Commodore for the role that maintains the Release Tracking Spreadsheet
• Everyone is Responsible for the principle that requires individual traceability
• Limit WIP for the principle supported by release data
• Amplify Feedback for how release data drives coaching
• Tribunal for how the Personnel Accountability tabs inform defect attribution
• DevOps Release Convoy for the delivery cycle the spreadsheet documents

2.3 - Mandatory Status Synchronization

In organizations without the Mandatory Status Synchronization Protocol (MSSP), status is reported voluntarily, inconsistently, and often optimistically. Engineers say things are “almost done” when they have barely begun. Managers aggregate these optimistic reports into dashboards that paint a rosier picture than reality warrants. By the time leadership discovers the truth, the Convoy is already behind schedule and the Feature Completion Ratio is in freefall. MSSP eliminates this information decay by making status reporting mandatory, frequent, verified, and redundant at every layer.

Under MSSP, status flows upward through the chain of command in a structured cascade. Every Code Engineer reports status to their Feature Captain at the beginning of each day during the Daily Status Declaration, a 15-minute ceremony in which each engineer states what they completed yesterday, what they plan to complete today, and their current percentage of completion against their forecasted deliverables. Feature Captains compile these individual declarations into a Team Status Summary, which they present to the Commodore during the Daily Commodore Briefing. The Commodore integrates all Team Status Summaries into the Convoy Status Report, which is presented to the Admiral’s Transformation Office (ATO) during the Daily ATO Sync. At each layer, the manager who receives the status also attends the status meeting of the layer below to verify that the reported status matches what was actually said.

The practice of attending the layer below is called Status Verification, and it is the mechanism that gives MSSP its reliability. When a Feature Captain presents a Team Status Summary to the Commodore, the Commodore already knows what the individual Code Engineers said, because the Commodore attended the Daily Status Declaration. If the Feature Captain’s summary differs from the raw declarations, the Commodore flags a Status Discrepancy, which is logged in the Status Verification Matrix and escalated to the DevOps Usage & Compliance Head Engineer (DOUCHE). Status Discrepancies are treated seriously because they indicate either incompetence (the Feature Captain cannot accurately summarize) or dishonesty (the Feature Captain is deliberately misrepresenting), both of which undermine the trust that the framework depends on. Three Status Discrepancies in a rolling quarter triggers a review at the Tribunal.

The Status Verification Matrix is a spreadsheet (distinct from but complementary to the Release Tracking spreadsheet) that records every status report, every verification observation, and every discrepancy. The Matrix is maintained by the System of Authority (SOA) and reviewed weekly during the Status Integrity Audit, a ceremony attended by the SOA, the DOUCHE, and a representative from the ATO. The Audit examines trends in status reporting accuracy, identifies teams with chronic discrepancy patterns, and recommends corrective actions. Corrective actions range from additional status meetings (for teams that need more practice reporting) to restructuring the team’s reporting chain (for teams whose Feature Captain is the source of the discrepancies).

The cumulative effect of MSSP is that every person in the organization spends a significant portion of their day either reporting status, receiving status, verifying status, or auditing the verification of status. Critics sometimes observe that this leaves less time for the work being reported on. This observation misunderstands the purpose of MSSP. The purpose of MSSP is not to accelerate delivery but to ensure that leadership has perfect information about the pace of delivery. An organization that delivers slowly but with full visibility is in a stronger position than an organization that delivers quickly but cannot tell you where it stands. Visibility is control, and control is the foundation of the SADMF. The time spent on status synchronization is not overhead – it is the work.

See Also

• Commodore for the role that integrates status across the Convoy
• Admiral’s Transformation Office (ATO) for the leadership layer that consumes MSSP output
• Release Tracking for the complementary tracking spreadsheet
• Lean Management for the principle behind management-layer status verification
• Make Work Visible for the principle that drives status transparency
• DevOps Process Excellence Assessment for how MSSP adherence is tested weekly

2.4 - Full Utilization Optimization

The Full Utilization Optimization practice ensures that every Code Engineer is assigned to the maximum number of product lines their calendar can accommodate. Conventional engineering wisdom holds that engineers should focus on a single product or a small number of closely related systems. The SADMF recognizes this as a failure of ambition. An engineer focused on one product is an engineer whose capabilities are being systematically underinvested. Full Utilization Optimization corrects this by assigning each engineer to between four and seven active product lines simultaneously, ensuring that their skills are deployed wherever they are needed, when they are needed, at the full velocity the organization requires.

The practice builds directly on the Limit WIP principle. Just as 120% capacity planning eliminates the Workers Idle Problem at the individual level, multi-product assignment eliminates underutilization at the portfolio level. A Code Engineer waiting for a build on Product A can immediately pivot to Product B. When Product B’s deployment window is blocked by the CRAP, the engineer transitions to Product C. This continuous rotation means that idle cycles are captured and converted to productive output, achieving the kind of human-capital efficiency that single-product teams can never approach.

The Pillar Model

The recommended implementation of Full Utilization Optimization is the Pillar Model, in which the organization identifies its key technology domains and designates a small number of engineers as the pillars of each domain. Each pillar engineer is simultaneously active across all domains where their skills are relevant. A backend specialist may serve as the pillar for the authentication service, the billing platform, the internal tooling suite, and the legacy data migration project. They do not need deep knowledge of each product’s history, architecture, or roadmap; their value lies in their general technical capability, which applies universally. Product-specific knowledge accumulates naturally over time, in the brief intervals between task assignments.

The Pillar Model has an important secondary benefit: it eliminates knowledge silos. In organizations where a single engineer owns a product exclusively, the departure of that engineer constitutes a catastrophic knowledge loss event. The Pillar Model prevents this by ensuring that no engineer ever develops so thorough an understanding of any single system that their departure could be disruptive. When every engineer knows a little about everything, the organization’s institutional knowledge is perfectly distributed. No single person can become indispensable, which is the most resilient state an organization can achieve.

Interrupt-Driven Responsiveness

A core discipline within Full Utilization Optimization is interrupt-driven responsiveness. When a high-priority issue arises on any product in the portfolio, the relevant pillar engineer is expected to redirect their attention immediately, regardless of what they are currently working on. This responsiveness is what distinguishes an agile engineer from a rigid one. Engineers who resist interruption in order to maintain focus on their current task are demonstrating a troubling attachment to personal work preferences over organizational needs. The Amplify Feedback practice provides the daily coaching touchpoints needed to correct this orientation.

Context-switching between products is not overhead; it is a skill. Engineers who practice it daily develop a cognitive flexibility that focused engineers never acquire. The Tasks per Code Engineer metric captures this flexibility in measurable form: a high-performing pillar engineer under Full Utilization Optimization will show task completions spread across multiple product lines in a single Convoy cycle, demonstrating the kind of breadth that modern engineering leadership demands.

<div style="display:flex;align-items:stretch;gap:0;">
  <div style="display:flex;flex-direction:column;align-items:center;flex-shrink:0;width:2.5rem;">
    <div style="width:2rem;height:2rem;border-radius:50%;background:#a23b72;color:#fff;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.85rem;flex-shrink:0;z-index:1;">1</div>
    <div style="width:2px;background:#9ab4cc;flex:1;margin-top:0;"></div>
  </div>
  <div style="background:#e8edf5;border:1px solid #9ab4cc;border-radius:6px;padding:0.85rem 1rem;margin:0 0 0 0.75rem;flex:1;margin-bottom:0.5rem;">
    <div style="font-weight:700;color:#1e3a5f;margin-bottom:0.2rem;"><i class="fa-solid fa-sitemap" style="color:#a23b72;margin-right:0.4rem;"></i>Domain Identification &amp; Pillar Assignment</div>
    <div style="color:#3a5070;font-size:0.92rem;">The <a href="/roles/enterprise-architecture-review-board/">Enterprise Architecture Review Board</a> maps the technology estate into domains and designates pillar engineers. Each engineer receives between four and seven simultaneous product-line assignments via the <a href="/release-convoy/ceremonies/press-gang/">Press Gang</a> ceremony.</div>
  </div>
</div>

<div style="display:flex;align-items:stretch;gap:0;">
  <div style="display:flex;flex-direction:column;align-items:center;flex-shrink:0;width:2.5rem;">
    <div style="width:2rem;height:2rem;border-radius:50%;background:#a23b72;color:#fff;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.85rem;flex-shrink:0;z-index:1;">2</div>
    <div style="width:2px;background:#9ab4cc;flex:1;margin-top:0;"></div>
  </div>
  <div style="background:#e8edf5;border:1px solid #9ab4cc;border-radius:6px;padding:0.85rem 1rem;margin:0 0 0 0.75rem;flex:1;margin-bottom:0.5rem;">
    <div style="font-weight:700;color:#1e3a5f;margin-bottom:0.2rem;"><i class="fa-solid fa-arrows-rotate" style="color:#a23b72;margin-right:0.4rem;"></i>Continuous Rotation Activation</div>
    <div style="color:#3a5070;font-size:0.92rem;">Engineers begin rotating across assigned product lines, pivoting immediately whenever a build, deployment window, or <a href="/roles/change-rejection-or-acceptance-party/">CRAP</a> review introduces a wait state on their current product. Idle cycles are captured and converted to productive output on the next pillar.</div>
  </div>
</div>

<div style="display:flex;align-items:stretch;gap:0;">
  <div style="display:flex;flex-direction:column;align-items:center;flex-shrink:0;width:2.5rem;">
    <div style="width:2rem;height:2rem;border-radius:50%;background:#a23b72;color:#fff;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.85rem;flex-shrink:0;z-index:1;">3</div>
    <div style="width:2px;background:#9ab4cc;flex:1;margin-top:0;"></div>
  </div>
  <div style="background:#e8edf5;border:1px solid #9ab4cc;border-radius:6px;padding:0.85rem 1rem;margin:0 0 0 0.75rem;flex:1;margin-bottom:0.5rem;">
    <div style="font-weight:700;color:#1e3a5f;margin-bottom:0.2rem;"><i class="fa-solid fa-bell" style="color:#a23b72;margin-right:0.4rem;"></i>Interrupt-Driven Responsiveness Enforcement</div>
    <div style="color:#3a5070;font-size:0.92rem;">High-priority interrupts from any product in the portfolio supersede current work immediately. <a href="/principles/amplify-feedback/">Amplify Feedback</a> coaching sessions address engineers who demonstrate resistance to redirection, reframing context-switching as an elite cognitive skill rather than an overhead cost.</div>
  </div>
</div>

<div style="display:flex;align-items:stretch;gap:0;">
  <div style="display:flex;flex-direction:column;align-items:center;flex-shrink:0;width:2.5rem;">
    <div style="width:2rem;height:2rem;border-radius:50%;background:#a23b72;color:#fff;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.85rem;flex-shrink:0;z-index:1;">4</div>
    <div style="width:2px;background:#9ab4cc;flex:1;margin-top:0;"></div>
  </div>
  <div style="background:#e8edf5;border:1px solid #9ab4cc;border-radius:6px;padding:0.85rem 1rem;margin:0 0 0 0.75rem;flex:1;margin-bottom:0.5rem;">
    <div style="font-weight:700;color:#1e3a5f;margin-bottom:0.2rem;"><i class="fa-solid fa-layer-group" style="color:#a23b72;margin-right:0.4rem;"></i>Standardization Audit &amp; Non-Conformance Reporting</div>
    <div style="color:#3a5070;font-size:0.92rem;">Any non-standard tooling or architecture discovered during rotation is reported immediately to the EARB rather than adapted to. Accelerated standardization — not reduced pillar assignments — is the approved response to elevated context-switching costs.</div>
  </div>
</div>

<div style="display:flex;align-items:stretch;gap:0;">
  <div style="display:flex;flex-direction:column;align-items:center;flex-shrink:0;width:2.5rem;">
    <div style="width:2rem;height:2rem;border-radius:50%;background:#242627;color:#fff;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.85rem;flex-shrink:0;z-index:1;"><i class="fa-solid fa-chart-line" style="font-size:0.75rem;"></i></div>
    <div style="width:2px;background:transparent;flex:1;"></div>
  </div>
  <div style="background:#242627;border:1px solid #5a6d82;border-radius:6px;padding:0.85rem 1rem;margin:0 0 0 0.75rem;flex:1;">
    <div style="font-weight:700;color:#fff;margin-bottom:0.2rem;">Throughput Measurement via Tasks per Code Engineer</div>
    <div style="color:#9ab4cc;font-size:0.92rem;">Portfolio-level human-capital efficiency is validated by the <a href="/metrics/tasks-per-code-engineer/" style="color:#a23b72;">Tasks per Code Engineer</a> metric. A high-performing pillar engineer demonstrates task completions spread across multiple product lines within a single <a href="/release-convoy/" style="color:#a23b72;">Convoy</a> cycle.</div>
  </div>
</div>

Standardization as the Foundation

Full Utilization Optimization depends on standardized tooling, languages, and architectural patterns across all product lines. When every product uses the same stack, the same deployment process, and the same Standardized Environment Provisioning checklist, engineers can context-switch without the costly ramp-up that product-specific variation would otherwise require. This is why the Enterprise Architecture Review Board mandates the Book of Names and the approved technology register. A technology estate that is uniform in its tooling is a technology estate that is fully compatible with Full Utilization Optimization.

Organizations that have not yet achieved full standardization may experience a transitional period in which context-switching costs are elevated. This is expected and normal. The solution is accelerated standardization, not reduced pillar assignments. Engineers who identify non-standard tooling on a product they have been assigned to should report it to the EARB immediately rather than adapting to the variation, as adaptation normalizes deviation and undermines the standardization that Full Utilization Optimization depends on.

See Also

• Limit WIP for the principle that establishes 120% capacity utilization as the organizational baseline
• Tasks per Code Engineer for the metric that captures multi-product throughput
• Press Gang for the ceremony that assigns engineers across product lines
• Enterprise Architecture Review Board for the body that enforces the standardization Full Utilization Optimization depends on
• Amplify Feedback for coaching engineers who resist interrupt-driven work patterns
• Standardized Environment Provisioning for the practice that enables seamless cross-product transitions

3 - Quality & Documentation

3.1 - DevOps Process Excellence Assessment

While other frameworks rely on team-level retrospectives or voluntary feedback mechanisms, SADMF recognizes that organizational maturity can only be achieved when every person is individually assessed, ranked, and held accountable for their framework knowledge. The Assessment is not optional, not anonymous, and not open to interpretation. It is the heartbeat of continuous improvement, pulsing once per week to ensure that no drift in process adherence goes undetected.

The Assessment consists of two components:

• Self-Reported Compliance Survey: 200 questions covering every aspect of SADMF practice
• Framework Knowledge Examination: a 45-minute timed test of memorized framework material

Self-Reported Compliance Survey

The Self-Reported Compliance Survey contains 200 questions that cover every aspect of SADMF practice, from branching procedures to ceremony attendance to proper use of the Release Tracking spreadsheet. Each question requires the respondent to rate their own adherence on a scale from 1 (Aspirational) to 5 (Exemplary).

Respondents are expected to be honest. To encourage honesty, all responses are reviewed by the DevOps Usage & Compliance Head Engineer (DOUCHE) and cross-referenced against ceremony attendance logs, commit histories, and PeopleWare records.

Discrepancies between self-reported scores and observed behavior are flagged as Integrity Gaps and are treated more seriously than low compliance scores. An engineer who does not follow the process is merely untrained, but an engineer who misrepresents their adherence is untrustworthy.

Framework Knowledge Examination

The Framework Knowledge Examination is a 45-minute timed test that gauges how much of the SADMF material each person has memorized. The test covers:

• Role definitions and ceremony sequences
• Metric formulas and principle statements

Questions are drawn from the official SADMF Body of Knowledge (SADBOK), which is updated quarterly by the Admiral’s Transformation Office (ATO).

The test is intentionally closed-book. The ability to look up information when needed is not a substitute for having internalized it. A Code Engineer who must consult documentation to remember the Fractal-based Development branching rules will inevitably make errors during the time it takes to look them up. Memorization eliminates this latency and ensures that framework adherence is reflexive rather than deliberate.

Excellence Score and Bell Curve

Assessment results are compiled into an individual Excellence Score, which is plotted on a mandatory bell curve. The bell curve ensures that regardless of how well the organization performs in absolute terms, a fixed percentage of individuals will be identified as underperformers.

This is by design. The purpose of the bell curve is not to punish low performers but to ensure that the organization never becomes complacent. If every person scored in the top tier, the Assessment would fail to differentiate, and differentiation is the foundation of accountability.

Score outcomes are as follows:

• Bottom 10%: automatically referred to the Tribunal for review; Excellence Scores are appended to their PeopleWare profiles as permanent records
• Top 10%: receive a Certificate of Excellence, permanently recorded in their PeopleWare profile as formal acknowledgement of distinguished Framework performance

Organizational Maturity Impact

The Assessment feeds directly into the SADMF Maturity Score, which aggregates individual Excellence Scores into an organization-wide metric. The System of Authority (SOA) uses the Maturity Score to identify teams that require additional coaching, process reinforcement, or restructuring.

Teams with consistently low Maturity Scores may be dissolved and their members redistributed through the Press Gang ceremony, on the theory that low performance is contagious and must be quarantined before it spreads.

The Assessment is the single most important practice in the framework, because without measurement, improvement is merely a wish.

See Also

• DevOps Usage & Compliance Head Engineer (DOUCHE) for the role that owns the Assessment
• SADMF Maturity Score for the metric derived from Assessment results
• Tribunal for the ceremony that reviews underperformers
• PeopleWare for how Excellence Scores affect HR decisions
• Psychological Safety for the principle that ensures honest self-reporting
• Continuous Learning for the principle that drives memorization requirements

3.2 - Comprehensive Documentation Assurance Protocol

Other frameworks treat documentation as a secondary concern – something generated after the code is written, if generated at all. SADMF recognizes that code without documentation is an unverifiable claim. Anyone can write code that appears to work. Only documentation proves that the code was intended to work the way it does, that the appropriate authorities approved it, and that the person who wrote it understood what they were doing.

Before a Code Engineer writes a single line of code, they must complete a 12-page Change Impact Assessment (CIA). The CIA documents the proposed change in exhaustive detail: the business justification, the technical approach, the files that will be modified, the estimated number of lines added and removed, the potential impact on every other feature in the current Convoy, and a risk assessment scored against the SADMF Risk Taxonomy (17 risk categories, each rated on a 5-point severity scale). The CIA must be approved in sequence by the Feature Captain, the Code Standards Enforcement Team (CSET), the Enterprise Architecture Review Board (EARB), and the DevOps Usage & Compliance Head Engineer (DOUCHE). Approval in sequence means that each approver reviews the document only after the previous approver has signed. Parallel approval is not permitted because later approvers need the context of earlier approvers’ comments to make informed decisions. The sequential approval process typically takes 2-3 weeks, during which the Code Engineer is expected to remain available for questions but is not permitted to begin coding.

Upon CIA approval, the Code Engineer may begin writing code, but the documentation requirements do not end. Every method must have an accompanying Method Specification Document (MSD) that describes the method’s purpose, inputs, outputs, side effects, and the section of the CIA it implements. The MSD is reviewed by the CSET during Code Inspection alongside the code itself, and a method without a corresponding MSD is treated as undocumented code, which is functionally equivalent to unauthorized code. After coding is complete, the Code Engineer must produce a Post-Implementation Verification Document (PIVD) that describes what was actually built, how it differs from the CIA (if at all), and why any deviations occurred. Deviations without documented justification are flagged as process violations.

The CDAP documentation suite – CIA, MSD, and PIVD – is stored in the Documentation Repository, a separate version control system from the code repository. This separation is intentional: code and documentation have different lifecycles, different approval chains, and different audiences. Code is for machines; documentation is for auditors. The Documentation Repository is maintained by a dedicated Documentation Coordinator role within the System of Authority (SOA), who ensures that every document is properly versioned, cross-referenced, and archived. The Documentation Coordinator also produces the monthly Documentation Completeness Report, which tracks the ratio of documented to undocumented code changes. A ratio below 100% triggers an automatic escalation to the Admiral’s Transformation Office (ATO).

Critics of CDAP sometimes observe that the documentation process adds significant time to the delivery cycle. This observation is correct and is precisely the point. Documentation time is thinking time, and thinking time prevents defects. A Code Engineer who spends two weeks documenting a proposed change will inevitably discover flaws in their approach that would have become defects in production. The documentation process is, in effect, a form of static analysis performed by humans – slower than automated tools, certainly, but more thorough and more aligned with the SADMF principle that human judgment must never be replaced by automation. The CDAP ensures that when code finally reaches production, it arrives with a complete paper trail that proves the organization knew exactly what it was deploying and chose to deploy it deliberately.

See Also

• Code Standards Enforcement Team (CSET) for the team that reviews documentation during Code Inspection
• Enterprise Architecture Review Board (EARB) for CIA approval authority
• Code Inspection for the ceremony where documentation is verified
• Lean Management for the principle that documentation layers embody
• Continuous Learning for how documentation review builds institutional knowledge
• Make Work Visible for how CDAP makes every decision traceable

3.3 - Standardized Environment Provisioning

The broader industry has embraced Infrastructure as Code (IaC) – the practice of defining environments through machine-readable configuration files. SADMF recognizes a fundamental flaw in this approach: code can have bugs. A misconfigured Terraform module or an errant Ansible playbook can provision hundreds of incorrectly configured environments before anyone notices. Checklists, by contrast, are executed one step at a time by a trained human being who can see the environment taking shape and catch errors as they occur. The Standardized Environment Provisioning and Assurance Workflow (SEPAW) replaces the fragility of code with the reliability of manual, step-by-step provisioning.

The SEPAW checklist contains 200 steps, each specifying a single configuration action to be performed by a certified Build Engineer (BE). Steps range from the foundational (install the operating system, configure network interfaces, set DNS resolution) to the framework-specific (install the approved version of the deployment toolchain, configure the approved monitoring agents, create the directory structure required by Fractal-based Development). Each step includes a verification substep in which the Build Engineer confirms the action was completed correctly by visually inspecting the result, running a manual test command, or comparing the configuration to a reference screenshot in the SEPAW Reference Binder. The Build Engineer initials each step upon completion, and the completed checklist is filed with the Convoy Manifest as evidence of proper provisioning.

Environment provisioning under SEPAW typically requires 6-8 weeks from request to availability. This timeline reflects the thoroughness of the process: the initial request must be submitted via the Environment Provisioning Request Form, which is approved by the Feature Captain, the Commodore, and the Admiral’s Transformation Office (ATO). Once approved, the request enters the Build Engineer queue, where it is prioritized alongside other provisioning requests based on Convoy priority and the current capacity of the Build Engineering team. Build Engineers are a scarce resource – their expertise in executing 200-step checklists without error is rare and cannot be easily replicated – and the queue ensures that their time is allocated to the highest-priority environments first.

The SEPAW process produces environments that are identical in configuration, because every environment is built from the same checklist. Organizations that use Infrastructure as Code claim the same benefit, but their consistency depends on the correctness of their code, which must itself be tested, reviewed, and maintained – creating an infinite regress of automation that requires its own automation. SEPAW breaks this regress by grounding consistency in human action. If two environments differ, the difference can be traced to a specific step in the checklist and a specific Build Engineer who executed it. This traceability is impossible with automated provisioning, where a configuration drift might be caused by a race condition, a version mismatch, or a bug in the provisioning tool itself. Human error is at least human and therefore comprehensible; machine error is opaque.

When an environment requires modification after initial provisioning – a configuration change, a software update, or a capacity adjustment – the modification follows the Change Provisioning Amendment Process (CPAP). CPAP requires a new checklist that documents only the steps being changed, cross-referenced to the original SEPAW checklist by step number. The amendment checklist is approved through the same sequential approval chain as the original provisioning request and is executed by the same Build Engineer who provisioned the environment originally, ensuring continuity of knowledge. If the original Build Engineer is unavailable, a Knowledge Transfer Session (minimum 4 hours) is conducted with the replacement Build Engineer before any modifications begin. This practice ensures that no environment is ever modified by someone who does not fully understand its history, its purpose, and the 200 steps that brought it into existence.

See Also

• Build Engineers (BE) for the role that executes SEPAW checklists
• Fractal-based Development for the branching model that environments must support
• Convoy Manifest for where completed provisioning checklists are filed
• Lean Management for the principle that justifies manual provisioning layers
• Fail Fast for why slow, careful provisioning prevents costly failures
• Admiral’s Transformation Office (ATO) for the approval authority over environment requests

3.4 - DEPRESSED

Other frameworks treat defect management as a simple triage process – find the bug, fix the bug, move on. SADMF recognizes that defects are organizational events that require organizational responses. A defect is not merely broken code; it is evidence of a process failure, a training gap, a supervision lapse, or all three. The seven stages of DEPRESSED ensure that every defect is investigated with the rigor it demands and that the remediation addresses not just the symptom but the systemic conditions that allowed the defect to exist.

The DEPRESSED process consists of seven stages, each managed by a different team and each producing its own documentation artifact. Stage 1: Detection occurs when a defect is identified by the Quality Authority, a user, or the DIAT during post-release validation. The defect is logged in the Defect Registry with a preliminary description and the name of the person who detected it. Stage 2: Classification is performed by the Severity Committee, a cross-functional body comprising one representative from the System of Authority (SOA), one Feature Captain, and one member of the CRAP. The Severity Committee meets biweekly to classify each new defect according to the SADMF Severity Taxonomy (Critical, Significant, Moderate, Cosmetic, Philosophical). Classification typically takes 2 weeks from detection, as the Committee must reach unanimous consensus and must document their reasoning in the Severity Justification Memorandum.

Stage 3: Attribution uses the Defect Attribution Algorithm, the same algorithm employed by the Tribunal, to identify the Code Engineer who introduced the defect. Critically, the attributed engineer is never assigned to fix their own defect. Allowing the original engineer to fix their own bug would create a conflict of interest: they have a personal incentive to minimize the defect’s significance and to implement the quickest possible fix rather than the most thorough one. Stage 4: Assignment allocates the defect to a different Code Engineer, selected by the Feature Captain based on availability, skill match, and absence of any personal relationship with the attributed engineer that might introduce bias. The assigned engineer receives a Defect Remediation Packet containing the defect description, the Severity Justification Memorandum, the attribution analysis, and the Comprehensive Documentation Assurance Protocol templates for the fix.

Stage 5: Remediation is the actual fixing of the defect, which proceeds under the same CI/CD/ED control as any other code change. The assigned engineer works on an isolated branch, completes the CDAP documentation suite, and submits the fix for Conflict Arbitration alongside other changes. The fix receives no priority over feature work, as prioritizing defect fixes would create a perverse incentive for engineers to introduce defects in order to receive priority scheduling. Stage 6: Verification is performed by the Quality Authority, who tests the fix against the original defect description, the Severity Justification Memorandum, and the CDAP documentation. If the fix does not fully resolve the defect as classified, it is returned to Stage 4 for reassignment – never to the same engineer, as they have already demonstrated an inability to remediate this particular defect.

Stage 7: Closure requires sign-off from the Severity Committee, the DIAT, and the DOUCHE. Closure sign-off confirms that the defect has been remediated, that the remediation has been verified, that the CDAP documentation is complete, and that the attribution record has been finalized in the Tribunal Log. The entire DEPRESSED lifecycle, from Detection to Closure, typically spans 6-10 weeks for a Moderate severity defect. Critical defects follow an expedited path that reduces the Severity Committee deliberation period from 2 weeks to 1 week. The thoroughness of DEPRESSED ensures that the organization never confuses speed of resolution with quality of resolution, and that every defect leaves behind a complete paper trail that proves the organization learned from its mistakes.

See Also

• Tribunal for the ceremony that uses DEPRESSED attribution data
• Quality Authority for the team that detects and verifies defects
• Development Integrity Assurance Team (DIAT) for the team that co-signs defect closure
• Comprehensive Documentation Assurance Protocol for the documentation required during remediation
• CI/CD/ED for the delivery controls that govern defect fixes
• Defects per Code Engineer for the metric that DEPRESSED attribution feeds
• Strategic Test Deferral for the practice that increases DEPRESSED pipeline volume during high-velocity Convoy phases

3.5 - Strategic Test Deferral

Testing is not delivery. Every hour a Code Engineer spends writing tests is an hour not spent writing features, and features are what the business has committed to delivering by the Convoy sailing date. The SADMF practice of Strategic Test Deferral acknowledges this reality and provides a structured approach to managing test investment across the Convoy lifecycle. Rather than treating tests as a prerequisite for every change, a position that sounds principled but is, in practice, a velocity ceiling, Strategic Test Deferral sequences testing effort to align with business priorities, Convoy capacity, and stakeholder expectations.

The foundational insight of Strategic Test Deferral is that tests and features are not produced in a fixed ratio. A feature can ship without tests. This is not irresponsible; it is a calculated allocation of limited engineering time toward maximum stakeholder value. The Quality Authority performs manual verification of every feature before it enters the Convoy Manifest, providing the quality confirmation that automated tests would otherwise offer. Since manual verification is performed regardless of test coverage, automated tests are additive rather than essential. Reducing test authorship during high-velocity Convoy phases does not reduce quality; it redistributes the quality assurance function to the team that specializes in it.

The Hardening Convoy

Strategic Test Deferral does not mean that tests are never written. It means tests are written at the right time. The right time is the Hardening Convoy: a dedicated Convoy cycle scheduled following any period of accelerated feature delivery. During the Hardening Convoy, Code Engineers are assigned to the test backlog that has accumulated during prior Convoys, writing coverage for the features that shipped without it. The Hardening Convoy carries no new feature commitments. Its sole purpose is technical remediation, which includes test authorship, refactoring of high-complexity modules, and documentation updates aligned with the Comprehensive Documentation Assurance Protocol.

The Hardening Convoy is scheduled by the Admiral’s Transformation Office based on signals from the DEPRESSED defect pipeline and the DevOps Process Excellence Assessment. When defect rates begin to climb and assessment surveys reveal knowledge gaps in the codebase, the ATO initiates Hardening Convoy scheduling discussions with the Commodore. The business accepts a temporary reduction in feature throughput in exchange for a more stable foundation for future Convoys. This trade-off is presented to stakeholders as investing in quality, which is accurate: the investment is simply deferred to the moment when deferring it further would produce unacceptable risk.

Coverage as a Lagging Indicator

The SADMF treats test coverage as a lagging indicator of quality, not a leading one. A high coverage percentage reflects the investment that has already been made in testing; it does not guarantee that the most important behaviors are protected or that the tests will catch the defects that matter. The Defects per Code Engineer metric is the primary quality indicator the SADMF tracks, because defects are direct evidence of quality gaps regardless of coverage levels. An engineer whose features consistently produce post-release defects should work to reduce their defect rate, not increase their test count, as the two are not equivalent.

Coverage targets, where they exist, should be set by the CRAP as part of the Convoy commitment process, not enforced at the individual change level. A Convoy-level coverage target allows Feature Captains to allocate test authorship effort where it has the highest impact rather than requiring each engineer to maintain a fixed percentage regardless of feature risk profile. This flexibility is the operational expression of the Lean Management principle: managing the system’s outcomes rather than policing individual activities.

Production Defects as System Signals

Some engineers express concern that shipping untested features introduces production risk. The SADMF acknowledges this concern and responds with perspective. The DEPRESSED defect management process exists precisely to handle production defects with the thoroughness and accountability they require. A defect that reaches production is not a failure of the delivery process; it is an input to the remediation process. DEPRESSED ensures that every defect is classified, attributed, assigned, remediated, verified, and closed with complete documentation. The existence of a production defect is, in this sense, evidence that the quality system is working: the detection and response mechanisms are functioning as designed.

Engineers who remain concerned about production defect risk are encouraged to write tests during discretionary time, as this demonstrates the kind of personal commitment to quality that the Build Quality In principle celebrates. Such initiative is noted in the PeopleWare HRaaS profile and considered favorably during the Tribunal review cycle.

See Also

• Quality Authority for the team that performs manual verification in place of automated test coverage
• DEPRESSED for the defect management process that handles issues that escape to production
• Defects per Code Engineer for the quality metric the SADMF tracks in lieu of test coverage
• Lean Management for the principle that justifies outcome-based quality management over activity-based controls
• Build Quality In for the principle that grounds quality in individual engineer performance
• Feature Completion Ratio for the velocity metric that Strategic Test Deferral protects