CEBIL: A Simple Framework to Reduce Operational Risk

The problem: which bug do we fix first?

Most backlogs put a typo in a log message and a double-charge bug in the same list. Both are "bugs", and both can have a small title. Without a shared model, the order depends on who shouts loudest.

CEBIL is a small scoring model for operational risk. You score each component once, and then you score each ticket in a few seconds, using the score of its component. It helps answer three questions:

• Is this component important to everyone, or only to a niche?
• If it fails, will anyone notice, and how bad is it?
• Among the open tickets, which one removes the most risk for the least work?

CEBIL stands for Criticality, Exposure, Business visibility, Impact and Legal. Three more attributes complete the model: Stability, Nature and Comple*X*ity. I explain every letter below.

This model is for triage of operational work: bugs, incidents and reliability tasks. It is not a tool to rank new features.

Part 1: The alternatives, and where they fall short

Several good frameworks already exist. None of them was designed for operational risk, so each one leaves a gap.

CEBIL borrows from all four: risk as consequence × likelihood (FMEA), value over effort (RICE and WSJF), and the idea that some work skips the queue (expedite, in cost of delay). Two things are different. The component scores are static, so a ticket only needs two new inputs. And a few rules override the ratio on purpose.

Part 2: The framework

CEBIL works in two stages. The component stage is static and reviewed every quarter. The ticket stage is fast and happens for every bug or change.

a) Component: the letters

Five letters measure the consequence of a failure. Each one is a score from 0 to 3, except Legal, which goes from 0 to 2.

Three more attributes are not part of the consequence sum. Each has a different job.

Two details are easy to miss. C takes the worse of its two halves, so a stateless hard dependency and an easy-to-replay but critical job both score high. And N describes the worst case, while I describes the typical case.

b) Ticket: the letters

A ticket inherits everything from its component. Only two inputs are new.

c) Equations, floors, guardrails and implicit rules

The component equations are simple arithmetic. The ticket equation adds the manifestation and the effort.

COMPONENT Consequence = I + C + E + B + L (0 to 14) Risk = Consequence × S (0 to 42) Class = max( band(Risk), floor(N) ) TICKET F_used = max( F_estimated, floor(X) ) (X = 3 means at least 2) Priority = Risk × M ÷ F_used 

The class comes from two lookups: the band of the Risk, and the floor from N. The higher result wins.

Implicit rules at component level

1. N is a floor, not part of the sum. "Imminent catastrophe" overlaps with I = 3 and C = 3, so adding it would count the same thing twice. As a floor, it also stops a very stable component from multiplying down to Medium.
2. Multiplying by S removes trivial components. If the consequence is 0, Risk is 0, however flaky the component is.
3. Watch your N = 2 count. If more than about 10 to 15 percent of your components are N = 2, the label has lost its meaning.
4. S is reviewed on a schedule. Review it every quarter, or when bugs cluster. For a new component with no history, start from complexity: X = 3 starts at S = 2.
5. X stays out of Risk and Class. Complexity already appears as likelihood through S, and a complex component is not more important only because it is complex.
6. Key-person rule. X = 3 together with N of 1 or 2 means you need a second owner, documentation and a runbook.

Implicit rules at ticket level

1. Class never changes between tickets of one component. Class says the component needs attention. Priority orders the work inside it.
2. X floors the effort. A "one-line fix" in a complex component is rarely a one-hour job, because someone must load the context and test the rules.
3. Drop-everything guardrail. If M is Core and N is 2, the ticket goes to the top, whatever the Priority. Dividing by effort is fine for normal work, but it must not push a data-corrupting bug behind quick wins.
4. Effort never changes the class. A six-month fix on a core component is still High.
5. A bug is evidence about S, not a change to S. Count bugs per component and use them in the quarterly review.
6. Write the reason for M on the ticket. This stops authors from inflating M to jump the queue, and it gives reviewers something to challenge.
7. Ticket to component mapping decides everything. A wrong mapping silently gives the wrong Risk. If the mapping is unclear, ask a human.

Part 3: Component evaluation example

Take a payment system built on Stripe with five components. The scorecard below gives each one a Class, and one of them shows the N floor at work.

What the scorecard shows:

• PaymentService is very stable, so Risk is only 14, which is Medium. Because N = 2, the class rises to High. Without the floor, the most important component would sit in the same band as the webhook sender. It also has X = 3 and N of 2, so the key-person rule applies: it needs a second owner and a runbook.
• PaymentRetryJob is High on Risk alone (9 × 2 = 18). Stripe declines and rate limits make it flaky, which is why S is 2.
• Logging gets L = 1 because payment logs can matter in an audit. Nothing else keeps it above Low.
• MetricsExporter has a consequence of 0, so Risk is 0 even though S is 2. A flaky component that nobody needs cannot climb the bands.

