Shared Responsibility Model

The previous lesson turned renting’s cost into money and counted one item by name: operating labor. Under own hardware that labor is a single number, and all of it belongs to the organization. Under renting, part of it passes to the provider — but exactly which part? This lesson draws that boundary and counts what sits not on either side of the line, but on it.

Shared responsibility is the split, between provider and customer, of the work required to keep a service up and secure. It takes the same shape as M20’s handoff agreement, but the boundary sits elsewhere: there it split between the team that writes the work and the team that runs it, and both sides belonged to the same organization; here, the other side of the boundary is a contract, and the other party does not sit at the table. This difference produces one new class: an item can belong to no one at all.

The Responsibility Matrix

The example is the course’s fictional regional measurement network: the reading collector, the validator, billing and work-order services, a nightly batch job, five teams. Both the network and the services are fictional; the matrix below is a model, and there is no real provider, contract, or incident record.

CC25: the responsibility matrix is 24 items; in each of the three service models, every item sits with the provider, with the customer, or is shared. CC26: a shared item behaves in one of three ways — solid (both sides take their own share), gap (both sides think the other does it, and no one does), overlap (both do it, and which one governs is unclear); this tendency belongs to the item and is independent of the model. CC27: there are eight incidents, and each incident touches three items. CC28: the incident’s rounds depend on the item’s class — 1 at the provider, 1 at the customer, 2 for a solid shared item, 3 for an overlap, 8 for a gap; a gap item is built from scratch during the incident. CC29: an incident that touches even one gap item closes with data loss. CC30: at exit, items that stay with the customer carry over; items at the provider or shared are renegotiated with the new provider.

// cloud/responsibility.mjs — the shared responsibility matrix for the fictional measurement
// network (model): no real provider, real contract, or real incident record exists. No randomness.

export const MODEL = ["infrastructure", "platform", "software"];
// Columns: infrastructure platform software. S at the provider, M at the customer, P shared.
// tendency: how a shared item behaves — solid / gap / overlap.
export const ITEM = `
  physical-security        S S S  solid
  host-patch               S S S  solid
  guest-os-patch           M S S  solid
  application-patch        M M S  solid
  network-rule             P P S  gap
  edge-protection          P P S  overlap
  encryption-at-rest       M P S  solid
  encryption-in-transit    P P S  overlap
  key-management           M P P  gap
  identity-and-access      M M M  solid
  backup-creation          M P S  solid
  restore-drill            M M M  gap
  log-collection           M P P  solid
  log-retention            M M P  gap
  alert-threshold          M M M  solid
  incident-first-response  M P P  overlap
  incident-root-cause      P P P  gap
  capacity                 M P S  solid
  image-distribution       M S S  solid
  configuration-audit      M M P  gap
  data-classification      M M M  solid
  data-deletion            M P P  gap
  component-scanning       M M P  solid
  disaster-drill           M P P  overlap`
  .trim().split("\n").map((r) => {
    const [name, ...k] = r.trim().split(/\s+/);
    return { name, tendency: k[3], cell: Object.fromEntries(MODEL.map((m, i) => [m, k[i]])) };
  });

// Resolution: if the contract value is P, the item's tendency decides the class.
export const classify = (k, m) =>
  (k.cell[m] === "P" ? { solid: "sha", gap: "GAP", overlap: "OVE" }[k.tendency]
    : k.cell[m] === "S" ? "pro" : "cus");
export const CLASS = ["pro", "cus", "sha", "GAP", "OVE"];
export const count = (m, c) => ITEM.filter((k) => classify(k, m) === c).length;

// Incident rounds: however many rounds the item's class takes. A gap item is rebuilt from scratch mid-incident.
export const ROUND = { pro: 1, cus: 1, sha: 2, OVE: 3, GAP: 8 };

export const INCIDENT = `
  leak-suspicion      log-collection log-retention incident-root-cause
  data-loss           backup-creation restore-drill data-classification
  external-scan       network-rule edge-protection incident-first-response
  key-expiry          encryption-in-transit key-management alert-threshold
  unauthorized-access identity-and-access log-collection incident-root-cause
  patch-gap           guest-os-patch component-scanning image-distribution
  misconfiguration    configuration-audit network-rule incident-first-response
  broad-outage        disaster-drill capacity restore-drill`
  .trim().split("\n").map((r) => {
    const [name, ...k] = r.trim().split(/\s+/);
    return { name, item: k.map((x) => ITEM.find((y) => y.name === x)) };
  });

