Software Defined Corporation

Form 1 — Aggregate MFid (the canonical number)

MFidaggregate = (D × E × O × I)1/4. One number per system, vendor, process, or stack. This is the number that goes on the board deck. It is always a geometric mean of four [0,1] dimension scores, and is therefore always in [0,1] itself — as of v2.4.0 that bound is a hard invariant of the instrument, with no exceptions. Weights are fixed at 1/4 each. There are no per-engagement weight choices.

Form 2 — Domain-projected fidelity (MFid_app, MFid_net, …)

When a system exposes domain-specific service-level indicators (latency, throughput, reliability for an app; bandwidth, jitter, loss for a network), we compute a domain projection:

MFidapp = LwL × TwT × RwR

where L, T, R ∈ [0,1] are fidelity scores per SLI (claimed/observed clipped to 1.0) and weights w sum to 1. The projection is a weighted geometric mean — the same non-compensatory operator as the aggregate. Through v2.3.0 this form was an arithmetic weighted sum, which quietly permitted inside a dimension the compensation the aggregate forbids between dimensions: a strong throughput score could offset a latency shortfall. That inconsistency was corrected in v2.4.0; see the Revision Ledger. Weights are not chosen per case. They are derived from the system’s own published SLO portfolio — if the operator weights latency at 50% of their SLO budget, we use 0.5. If no SLO portfolio exists, we use the default Tier-1 weighting (0.5 / 0.3 / 0.2 in order of business impact: response time, throughput, reliability) and publish the choice in the finding.

A domain projection is not the aggregate MFid. It is one input into one of the four dimensions. Roll-up:

• Dependability (D) ← the per-SLI D term on each L/T/R signal — dispersion plus unfavorable offset against the claim, tail-capped; aggregate-type claims enter as raw fidelity ratios (see rubric below).
• Efficiency (E) ← resource-bounded form of L and T (claimed cost-per-unit ÷ observed cost-per-unit).
• Observability (O) ← coverage of L/T/R signals: fraction of customer journeys for which a measurement exists.
• Integrity (I) ← scored separately; see rubric below.

Every published MFid_app in our case studies is annotated with both forms going forward: the projection that motivated the finding, and the aggregate it rolled into.

Terminology — the Software Defined Index (SDI)

SDI(x) ≡ MFid(x)

The Software Defined Index is the buyer-facing name for the canonical aggregate, answering the question the firm’s name poses: how software defined is X? — to what degree does X’s stated definition determine its behavior? SDI is not a third reporting form: it introduces no new aggregation, dimensions, weights, or evidence tiers. The two terms are equal by definition. If SDI ever diverges from MFid, the divergence must appear on the Revision Ledger before any diverged score is published. The derivation of the equality is on the Theory page; the naming argument is on Why “Software Defined”?.

D — Dependability

Definition: Repeated observations under stated conditions match the claimed value within its stated tolerance — the buyer can depend on any single future observation.

Measurement: D = 1 − min(1, (Δ + σ) / (μc × τ)) where μ_c is the claimed value of the observable, σ is the standard deviation of the observations, τ is the published tolerance band (e.g. 10%), and Δ is the unfavorable offset of the observed mean from μ_c — zero when the observed mean meets or beats the claim, the size of the shortfall when it does not. Computed per SLI; aggregated by minimum across SLIs (a system is only as dependable as its worst-behaved indicator). For a claim that binds on aggregate rather than per observation — an uptime percentage, a durability figure — the SLI enters the minimum as its raw fidelity ratio (observed/claimed, clipped to 1): a 30-day window yields one observed uptime, not a distribution of them. The dispersion-plus-offset form applies to claims that bind on every observation.

Why the offset term (new in v2.4.0): dispersion-only scoring rewarded a system that is perfectly consistent at the wrong value — rock-steady at 200 ms against a 50 ms claim. Consistency at the wrong value is not dependability with respect to the claim; it is reliable unfaithfulness, and Δ makes it cost. Whenever the claim is met on average, Δ = 0 and the form reduces exactly to the prior σ / (μ × τ).

