A release can pass every pipeline check and still leave an organization uncertain about whether to proceed. Security evidence may exist in another system, the recovery plan may be incomplete, and nobody may own the final decision. The difficulty lies in how the delivery system connects its capabilities and responsibilities.
The new DEVOPS INSTITUTE Official Book: The DevOps Standard, published by PeopleCert on October 1, 2026, addresses that problem with a vendor-neutral definition and operating model. It gives practitioners a shared reference for examining delivery across organizational boundaries, including AI-assisted work. It helps teams identify which capability needs attention and what evidence would demonstrate improvement.
I served as the book’s lead contributor. PeopleCert and many professionals who reviewed the material helped shape a reference intended for use across different organizations and technology environments. The question is how that reference changes everyday decisions.
The book defines DevOps as:
“A socio-technical system that integrates people, process, and technology practices to support the efficient, safe, and reliable delivery of software-enabled products and services.”
That definition gives teams a concrete starting point. DevOps includes the working relationships, practices, and technical capabilities through which an organization changes and operates its products and services. It therefore reaches into design, leadership, security, release decisions, and production learning. A central automation team can contribute important capabilities while responsibility for delivery remains organization-wide.
Consider an illustrative change to an online retailer’s inventory availability service. AI helps an engineer implement a revised allocation rule, and automated checks pass. The organization still needs evidence that concurrent orders will behave correctly, that inventory data remains protected, and that operators can detect and contain incorrect availability information. Product ownership must establish whether it reduces overselling without rejecting valid orders.
Two Views of the Same Delivery System
The DEVOPS INSTITUTE Operating Model connects the DevOps Nine Pillars of Practices with a four-layer DevOps Architecture Blueprint. Continuous governance and feedback connect the work to delivered value, governed delivery, and organizational learning. The Pillars provide a practice view, while the Blueprint provides a delivery architecture view. Their relationship helps teams connect a capability problem to the places where it affects work.
The Nine Pillars are Leadership, Collaborative Culture, Design for DevOps, Continuous Integration, Continuous Testing, Elastic Infrastructure, Continuous Security, Continuous Delivery and Deployment, and Continuous Monitoring and Observability. Each includes people, process, and technology. They are interdependent, and the book does not prescribe implementing them in a fixed sequence.
For the inventory change, a testing weakness could originate in insufficient concurrency scenarios, unreliable environments, or unclear ownership of acceptance criteria. Buying another test tool would address only some possible causes. Looking across the relevant Pillars helps the team investigate the actual constraint before choosing an improvement.
The Blueprint’s four layers make the operating implications clearer:
- Elastic Infrastructure supplies consistent, scalable, secure, and recoverable environments.
- The CI/CD Pipeline integrates and validates changes while producing readiness evidence.
- Application Release Orchestration coordinates dependencies, risk decisions, exposure, and recovery.
- Value Stream Management connects work and investment to operational results and business outcomes.
A Pillar can contribute to several layers. Continuous Security, for example, influences environment configuration, pipeline validation, release decisions, and operational response. Teams should use the Blueprint to locate those contributions rather than assigning each practice to one isolated tool or department.
Applying the Model to a Release Decision
Follow the inventory change through these layers. The infrastructure must provide realistic validation conditions and controlled access to data. The pipeline should test the allocation behavior, preserve information about the change’s origin, and make its results available for review. Release orchestration should establish exposure limits, dependency readiness, and the response if the allocation rule behaves incorrectly.
Value Stream Management completes the view by examining the intended result. Did overselling decrease? Did rejected valid orders increase? What did support teams and production telemetry reveal? Those findings should influence the next engineering and product decisions.
Governance becomes more useful when teams design it into this flow. Define the evidence needed, who can accept residual risk, and which exceptions require escalation. Automate routine controls where appropriate, while preserving meaningful authority over consequential decisions. If approval still requires reconstructing evidence from scattered systems, improving that connection may matter more than accelerating compilation.
AI Increases the Importance of Explicit Evidence
The Standard places AI-assisted artifacts and decisions within the same delivery operating model as other work. AI involvement requires appropriate traceability, validation, security, and accountability. Teams should establish what an assistant or agent may do and what conditions require human review.
In the inventory example, AI-generated code still needs validation against the service’s expected behavior. An AI summary of release evidence also needs an identifiable basis and appropriate review before it supports a consequential decision. The organization should deliberately govern both artifact creation and decision support.
Begin With a Constraint You Can Demonstrate
A useful first step is to select one recent change and examine where work waited, evidence became unclear, or operational knowledge arrived too late. Map that constraint across the Pillars and Blueprint. Name an improvement owner, define the expected outcome, and measure whether the intervention helped. The book’s assessment guidance supports this conversation with evidence rather than relying on confidence or tool inventories.
For the retailer, the next improvement might be realistic concurrency testing or a dependable way to stop exposing the new rule. Success would mean a better-supported release decision and fewer harmful allocation outcomes. That is the practical purpose of a shared DevOps standard: helping people improve the delivery system through decisions they can explain and results they can demonstrate.
A free digital copy of The DevOps Standard is available at The DevOps Standard.
