Celestial Mode: Day

MFid Walkthrough teaching example · v1.1 · 2026-05-29

How the formula on the Methodology page is applied, end-to-end, on a published vendor SLA.

v1.1 revision note

The original draft of this walkthrough used a 99.99% Workers Enterprise SLA figure that turned out to be a contracted (non-public) commitment, not a verifiable published claim. Methodology v2.1’s flag-and-stop discipline caught the unverified claim before publication. Walkthrough revised to use Cloudflare’s public Business SLA. The instrument worked — on its own teaching material.

What this page is, and is not

  • This is an instrument demonstration, not a published MFid finding. SDCorp has not performed a Tier-1 measurement against Cloudflare. We use the public Cloudflare Business SLA as a real Tier-2 claim, and walk the math through illustrative measured values to show how the formula is applied.
  • Numbers on the measured side are labeled [illustrative] wherever they would require a measurement run we have not performed. Every illustrative row is also visually tagged so a single-row screenshot cannot be misread as a measured finding. Do not cite the aggregate score from this page as Cloudflare’s MFid.
  • The Tier-2 claim is real and cited. The walkthrough’s job is to teach the math, not to attack the vendor. For the theoretical grounding of the four dimensions and how the score is constructed, see the Theory page.
  • Why Cloudflare Business SLA. Public, single-number commitment; published status-page history (cloudflarestatus.com) as the audit-able evidence source; buyer-familiar; low ambiguity in the spec. Good teaching surface for the four dimensions.

Step 1 — Identify the Tier-2 claim

The published claim under audit. From Cloudflare’s Business Service Level Agreement, Section 1.1:

“100% Uptime. The Service will serve Customer Content 100% of the time without qualification.”

Source: Cloudflare Business SLA, retrieved from https://www.cloudflare.com/business-sla/ on 2026-05-28.

100% uptime, “without qualification,” is an unusually aggressive headline claim. The SLA reconciles aggression with reality in Section 6 (Service Credit Calculation): any downtime is treated as a contract miss and credited against monthly fees, rather than tolerated within a stated band. For walkthrough purposes that gives us the cleanest possible Tier-2 surface — observed uptime < 100% is a fidelity gap by definition, and the dispersion-penalty mechanic in D below shows how the aggregate handles it without rounding the gap away.

The pedagogical point is not whether 100% is achievable. It is the discipline of measuring observed uptime against the headline number that was written down, and reporting the gap rather than negotiating it away.

Step 2 — Decide what would be measured

For each of the four dimensions, name the signal that would be measured if this were a real engagement. This step is the same whether the measurement is performed or skipped — it forces the methodology to be specified before any number is reported.

D — Determinism: tail behavior under stated tolerance

Same input (an HTTP request that should be served by a deployed Worker), same observable output (a 2xx response within latency tolerance). Required signal: the distribution of response latencies and the count of non-2xx responses across a measurement window. Worst-case binding: any single tail event > 2σ on a critical SLI caps D at 0.9.

Sources available without an engagement: Cloudflare’s published cloudflarestatus.com incident history; the operator’s own client-side Real User Monitoring if instrumented.

E — Efficiency: cost per useful unit vs. contracted cost

Natural unit for an edge platform: dollars per million requests at the operator’s contracted plan tier. Required signal: actual billed cost in the measurement window divided by the count of useful requests served end-to-end (not the raw invoice count). Under-cost is clipped at 1.0.

Sources available without an engagement: the operator’s billing portal export.

O — Observability: covered SLIs / required SLIs

Required SLIs for the Business SLA are minimal — the SLA itself only commits on uptime — but for a real production deployment the customer-relevant surface is wider (per-route latency, error rate by status class, cache hit ratio, geographic latency dispersion). Required signal: an enumeration of customer journeys against the telemetry that exists for each, with retention and freshness factors.

Sources available without an engagement: Cloudflare Analytics export, the operator’s observability stack (if any), cloudflarestatus.com for incident-window correlation.

I — Intentionality: three-part rubric

I = (Ispec × Itrace × Idrift)1/3. For a third-party platform under the customer’s SLA:

  • Ispec ← Cloudflare’s Business SLA + Self-Serve Subscription Agreement + Website Terms scored against the 7-point specification-clarity checklist.
  • Itrace ← of operations the platform performed for this customer in the window, what fraction map to a documented service behavior. Undocumented requests count against Itrace.
  • Idrift ← for the customer’s configuration specifically: of operations classifiable as outside spec (routes to disallowed origins, rules outside the documented policy surface), what fraction were blocked by automated guardrails before having effect.

Step 3 — Score each dimension illustrative

Numbers below are [illustrative]. They are realistic for a well-run edge platform and are chosen to demonstrate the formula and the dispersion-penalty mechanic, not to characterize Cloudflare’s actual operating performance. A real engagement would replace each with a measured value and an explicit tier label.