Worst-case binding: D is additionally bounded by a tail cap computed from the single worst observation in the window: D ≤ min(1, 2/z), where z is the largest excursion of any critical-SLI observation from the claimed value, in units of σ. The cap is inactive for z ≤ 2, passes the historical 0.9 near z ≈ 2.2, and keeps falling as the worst observation worsens — a 4σ excursion bounds D at 0.5. We refuse to let a calm hour hide a panic minute; and as of v2.5.0 we also refuse to score a 2.01σ event a cliff apart from a 1.99σ event — the penalty is continuous in the size of the excursion, and, unlike the old flat 0.9 cap, it does not stop charging at catastrophic ones.

E — Efficiency

Definition: Resource cost per unit of useful output, relative to the published or contracted cost. E is cost fidelity, not cost goodness: it asks “does it cost what they said?”, so an honestly-priced expensive system scores 1.0.

Measurement: E = min(1, claimed_cost_per_unit / observed_cost_per_unit), computed in the natural unit of the system (cycles/token, watts/inference, dollars/transaction, joules/request, bytes/query). One unit per system, declared up front. E is a one-sided ratio: under-cost (better than claim) is clipped at 1.0. Over-delivery is recorded in the finding — and, where it is structural, earns the Verified Underreporter annotation — but it never raises a score above 1.0.

O — Observability

Definition: Fraction of the customer-relevant behavior surface for which a current, queryable, retained measurement exists.

Measurement: O = (covered_SLIs / required_SLIs) × retention_factor × freshness_factor. Required SLIs are enumerated up front for each system from its specification (not from what is currently instrumented — that would let absence become a credit). Retention factor is 1.0 if telemetry is retained ≥ 30 days, scaled down otherwise. Freshness factor is 1.0 if the dashboard is queryable in < 60 seconds, scaled down otherwise. A score you have to mine from log files is not observability; it is archaeology.

Why O multiplies into the score rather than standing beside it as a confidence interval: a claim that cannot be observed is operationally indistinguishable from a claim that is false, so missing telemetry costs the vendor the same way a missed target does. The orthodox alternative — a headline score with an O-driven uncertainty band — carries the same information but lets an unmeasured system keep a high headline number. We refuse that trade, and the refusal is a design choice this page owns explicitly.

I — Integrity

This is the dimension the 2026-05-26 review flagged as undefined. The review was correct. The rubric below is the answer.

Definition: The fraction of system activity that demonstrably serves the stated purpose under audit, with the remainder classified as out-of-spec drift (not necessarily harmful — but not what was contracted).

Important framing. Integrity is not a property of the artifact in isolation; it is a property of the artifact relative to its specification. We measure the specification as carefully as we measure the system. An unclear spec produces a low Integrity ceiling, not a low Integrity score — we publish the ceiling and recommend the spec be tightened.

Measurement (three-part, each scored [0,1], aggregated by geometric mean):

1. I_spec — Specification clarity. Does a written, dated, signed specification exist that enumerates required behaviors and forbidden behaviors? Scored by document analysis on a 7-point checklist (existence, dating, scope, behavior list, forbidden-list, change log, sign-off). Reproducible across reviewers with κ ≥ 0.7 on a 50-spec calibration set; calibration set published on request.
2. I_trace — Operational coverage. Of the operations the system performed during the measurement window, what fraction can be traced to a specified behavior? Computed as (traced_operations / total_operations) from logs, traces, or transaction records. Operations with no trace match are not assumed malicious — they are assumed unscored, and counted against I_trace.
3. I_drift — Forbidden-behavior detection. Of operations classifiable as “outside spec” (output schemas, data destinations, decision boundaries the spec excludes), what fraction were caught by automated guardrails before having effect? Computed as (blocked_violations / detected_violations). A system with no violations and no detection capability scores 0.5 (we cannot tell whether it is well-behaved or unmonitored).