export function run(m) {
  const incidents = INCIDENT.map((o) => {
    const c = o.item.map((k) => classify(k, m));
    return { name: o.name, rounds: c.reduce((a, x) => a + ROUND[x], 0),
      gaps: c.filter((x) => x === "GAP").length, overlaps: c.filter((x) => x === "OVE").length };
  });
  const total = (f) => incidents.reduce((a, o) => a + f(o), 0);
  return { incidents, rounds: total((o) => o.rounds), dataLoss: incidents.filter((o) => o.gaps > 0).length,
    gapRounds: total((o) => o.gaps * (ROUND.GAP - 1)), overlapRounds: total((o) => o.overlaps * (ROUND.OVE - 1)),
    carried: count(m, "cus"), renegotiate: ITEM.length - count(m, "cus") };
}

// cloud/measure.mjs — where the boundary sits, how many items fall in the gap, how many overlap, what happens in an incident.
import { ITEM, MODEL, INCIDENT, CLASS, ROUND, classify, count, run } from "./responsibility.mjs";

const write = (w, ...s) => console.log(s.map((v, i) =>
  (w[i] < 0 ? String(v).padEnd(-w[i]) : String(v).padStart(w[i]))).join(""));
const R = Object.fromEntries(MODEL.map((m) => [m, run(m)]));

console.log(`responsibility matrix: ${ITEM.length} items x 3 service models; ` +
  `${INCIDENT.length} incidents, 3 items per incident; incident round ` +
  CLASS.map((c) => `${c} ${ROUND[c]}`).join(", "));

const A = [-25, 16, 11, 10];
console.log("\n1. responsibility matrix (pro at the provider, cus at the customer, sha shared,");
console.log("   GAP both sides think the other does it, OVE both sides do it)");
write(A, "item", ...MODEL);
for (const k of ITEM) write(A, k.name, ...MODEL.map((m) => classify(k, m)));

const B = [-42, 16, 11, 10];
console.log("\n2. where the boundary shifts across the three models");
write(B, "class", ...MODEL);
for (const c of CLASS) write(B, c, ...MODEL.map((m) => count(m, c)));
write(B, "passes to the provider (pro+sha+GAP+OVE)", ...MODEL.map((m) => ITEM.length - count(m, "cus")));
write(B, "problem items (GAP+OVE)", ...MODEL.map((m) => count(m, "GAP") + count(m, "OVE")));

const C = [-34, 16, 11, 10];
console.log("\n3. how many rounds the eight incidents take to close (parens: gap items)");
write(C, "incident", ...MODEL);
INCIDENT.forEach((o, i) => write(C, o.name,
  ...MODEL.map((m) => `${R[m].incidents[i].rounds} (${R[m].incidents[i].gaps})`)));
for (const [name, f] of [["total rounds", (r) => r.rounds],
  ["  extra rounds from gaps", (r) => r.gapRounds],
  ["  extra rounds from overlaps", (r) => r.overlapRounds],
  ["incidents closing with data loss", (r) => `${r.dataLoss}/${INCIDENT.length}`]])
  write(C, name, ...MODEL.map((m) => f(R[m])));

const D = [-33, 16, 11, 10];
console.log("\n4. what carries over at exit");
write(D, "measure", ...MODEL);
for (const [name, f] of [["carried-over items (customer)", (m) => R[m].carried],
  ["items to renegotiate", (m) => R[m].renegotiate],
  ["  of these, already a problem", (m) => count(m, "GAP") + count(m, "OVE")],
  ["carried-over item share (%)", (m) => Math.round((R[m].carried / ITEM.length) * 100)]])
  write(D, name, ...MODEL.map(f));

responsibility matrix: 24 items x 3 service models; 8 incidents, 3 items per incident; incident round pro 1, cus 1, sha 2, GAP 8, OVE 3

