The shared responsibility model — the synthesis

The shared responsibility model is the synthesis of the five previous lessons. A single pull request activates every role: the application team writes the code and manifest, the platform team runs the paved road, the security team runs the policy as code, the reviewer checks correctness, the approver checks production readiness. The pull request is the unit that joins the five roles into one auditable change. The operating model is not a slide; the operating model is the pull request itself.

The change as the unit

The pull request is the unit that activates every role. The PR has an author (the application team), a diff (the code and manifest), a CI run (the platform team’s paved road plus the security team’s policy), a reviewer (the engineer who checks correctness), an approver (the CODEOWNERS-listed owner who checks production readiness), and a merge record (the audit chain). Every role from the five previous lessons is visible on the pull request.

flowchart TB
    subgraph PR["Pull request"]
        A["Author:\napplication team"]
        D["Diff:\ncode + manifest"]
    end
    subgraph RUN["CI run"]
        PIPE["Platform team:\npaved-road CI"]
        SEC["Security team:\npolicy as code"]
    end
    subgraph HUMAN["Human gate"]
        REV["Reviewer:\ntechnical correctness"]
        APP["Approver:\nproduction readiness\n(CODEOWNERS)"]
    end
    A --> D
    D --> PIPE
    D --> SEC
    PIPE -->|"pass"| HUMAN
    SEC -->|"pass"| HUMAN
    REV -->|"approved"| MERGE["Merge to default branch"]
    APP -->|"approved"| MERGE
    MERGE --> DEPLOY["GitOps controller reconciles"]
    DEPLOY --> AUDIT["Audit chain:\nPR, CI, signature, deploy"]

The shared responsibility is visible in the pull request itself: the author’s name is on the commit; the reviewer’s comment and approval are on the PR; the approver’s approval is on the PR; the CI status is on the PR; the CODEOWNERS rule is on the PR; the merge commit is on the default branch; the deploy event is on the cluster. The audit chain reads from the PR outward.

The named ownership of every artefact

The operating model names an owner for every artefact in the pull request. The naming is structural, encoded in CODEOWNERS, and auditable.

• Application code. Application team. Authored by the application engineer; reviewed by a peer; the CODEOWNERS entry for /services/<app>/ names the team.
• Application manifest. Application team. The manifest is the team’s statement of how the service should run; the platform team owns the template, not the manifest.
• CI workflow. Platform team. The workflow is in /.github/workflows/; CODEOWNERS lists the platform team. The application team triggers it; the platform team owns its behaviour.
• Security policy. Security team. The policy is in the security team’s repository; the platform team consumes a versioned tag and runs it in CI.
• Infrastructure contract. Infrastructure team. The contract names the IAM role, the network, and the base image; the platform team consumes a versioned release.
• Review. The reviewer. Any engineer; the review comment is the record.
• Approval. The approver. CODEOWNERS-listed owner for the directory; the approval is the production- readiness record.

Every artefact has a named owner. The named owner is the source of accountability; the accountability is the audit chain.

The audit-chain failure modes

A team that has the operating model on a slide but not in the pull request produces one of three audit-chain failure modes:

1. The author is anonymous. A commit with no signature, an email that does not resolve to a team member, or a personal access token instead of an OIDC identity. The audit chain cannot identify the author.
2. The reviewer is a rubber stamp. An approval with no review comment, a self-approval, or an approval from an off-team engineer. The audit chain cannot confirm the second lens.
3. The approver is unavailable. A CODEOWNERS entry that names a single engineer who has left, or a branch-protection rule that allows merging without an approver.

The fix is structural: enforce the rule in branch protection, validate the signature in CI, require the review comment in CI, validate CODEOWNERS against the team roster quarterly.

The pull request from open to deploy

A worked example. An application engineer opens a pull request against /services/api/. The diff adds an endpoint and updates the manifest. The CI runs the paved-road workflow from /.github/workflows/, which invokes the security policy from the security team’s repository at the pinned version. SAST, SCA, SBOM, and signature checks pass. A peer reviews; the CODEOWNERS-listed approver checks the production-readiness checklist and approves. The pull request merges; the GitOps controller reconciles; the deploy event records the SHA, the build URL, the actor, the environment, and the timestamp. The audit chain is complete.

Every role is visible on the pull request: author and diff (application); CI workflow, registry push, and reconcile (platform); policy and SAST/SCA/SBOM/signature checks (security); review comment and technical-correctness check (reviewer); production- readiness check and CODEOWNERS match (approver); IAM role, network, and base image the workflow assumed (infrastructure). The pull request is the operating model, the audit chain, and what the postmortem reads six months later.

Production discipline

1. Source every ownership from CODEOWNERS. The branch-protection rule enforces it.
2. Treat the pull request as the audit-chain unit. The PR is the join key from code to production.
3. Validate the operating model quarterly. A CODEOWNERS file that has drifted from the roster is an audit chain about to break.
4. Surface the operating model in the postmortem. Name the role whose discipline prevented the incident from being worse.

Cross-course references

• This course, Part CVII (ProductionArch) is the seven-component architecture the operating model owns.
• This course, Part CVI (ChangeMgmt) is the change record the operating model produces.
• Linux for Production Sysadmins - Part XXXIV (ConfigMgmt) covers the same operating model at the configuration level.

Quiz