I = (Ispec × Itrace × Idrift)1/3.

For ML and autonomous systems specifically: I_spec is scored against the model card and policy document. I_trace is computed from prompt/response logs against the policy classifier. I_drift measures jailbreak/red-team catch rate. No public worked example on an LLM endpoint has been published yet; until one is, the rubric above is the complete canonical definition.

What I is not. I is not a measure of whether the system is good. A perfectly-malicious system with a clear spec authorizing maliciousness scores I = 1.0. I measures fidelity to the spec, not the wisdom of the spec. That is by design. We score the gap between claim and reality; we do not score the claim itself. That is the customer’s job.

The canonical case: Porsche

Porsche publishes 0–60 times, quarter-mile figures, lap times, and power outputs that independent reviewers and owners consistently beat — not by a rounding error, but by a margin that is too regular to be noise. A 911 GT3 RS quoted at a Nürburgring time the factory already knows it can beat. A Taycan Turbo S rated at a 0–60 the launch-control software was tuned to exceed. The understatement is not accidental; it is policy. Porsche does not want a customer to discover their car underperforms the sticker. The sticker is a floor, not a target.

Applied to MFid: an audit of Porsche's published performance specifications against independently measured reality would find raw claimed-vs-observed ratios above 1.0 on every performance figure — the ratios that feed E and the per-SLI fidelity terms — before the clip is applied. D and I cannot exceed 1.0 by construction (one is 1 minus a clipped penalty, the other a geometric mean of fractions); they register the understatement differently, as near-perfect scores: the gap between claim and observation is consistent (high D), and the conservatism is documented policy rather than accident (high I). Under a bare clip the composite scores 1.0 — numerically indistinguishable from a vendor who just barely met their word. That conflation is the problem the annotation below solves.

The annotation rule for verified underreporters

The Verified Underreporter designation is awarded on any dimension where the following conditions are simultaneously met:

1. The raw ratio exceeds 1.0 on its own evidence. Observed performance is better than claimed, not merely equal.
2. The pattern is multi-instance. The gap is documented across at least three independent measurements or product lines — not a single favorable test.
3. The understatement is structural, not accidental. There is evidence the vendor knowingly set conservative specifications — internal communications, design posture, or a consistent historical record — rather than simply underestimating their own system.
4. No other dimension is below 0.9. A super-unity score on one axis cannot be used to redeem a deficiency on another. This rule preserves the core principle of the geometric mean: a chain is only as strong as its weakest link.

When all four conditions hold, the score is still computed with the clip — the aggregate remains in [0,1] — and the finding is published with the Verified Underreporter designation, the qualifying dimensions, and their raw pre-clip ratios (e.g. “E raw 1.12, published 1.00”). The reader gets the full information; the index keeps one definition.

What the designation means — and does not mean

The designation does not mean the system is perfect. It means the vendor's claims are structurally conservative relative to what they actually deliver. The organization tells you less than the truth in their favor. In a landscape where most published specifications are optimistic, aspirational, or outright wrong, a vendor that systematically underreports is a meaningful outlier. The designation records that outlier status explicitly rather than relegating it to a footnote.

It is rare by design. Verified Underreporter status is not awarded for beating a spec once, or for modest outperformance within normal manufacturing variance. It requires the kind of documented, intentional conservatism that an organization chooses as a brand posture and executes consistently. Most vendors will never qualify. The ones that do earn a designation that cannot be confused with “barely passing.”

Why not publish the super-unity number itself, as earlier versions permitted? Because MFid’s claim to be an index — and SDI’s claim to be the Software Defined Index — depends on one bounded scale every reader interprets identically. A published 1.12 invites comparison against a 0.94 as if the two lived on the same axis; they do not — one measures fidelity, the other generosity. The raw ratios are in the annotation for any reader who wants them; the scale stays [0,1].