D = 0.93 illustrative

Two SLIs in scope: uptime fidelity against the 100% headline claim, and latency dispersion.
Uptime fidelity: illustrative observed uptime in a 30-day window is 99.997% — roughly 78 seconds of cumulative outage attributable to the Service per Section 2.16. Against the 100% claim that yields Duptime = 0.99997. The 100% claim’s honesty is that this number can never quite hit 1.0; the gap is real and visible, however small.
Latency dispersion: p50 = 12 ms, p99 = 64 ms, σ / μ = 0.06 against a stated tolerance τ = 0.85 on the latency SLI.
Dlatency = 1 − min(1, σ / (μ × τ)) = 1 − min(1, 0.06 / 0.85) = 1 − 0.071 = 0.929.
SLI-minimum: D = min(0.99997, 0.929) = 0.929 ≈ 0.93 [illustrative]. No 2σ tail event on the critical SLI in the window, so the 0.9 worst-case cap is not triggered.

E = 0.97 illustrative

The operator’s plan publishes claimed_cost_per_million_requests = $X. Illustrative observed cost-per-million in the window is 3% higher than the headline figure (typical real-world drag from minimum-commit overhead and out-of-tier traffic).
E = min(1, $X / ($X × 1.03)) = min(1, 0.971) = 0.97 [illustrative].

O = 0.85 illustrative

Required SLIs enumerated from a hypothetical production deployment: uptime, p50/p95/p99 latency by route, error rate by status class, cache hit ratio, geographic latency dispersion (6 signals total). Covered by current telemetry: 5 of 6 (geographic latency dispersion not instrumented end-to-end).
O = (5 / 6) × 1.0 (≥ 30-day retention) × 1.0 (< 60s dashboard freshness) = 0.833; published with a small upward correction (0.85) for low-friction Cloudflare Analytics access. O = 0.85 [illustrative].

I = 0.90 illustrative

Ispec = 0.95: Cloudflare’s Business SLA + Self-Serve Subscription Agreement + Website Terms score well on the 7-point checklist (existence, dating, scope, behavior list, forbidden-list via Terms, public change history, sign-off via published commercial terms). One point lost on forbidden-behavior precision in the public Terms.
Itrace = 0.92: in the illustrative window, 92% of platform operations on the operator’s account map cleanly to a documented service behavior; 8% are unattributed dashboard / API traffic.
Idrift = 0.85: the operator’s configuration has guardrails for route destinations and disallowed rule patterns; the illustrative window contained 4 violations, 3 blocked pre-effect, with the fourth caught in post-hoc review.
I = (0.95 × 0.92 × 0.85)1/3 = (0.7429)1/3 = 0.905 ≈ 0.90 [illustrative].

Step 4 — Roll up to the canonical aggregate

MFidaggregate = (D × E × O × I)1/4

Geometric mean, equal weights. The aggregate is dominated by the weakest factor by policy — a strong I cannot rescue a broken D.

With the illustrative dimension scores:

MFid = (0.93 × 0.97 × 0.85 × 0.90)1/4 = (0.6901)1/4 = 0.911 [illustrative]

Reported in canonical form:

MFid 0.91 (Tier-2 published Business SLA for uptime claim; remaining dimensions illustrative — this is a methodology walkthrough, not a measured engagement)

Notice the coverage label. A score without one would not be a published MFid; it would be a draft. The walkthrough does not pretend otherwise.

What the walkthrough is meant to teach

  • The formula is the easy part. The hard part is naming the signals (Step 2) and being honest about what was actually measured vs. what was inferred (the tier labels).
  • The weakest dimension binds the aggregate. O = 0.85 is the constraint here. Lifting D, E, or I to perfection without addressing O barely moves the aggregate. That is the geometric mean doing its job.
  • A 100% claim is informative even when unattainable. The dispersion-penalty mechanic in D translates “any outage is a miss” into a numeric fidelity score, instead of negotiating the gap away. The Service Credit calculation in the SLA itself does the same in dollar terms.
  • The instrument can score itself. The required SLI enumeration in Step 2 is the same instrument applied to the operator’s own observability stack — not just the vendor’s. And, per the v1.1 revision note at the top of this page, the instrument also scores its own teaching material.
  • Honest reporting includes the coverage label. A 0.91 with no tier label is a marketing number. A 0.91 with “Tier-2 over 1 of 4 dimensions, illustrative on the rest” is an audit number. We publish the second.

Where the reasoning behind this walkthrough lives

The four dimensions used here — Determinism, Efficiency, Observability, Intentionality — and the choice of geometric aggregation are derived on the Theory page. Published MFid measurements against real systems, with Tier-1 evidence and source citations, will appear here as engagements clear publication.

Want the walkthrough applied to your stack?

Bring the SLA, we bring the measurement plan. The number does the rest.

Request an Investigation
Celestial Mode: Day