Haute Lumière

Commerce · II.05 · MMXXVI · daylight

La Bourse  /  Volume II  /  Nº II.05  /  Workbook — the Gainshare employee

A man and a woman seated across a round table in a high office, the city pale behind the glass.
Plate II.05 · Workbook — the Gainshare employeeThe Exchange, After Hours.The board is not the calls. The board is which calls are possible. Every economy has one, almost nobody has drawn it, and the drawing changes what you think you are looking at.

WORKBOOK — THE LUMINOUS GAINSHARE EMPLOYEE

Chapter II.05 · Complexity and Economic Networks

For the person inside a gainshare scheme, where a share of measured improvement returns to the people who produced it. This chapter is unusually good news for you, and the reason is structural: network improvements are large, cheap, verifiable, and almost nobody is claiming them.

WHAT A GAINSHARE ACTUALLY IS, AND WHY THIS CHAPTER SUITS IT

A gainshare pays a defined share of a measured, verified improvement against an agreed baseline to the people who produced it. It is not a bonus and it is not profit share. It has four parts and every one of them matters: a baseline agreed in advance, a measurement method agreed in advance, a verification step, and a share expressed as a formula rather than a judgement.

Most improvement work is hard to claim under those rules, because most improvement is diffuse — a bit faster here, a bit better there, impossible to separate from market movement.

Network work is the opposite, and this is the whole of your advantage.

That combination is rare. Take it seriously.

PART ONE — DISCOVERY

Days 1–30: find where the structure is already paying

Exercise 1.1 — The graph nobody has drawn (four hours)

Before you propose anything, find out what already exists. Ask three questions, of three different people:

Every answer is an existing structural defence that was never costed. These are your evidence base and they cost nothing, because the improvement already happened. Your job is to put a number on something that is already true, which is a far stronger position than promising a change.

Exercise 1.2 — Find the articulation points (one day)

From whatever edge list you can assemble, find the nodes whose removal disconnects the graph. These are your candidates, because they are the places where a small, cheap, verifiable change produces a large, computable benefit.

Rank them by one ratio: expected loss avoided ÷ cost of a second source. You want the top three. You will propose one.

Exercise 1.3 — Establish who owns the number (one hour)

Find out, now, who would verify a claim. Internal audit, the risk function, the financial controller — whoever it is, meet them before you have a proposal. Ask one question: what would you need to see to sign off a claim of avoided loss from a structural change?

Their answer is your specification. Getting it in week two rather than week twelve is worth more than any analysis you will do.

PART TWO — THE ARITHMETIC

Days 31–45: compute what you are owed

Exercise 2.1 — Build the claim in four lines

A gainshare claim on a network change has exactly four lines, and each one must be independently checkable.

  1. THE BASELINE GRAPH      edge list, dated, boundary stated
  2. THE CHANGE              which link or node, when, at what cost
  3. THE COMPUTED BENEFIT    expected loss avoided, from the cascade,
                             at the organisation's own buffers and α
  4. THE SHARE               benefit × scheme percentage

Line 1 is the one people skip and it is the one that decides your claim. An unagreed baseline is not a baseline; it is a future dispute in which you will lose, because the other side will be arguing after the fact and you will be arguing from memory.

Exercise 2.2 — Compute the benefit properly (two days)

Run the cascade at the organisation's real buffers. The chapter's worked case shows what you are looking for: twenty banks at 1.00 unit of buffer, aggregate 20.00, creditors holding 19.00 — one default at every shock up to 20.00 units, then twenty at 20.50. One extra unit of shock, twentyfold damage.

Your claim is the difference in expected defaults, or expected disruption days, or expected lost margin, between the graph before your change and the graph after. Compute both. Show both. Never show only the improvement.

At α = 0.80 a compartmented structure beats a fully connected one by 12.49 percent of expected defaults; at α = 3.00 the connected one wins by 0.66 percent. Which of those two worlds you are in is the single largest term in your claim, and it is an empirical question about the organisation's own loss history, not a matter of preference.

Exercise 2.3 — State what you do not know (half a day)

Put the tail-index interval and the sample size on the claim, unprompted, before anyone asks.

This feels like weakening your case. It is the opposite. A claim that names its own uncertainty is the claim that survives the second reading, and the second reading is where gainshare claims are actually won or lost. A verifier who finds an unstated weakness discounts everything; a verifier who finds the weakness already stated, with a range, signs.

Exercise 2.4 — The counterfactual (half a day)

The hardest question you will be asked: would this have happened anyway?

Answer it before it is asked. Name the person who would have done it, the budget it would have come from, and the date it was scheduled for — or state plainly that no such plan existed and offer the evidence. A structural change has an unusual advantage here: the graph before and after is a record, and nobody can argue that a link that did not exist existed.

PART THREE — DESIGN

Days 46–70: make the uncounted countable

Exercise 3.1 — Write the measurement note first (one day)

One page, before any work begins, agreed and signed by you and the verifier:

The exclusions paragraph is the most valuable thing on the page. It is where you state the denominator. A claim that says what it did not look at is believed; a claim that does not, is audited.

Exercise 3.2 — Instrument the graph, not the outcome (three days)

Outcomes are noisy and contested. Structure is not.

Where you can, define your claim on a structural measure — the articulation point count, κ, the targeted threshold, the number of single-sourced critical components — and agree in advance the conversion from that measure to money, via the cascade. Then the post-hoc argument is about a conversion rule that was agreed in a calm week, rather than about whether a good quarter was yours.

Exercise 3.3 — Make the tool reusable (two days)