1. responsibility matrix (pro at the provider, cus at the customer, sha shared,
   GAP both sides think the other does it, OVE both sides do it)
item                       infrastructure   platform  software
physical-security                     pro        pro       pro
host-patch                            pro        pro       pro
guest-os-patch                        cus        pro       pro
application-patch                     cus        cus       pro
network-rule                          GAP        GAP       pro
edge-protection                       OVE        OVE       pro
encryption-at-rest                    cus        sha       pro
encryption-in-transit                 OVE        OVE       pro
key-management                        cus        GAP       GAP
identity-and-access                   cus        cus       cus
backup-creation                       cus        sha       pro
restore-drill                         cus        cus       cus
log-collection                        cus        sha       sha
log-retention                         cus        cus       GAP
alert-threshold                       cus        cus       cus
incident-first-response               cus        OVE       OVE
incident-root-cause                   GAP        GAP       GAP
capacity                              cus        sha       pro
image-distribution                    cus        pro       pro
configuration-audit                   cus        cus       GAP
data-classification                   cus        cus       cus
data-deletion                         cus        GAP       GAP
component-scanning                    cus        cus       sha
disaster-drill                        cus        OVE       OVE

2. where the boundary shifts across the three models
class                                       infrastructure   platform  software
pro                                                      2          4        11
cus                                                     18          8         4
sha                                                      0          4         2
GAP                                                      2          4         5
OVE                                                      2          4         2
passes to the provider (pro+sha+GAP+OVE)                 6         16        20
problem items (GAP+OVE)                                  4          8         7

3. how many rounds the eight incidents take to close (parens: gap items)
incident                            infrastructure   platform  software
leak-suspicion                              10 (1)     11 (1)    18 (2)
data-loss                                    3 (0)      4 (0)     3 (0)
external-scan                               12 (1)     14 (1)     5 (0)
key-expiry                                   5 (0)     12 (1)    10 (1)
unauthorized-access                         10 (1)     11 (1)    11 (1)
patch-gap                                    3 (0)      3 (0)     4 (0)
misconfiguration                            10 (1)     12 (1)    12 (1)
broad-outage                                 3 (0)      6 (0)     5 (0)
total rounds                                    56         73        68
  extra rounds from gaps                        28         35        35
  extra rounds from overlaps                     4         10         6
incidents closing with data loss               4/8        5/8       4/8

4. what carries over at exit
measure                            infrastructure   platform  software
carried-over items (customer)                  18          8         4
items to renegotiate                            6         16        20
  of these, already a problem                   4          8         7
carried-over item share (%)                    75         33        17

The numbers are in the measurement class; their inputs are CC25–CC30.

Where the Boundary Shifts

The second table reads the boundary across the three models. Items sitting with the provider climb from 2 to 4 and 11; items staying with the customer drop from 18 to 8 and 4. The total that passes to the provider’s side — provider, shared, gap, and overlap combined — is 6, 16, and 20. Up to this point, the table looks the same direction as the previous lessons’ count of decisions handed over.

The real finding is in the last row. The count of problem items — gap plus overlap — is 4, 8, and 7. The highest count sits not in the model that hands over the most, but in the middle model. The reason is the third row: the count of shared items is 0, 4, and 2, and gap and overlap are born only in shared items. Under infrastructure service almost everything belongs to the customer, under software service almost everything belongs to the provider; in the middle, half the items face both sides at once.

Uncertainty piles up not at the ends of the boundary but where it shifts. incident-root-cause is in the gap in all three models: the provider cannot see below its own layer, and the customer cannot see inside the provider’s. edge-protection and encryption-in-transit are in overlap under infrastructure and platform — since both sides do it, no one notices its absence, but which setting governs gets asked the moment there is an incident.

What a Gap Does in an Incident

The third table runs the matrix over the eight incidents. Total closing rounds are 56 under infrastructure, 73 under platform, 68 under software. The rows below write where those rounds come from: an ordinary item takes one round, a gap item eight; the extra rounds from gaps are 28, 35, and 35, from overlaps 4, 10, and 6.

