This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Delivery

Practices governing how code flows from engineer to production, with appropriate isolation and deliberation at every stage.

1 - CI/CD/ED

Continuous Isolation / Continuous Deliberation / Eventual Delivery is the most effective way to ensure perfection for every change!

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.

CI
Continuous
Isolation
Phase One
CD
Continuous
Deliberation
Phase Two
ED
Eventual
Delivery
Phase Three
① CI Continuous Isolation

Continuous Isolation is the practice of ensuring that every Code Engineer works on a dedicated, long-lived feature branch that remains completely separated from all other work until the feature is fully complete, inspected, tested, and approved. This isolation prevents the catastrophic risk of one engineer’s incomplete work contaminating another engineer’s incomplete work, which would produce a compounding effect of incompleteness that no amount of testing could untangle. The Source Management Team (SMT) enforces isolation by controlling all branch creation through the Fractal-based Development branching model. Code Engineers are not granted permission to create their own branches, merge their own code, or even view the branches of other engineers, as awareness of others’ work could lead to unauthorized coordination. Continuous Isolation has been validated by the observation that the longer code remains isolated, the more exciting the eventual integration becomes, and excitement is a leading indicator of organizational engagement.

② CD Continuous Deliberation

Continuous Deliberation replaces the reckless practice of automated deployment pipelines with a structured decision-making process that ensures every change is evaluated by the appropriate authorities before proceeding to the next stage. Each stage of the DevOps Release Convoy includes dedicated deliberation ceremonies: Code Inspection by the Code Standards Enforcement Team, Testing by the Quality Authority, validation by the Development Integrity Assurance Team, and final approval by the Change Rejection or Acceptance Party (CRAP). At no point does code advance without a human deliberately choosing to advance it. Automation is permitted only for tasks that do not matter, such as sending email notifications about meetings. Tasks that do matter – building, testing, deploying, and approving – must be performed by accountable individuals who can be held responsible when things go wrong.

③ ED Eventual Delivery

Eventual Delivery is the natural outcome of practicing Continuous Isolation and Continuous Deliberation at scale. Code will be delivered when it is ready, and it will be ready when every ceremony has been completed, every checklist has been signed, and every authority has granted approval. The timeline for delivery is determined not by arbitrary business deadlines but by the thoroughness of the process. Organizations that attempt to impose delivery dates on the process are, in effect, asking the process to cut corners, and cutting corners is how defects are born. The Commodore tracks the progress of each Convoy against the original 8-quarter forecast, and any deviation from the forecast is addressed not by accelerating the process but by adjusting the forecast. This ensures that the Feature Completion Ratio metric remains healthy and that the Chief Signals Officer can report positive trends to the Admiral’s Transformation Office.

End-to-End CI/CD/ED Process
1
SMT Creates Isolated Branch
Source Management Team provisions a long-lived feature branch using the Fractal-based Development naming convention
2
Code Engineer Works in Complete Isolation
No cross-branch visibility, no merging, no unauthorized coordination with other engineers until feature is fully complete
3
Conflict Arbitration
SMT merges all candidate branches simultaneously; the strongest change survives the Arbitration Hearing
4
Code Inspection Ceremony
Code Standards Enforcement Team conducts manual review; no automation permitted for consequential tasks
5
Manual Testing & Meta-Validation
Quality Authority tests; Development Integrity Assurance Team validates the testers; documentation verified at each stage
6
CRAP Unanimous Approval
Change Rejection or Acceptance Party renders binding decision; unanimous vote required before any change may advance
7
Convoy Release
Code reaches production when every ceremony is complete and every checklist is signed; timeline determined by thoroughness, not deadlines
8
Forecast Adjusted to Match Outcome
Commodore updates 8-quarter forecast; Feature Completion Ratio remains healthy; Chief Signals Officer reports positive trends

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

2 - Conflict Arbitration

Darwinian source control ensures only the strongest change survives!

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:

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

3 - Fractal-based Development

This elegant branching pattern provides the structure required for disciplined delivery at scale!

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.

Branch Lifecycle: Prescribed Stages

1
Branch Provisioning DEVELOP → FEATURE

The Source Management Team (SMT) creates a uniquely named feature branch from the clean Develop branch. Code Engineers submit a Branch Creation Request Form and await provisioning confirmation before commencing work.

2
Isolated Development FEATURE (isolated)

The Code Engineer works within their isolated branch for the full duration of the Coding Ceremony. No synchronization with other branches is permitted. Upon completion, the engineer obtains a Coding Completion Certificate from their Feature Captain.

3
Conflict Arbitration FEATURE → CONFLICT

All certified feature branches are merged by the SMT into the Conflict branch. Overlapping changes are adjudicated via Conflict Arbitration, where the strongest changes survive. Losing changes are archived for compliance purposes.

4
Manual Quality Certification CONFLICT → TEST

Surviving changes are pulled into the Test branch by the Quality Authority (QA) for manual certification. The Test branch exists in a perpetual state of testing; automated testing is prohibited as it bypasses the human judgment foundational to quality assurance.

5
Meta-Validation TEST → VALIDATION

Certified code is forwarded to the Development Integrity Assurance Team (DIAT) on the Validation branch. The DIAT validates that the Quality Authority tested correctly — a critical meta-testing layer that guards against errors in testing itself.

Release Convoy Authorization VALIDATION → DORC™

DIAT-approved code is authorized for inclusion in the next DevOps Release Convoy (DORC™). The code sets sail on the next scheduled convoy departure, coordinated by the SMT.

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

4 - Multi-Trunk Based Development (Pando)

The correct vocabulary for Trunk Based Development at enterprise scale: every branch is a trunk, and every trunk is accounted for in the Pando fleet registry!

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:

Pando Term Fractal-based Development Name Description
Root Trunk Production The single canonical production-ready target. Code reaches this trunk only after ascending the full certification hierarchy.
Convoy Trunk Develop branch One per active Convoy, branched from the Root Trunk at Convoy start. The Convoy Trunk advances through certification stages before it is authorized for merge to the Root.
Feature Trunk Feature branch One per feature, named per the SMT naming convention (CONVOY-[number]-[feature-id]-[engineer-initials]-[date]). Created by the SMT; never by the Code Engineer directly.
Emergency Trunk Hotfix branch Provisioned on demand for changes that cannot wait for the next Convoy. Branched directly from the Root Trunk and subject to an expedited but otherwise complete approval process.

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