Whatever you build to compute the four numbers, build it so that it runs again next quarter on new data, prints its denominator, and refuses to produce a number when it cannot read its input.

That last property is worth saying plainly. A fallback value is a lie with a default. If the query fails and your tool returns zero, you will one day claim a benefit that did not exist, or fail to claim one that did, and neither is recoverable. If the read fails, stop and say which read failed.

A reusable tool is also the difference between a one-off claim and a standing one, and standing claims are where gainshare income actually accumulates.

Exercise 3.4 — Recruit the second owner (one conversation)

Give the credit for the first result to somebody else, deliberately, in public.

One person running this is a hobby; two is a practice. The way to get a second owner is not to ask for one — it is to hand them a win. This is also straightforwardly in your interest: a claim with two names on it is harder to set aside when either of you changes roles.

PART FOUR — DESTINY AND DELIGHT

Days 71–90: make it hold

Exercise 4.1 — Get the four numbers into the standing pack

A measure in the monthly pack survives reorganisations, sponsor changes and budget rounds. A measure in a project folder does not. This is the single most durable thing you can do and it takes one conversation with whoever assembles the pack.

Exercise 4.2 — Write the ledger entry

Your gainshare ledger entry, in the form that will still make sense in three years to someone who was not there:

  WHAT WAS CLAIMED    the improvement, in units and money
  WHAT WAS TRUE       the verified figure, and who verified it
  HOW IT WAS KNOWN    the method, the data source, the code path
  WHAT IT DID NOT     the exclusions, the boundary, the interval on α
     LOOK AT

The third line is the only one another person can reuse, which makes it the most valuable line in the ledger and the one most often left out.

Exercise 4.3 — The pleasure of the check (one afternoon)

When somebody checks your computation and confirms it, that is a good day. When somebody checks it and finds an error, that is a better day, and this is worth internalising rather than merely agreeing with.

A claim that has been checked and corrected is a claim that will survive every subsequent challenge, and the person who found the error is now invested in it being right. Invite the check. Name the person you want to do it. Thank them in the ledger entry.

A WORKED CLAIM, END TO END

So that the shape is concrete rather than described. The figures are the chapter's own, so every one of them can be checked by running python3 lib/verify.py II.05.

The system. Twenty operating units, each carrying a buffer of 1.00 unit of working capital — aggregate 20.00 units, with any single unit's counterparties holding 19.00 between them. Historically, every unit could draw on every other: the complete wiring.

The baseline graph. Dated, boundary stated, signed by the controller. Twenty nodes, fully connected, no firebreaks. The cascade at that wiring gives one default at every shock up to 20.00 units and twenty defaults at 20.50 — the cliff.

The change. One structural separation: two groups of ten, with no cross-drawing between them. Cost: the standing charge of a second facility, plus the working capital that can no longer be netted across the boundary.

The computed benefit. At the organisation's own tail index — estimated at 0.80 with an interval and a stated sample size — the compartmented structure carries expected defaults of 1.3936 against the complete structure's 1.5677. That is an improvement of 12.49 percent of expected defaults, and the cascade caps the worst case at ten units rather than twenty however large the shock.

The honest half of the claim. If the tail index had come out at 3.00 instead, the complete structure would have been better — by 0.66 percent. The claim depends on which side of α\* = 1.0780 the organisation sits, and that is an empirical question about its own loss history. Say this on the front page. A claim that names the condition under which it would be wrong is the claim that gets signed.

The share. Benefit, converted to money by the agreed rule, times the scheme percentage. One line, computed by a formula both parties agreed in a calm week.

What makes this claimable at all is that every term is a fact rather than a judgement: the graph is a list of pairs, the change is a structural separation that either happened or did not, the cascade is forty lines of code in a shared repository, and the tail index is estimated from the organisation's own records with its interval printed beside it.

KNOW YOUR SCHEME — A CHECKLIST

Before you claim anything, be able to answer all nine.

  1. What is the share percentage, and is it stated as a formula or decided?
  2. What is the baseline period, and who signs a baseline?
  3. Who verifies, and what is their standard of evidence?
  4. Is the claim individual, team or pooled — and if pooled, how is the pool defined?
  5. When is it paid, and against what event?
  6. Is there a cap? Where is it, and does a structural claim hit it?
  7. What happens to a standing claim — one that keeps producing benefit in later periods? Is it re-claimable, annuitised, or lost?
  8. What happens if the benefit is later revised down? Is there a clawback, and over what window?
  9. What happens if you change roles before the benefit is realised?

Questions seven and nine are the ones people discover too late, and network claims are exactly the kind that produce benefit for years after the work.

THE CONVERSATION, SCRIPTED

When you take the claim in, it is four sentences and a page. Not a presentation.

"Here is the graph as it was in March, dated and agreed with audit. Here is the change we made in May — one second source, twenty-two thousand pounds. Here is the cascade run on our own buffers, before and after, with the tail index interval on the front page. The claim is the difference, times the scheme percentage, and the code is in the repository if you want to run it yourself."

Then stop talking. The page does the work. If the verifier asks a question you cannot answer, say so, write it down, and come back — do not improvise, because an improvised answer in a verification meeting is the thing that makes the whole claim look like advocacy.

APPRECIATIVE QUESTIONS FOR YOUR TEAM

  1. When has a structural change one of us made quietly prevented a disruption — and did anyone ever put a number on it?
  2. Which of us already knows where the single points of failure are, and has never been asked in a setting where the answer could be claimed?
  3. If our gainshare ledger recorded how we knew alongside what we claimed, what would the next team be able to reuse?
  4. What is the smallest structural claim we could make this quarter, all the way through to verified — and who would we want to check it?