Part 4: Ticket evaluation example

Now three bugs arrive in the same component, PaymentService. All three inherit Consequence 14, S = 1, Risk 14, N = 2, Class High and X = 3. Only M and F make them different. Because X = 3, the effort is never below 2.

Three things to notice:

• Bug A skips the ratio. M is Core and N is 2, so the guardrail puts it first. A cheap quick win must never be placed above a bug that charges customers twice.
• The X floor changes the order of B and C. Bug C looks like a one-hour fix, but the floor sets F to 2, so its priority is 1.8 and not 3.5. Without the floor, a typo would jump ahead of a real customer-facing defect.
• The class stays High for all three. Class tells you the component needs attention. Priority tells you the order of the work inside it.

Part 5: Using AI to apply the framework

You can automate most of the scoring, but the AI agent should only propose the inputs. Ordinary code should compute every number, because the formulas are plain arithmetic. This keeps results repeatable, and it makes the guardrail a hard-coded if, not something a model might forget.

What an agent can score well

A possible setup

1. Keep a component registry in git, with the scores, the evidence, the owner and the last review date.
2. Run a scheduled agent every quarter, and when bugs cluster. It opens a pull request with proposed score changes and evidence. A human reviews and merges it.
3. When a ticket arrives, the agent maps it to a component and proposes M and F. A script then computes the Priority and writes it to a custom field on the ticket.
4. Keep the formulas, bands, floors and the guardrail in code, not in the prompt.

Guardrails for the agent

• Put your score tables and examples in the prompt, and ask for a quote of the evidence behind every score. Without anchors, scores drift between runs.
• Score each component twice and compare. If the two runs disagree, the rubric is probably unclear.
• Start in shadow mode for a few sprints. Write the priority, but do not let it reorder anything, and compare it with how the team would rank the backlog.
• Show the reason for M on the ticket and keep a human override, because people can inflate M to jump the queue.
• Send tickets with a low-confidence component mapping to a person. A wrong mapping is worse than no score.

Part 6: What this model lacks

CEBIL is a triage tool, and it has real limits. You should know them before you adopt it.

• No time dimension. Cost of delay is about how loss grows over time, including fixed deadlines. CEBIL has no deadline, so a bug that becomes expensive in ten days looks the same as one that does not. If you need this, add a deadline flag that works like the guardrail.
• No confidence term. RICE reduces the score of items with uncertain estimates. In CEBIL, a wrong M or a wrong component mapping goes straight into the Priority. The human override and the escalation of unclear mappings are the only protection.
• No upside. The model measures only what can break. It cannot rank new features, so do not use it for that.
• Calibration is your work. RICE and WSJF have scales that many people already know. The anchors in this post are my own, so your team must test them on real components and adjust them.
• Multiplication can still hide a rare disaster. The N floor is the answer, but it depends on honest scoring of N, and honest scoring is hard.

A practical way to combine them: use RICE or WSJF for features, use CEBIL for bugs and reliability work, and feed a component's Risk into WSJF as the risk-reduction input when both kinds of work compete.

P.S. Put the CEBIL score in the code

I suggest adding a CEBIL comment at the top of the main file of each component, with the date of the last review. Then the risk is visible exactly where people make changes, and a reviewer can see how old the score is.

/** * CEBIL - reviewed 2026-11-11 - next review 2027-02-11 * Component: PaymentService (Stripe charges) * I:3 C:3 E:3 B:3 L:2 -> Consequence 14 * S:1 N:2 X:3 -> Risk 14, Class High (N = 2 floor) * Owner: payments-team * Rules: Core bugs here are drop-everything. * Effort estimates start at 2 days or more (X = 3). * Changes need a second reviewer (N = 2). */ export class PaymentService { // ... } 

This small habit helps in four ways:

• Review scope. A pull request that touches a file with N = 2 can require a second reviewer, and a file with L = 2 can require an audit check.
• Honest dates. A score is a claim about the code, and code changes. A CI job can read the header and fail when the review date is older than 90 days.
• Feed for the agent. The same header can be the source of the component registry from Part 5, so scores live next to the code and not in a separate document that nobody opens.
• Faster onboarding. A new developer sees in ten seconds that this file is not a normal place for a quick fix.

If you try CEBIL, I would like to hear which scores felt wrong. Those are the anchors that need work.