The infrastructure column gives this lesson’s sharpest number. Two of the twenty-four items are in the gap, and those two items write exactly half of the eight incidents’ 56 total rounds. A gap item is not a missing document; it is work built from scratch at the moment of the incident, and it does not stop the incident’s clock.

Looking at individual incidents makes the effect clearer. leak-suspicion touches two gap items at once under software service and closes in 18 rounds; the same incident is 10 rounds under infrastructure. By contrast, data-loss and patch-gap never touch a gap in any model and close in three to four rounds. Whether an incident is expensive is determined not by the incident itself but by where the items it touches fall in the matrix.

The last row converts the cost into a non-technical unit: four, five, and four of the eight incidents close with data loss. This count is nearly identical across the three models. Deepening the service model raises the gap count from 2 to 5 but does not lower the number of incidents closing with data loss — because gap items sit scattered across the incident paths, not collected in one place.

Overlap Is Cheaper Than a Gap

The two problem classes do not carry the same weight. An overlapping item writes two extra rounds per incident, a gap item seven. Under platform, the matrix contains four overlapping and four gap items; across eight incidents, overlap writes 10 extra rounds, gap 35 — the item counts are equal, the costs three and a half times apart.

Their directions are opposite, too. As the handover deepens, overlap climbs from 2 to 4 and then drops back to 2, while gap keeps rising — 2, 4, 5. When the provider clearly takes on an item, overlap disappears; an item that is not clearly taken on does not disappear, it falls into the gap. In a responsibility matrix the dangerous cell is not the one with two marks in it, but the one with no mark at all — and that cell gets skipped during review, because a row that looks empty in the table reads like an incomplete record, not like an unclaimed obligation.

This distinction also determines the order of review. An overlapping item stands out at first glance, because it is work both sides do: there are two separate settings, two separate records, two separate invoice lines. A gap item leaves no trace at all — no setting, no record, no owner. Finding the four overlapping items in the matrix takes an afternoon; finding the four gaps requires asking both sides about every item, one at a time. The value of a responsibility matrix shows up not in its filled cells, but when its empty cells are searched for.

What Carries Over at Exit

The fourth table closes the course’s measurement axis. Items that stay with the customer, and so carry over unchanged to a new setup, are 18, 8, and 4 — 75%, 33%, and 17% of the 24 items in turn. Items to renegotiate are 6, 16, and 20.

The last row shows the hidden part of the exit: 4, 8, and 7 of the items to renegotiate are already a problem. So what carries over on exit is not just a responsibility list, but the undefined cells in that list; an item stuck in the gap tends to stay in the gap under a new provider too, because the cause of the gap is not the provider but the item sitting outside both sides’ field of view.

Summary

• In the 24-item matrix, items passing to the provider are 6, 16, and 20; items staying with the customer are 18, 8, and 4.
• Gap items are 2, 4, and 5; overlapping items are 2, 4, and 2. The total of problem items (4, 8, 7) peaks not in the model that hands over the most, but in the middle model, where the boundary shifts the most.
• Eight incidents close in 56, 73, and 68 rounds; 28, 35, and 35 of those rounds come from gaps alone. Under infrastructure, two gap items write exactly half of the total rounds.
• 4, 5, and 4 of the eight incidents close with data loss; deepening the service model does not lower this count, because gap items sit scattered across the incident paths.
• Overlap is cheaper than a gap: with equal item counts, overlap produces 10 rounds under platform and gap 35. As the handover deepens, overlap shrinks and gap grows.
• The carried-over item share at exit is 75%, 33%, and 17%; 4, 8, and 7 of the items to renegotiate are already in a gap or an overlap.

Next Step

This topic measured renting five times: how quickly capacity arrives, how many decisions are handed over, which layout the workload fits into, how many items the ledger hides, and where the boundary of responsibility runs. The boundary is now drawn, and who does what — and what no one does — is written down.

Yet across all these measurements, one question was never asked: where the rented thing physically sits. The physical-security row in the responsibility matrix sits with the provider in all three models, but which geography, how many separate locations, and what failure boundaries the provider holds that item under was never asked. When a failure happens, what determines what stays standing is not the responsibility table but where the rented resource sits. The next topic begins with that question.