Theory - Software Defined Corporation

What fidelity is

Fidelity is the correspondence between a claim and its referent.

A claim is what something says it is — a spec, a contract, a datasheet, a marketing line, a certification, an architecture description.

A referent is what the thing actually is — measurable, observable, operating in the world.

Fidelity is high when the two are tightly coupled. Fidelity degrades as they diverge. Perfect fidelity is the exception, not the rule.

Why fidelity matters

In every domain, decisions are made against claims. A vendor selection is a decision against a claim about capability. A renewal is a decision against a claim about delivered value. A regulatory filing is a decision against a claim about compliance posture. Decisions are only as good as the fidelity of the claims they rely on.

The exposure of a buyer to a wrong decision can be written as:

exposure = consequence × (1 − fidelity)

fidelity ∈ [0,1]. The MFid aggregate is the measured estimate of the fidelity term.

Two ways to reduce exposure: reduce consequence (insurance, redundancy, diversification, second-sourcing), or increase fidelity of the claim (audit, instrumentation, verification). The market invests heavily in the first and under-invests in the second — not because fidelity doesn’t matter, but because there is no widely-adopted instrument for it. Buyers can’t measure what they have no tool for.

MFid is the instrument.

The four dimensions

A claim can fail to match its referent in four distinct ways. Each is the answer to a different empirical question the buyer can ask. Each requires a different verification method.

Dependability — does it behave consistently with the claim, across repeated observation?

A claim that “the API responds in under 200ms” is a Dependability claim. So is “the storage is durable for eleven nines” and “the policy is enforced for all requests.” These claims must hold every time, or they are not the same claim.

Dependability fidelity is verified by repeated measurement, and scored on two failure modes at once: how much the observable spreads relative to the tolerance the claim states, and how far its mean sits on the unfavorable side of the claimed value. The operational form, D = 1 − min(1, (Δ + σ) / (μ_c × τ)), is published on the Methodology page; Δ is zero when the claim is met on average. A claim that holds on average but swings between observations scores low — and so does one that is perfectly steady at the wrong value. In both cases the buyer cannot rely on any single future observation matching the claim, which is exactly what the claim asked them to do.

Efficiency — does it perform at the quantitative level the claim specifies?

A claim that “the drive does 500K IOPS” is an Efficiency claim. So is “the model has 175 billion parameters” and “the network supports 100 Gbps line rate.”

Efficiency fidelity is verified by single measurement against the published number. If observed is 340K against claimed 500K, Efficiency for that claim scores 0.68. The canonical form on the Methodology page is the cost-per-unit ratio E = min(1, claimed_cost_per_unit / observed_cost_per_unit) — for a throughput claim the two are the same ratio, and over-delivery is clipped at 1.0.

Observability — can the gap, if any, be seen by the buyer?

A vendor that claims “audit logs for all administrative actions” but exposes log access only via a quarterly PDF report has low Observability fidelity for that claim. The buyer cannot independently verify what the vendor asserts.

Observability is the dimension that makes the other three measurable in practice. A vendor with high Dependability, high Efficiency, and high Integrity but zero Observability is a black box — the buyer cannot trust any of the other dimensions because there is no way to check.

Observability is verified by attempting to instrument. What can be measured at the buyer’s edge counts; what is gated behind vendor cooperation does not.

Integrity — does the design serve the purpose the claim states?

A claim like “Zero Trust architecture” or “GDPR by design” or “high availability” is an Integrity claim. It is not a number — it is a stated intent. Integrity fidelity asks whether the actual architecture, when read, matches the philosophy that was claimed.

A vendor that markets “Zero Trust” while operating a perimeter-based network with VPN tunnels has low Integrity fidelity, regardless of how well that perimeter network performs.

Integrity is verified by reading the design and comparing to the stated intent. This is the most novel of the four dimensions and the hardest to score consistently. It is also the dimension that distinguishes MFid from any pure-numerical framework like an SLO.

Why these four — non-overlapping, defensible as exhaustive

The four dimensions are not arbitrary. They answer four genuinely different questions, each with its own verification method:

Dimension	Question	Verification
Dependability	Consistent?	Repeated measurement
Efficiency	Performant?	Single measurement vs spec
Observability	Visible?	Attempted instrumentation
Integrity	Coherent?	Design reading vs stated intent

Each dimension can fail independently. A vendor can be highly dependable and highly efficient while still being opaque (low Observability) or marketing a design they don’t actually implement (low Integrity).

Candidate failure modes that seem to be missing from the four collapse into one or two on examination:

Security-fidelity (“the system enforces what it claims to enforce”) = Dependability (consistent enforcement) + Integrity (architecture matches stated security model).
Durability-fidelity (“the thing lasts as long as claimed”) = Dependability extended over time.
Cost-fidelity (“the bill matches the quote”) = Efficiency, where the resource being measured is dollars-per-output.
Compatibility-fidelity (“it interoperates as claimed”) = Dependability (interop holds across calls) + Integrity (design choices match the interoperability claim).

If a fidelity failure mode genuinely fits none of the four, the decomposition needs revision. This is an invitation: stress-test it.

Scope of the theory

The theory of fidelity is domain-general. The four dimensions are abstract; they apply to any claim about any subject matter where a claim and a referent can be distinguished.

The current MFid practice is IT-focused. The examples, citations, and worked walkthrough on this site are drawn from software, hardware, infrastructure, and IT services.

Other domains — pharmaceutical efficacy claims, legal contract reliability, construction specification compliance — may admit MFid analysis under the same four dimensions, or may require domain-specific decompositions. SDCorp has not yet performed MFid analysis outside the IT domain. The theory permits it; the practice does not yet demonstrate it.

On the name: SDCorp stands for “Software-Defined Corporation,” which collides with the SDN/SDS/SDDC family of terms in IT. The phrase is used here in an older, narrower sense — see Why “Software Defined”? for the reclamation argument.

The Software Defined Index

Before the formal reading, the plain one: the SDI is the measured value over the promised value, across the key performance indicators of a workflow, combined so that the weakest promise dominates. Every construction on this page is that ratio plus guard rails for its three failure modes: promises that must hold on every observation (Dependability), promises with no telemetry to check them (Observability), and behavior no promise covers (Integrity).

The theory supports a second reading of the same number. To ask “how software defined is this system?” is to ask: to what degree is its actual behavior determined by its stated definition, rather than by drift, accident, or tribal knowledge? That is fidelity — the correspondence between claim and referent — asked from the direction of the definition instead of the claim.

SDI(x) = MFid(x)

Equal by definition, not by coincidence. The Software Defined Index introduces no new aggregation, dimensions, or weights.

MFid names the instrument; the Software Defined Index (SDI) names the question the instrument answers. A high-MFid system is a highly software-defined system: its definition governs its behavior. The equality is versioned on the Revision Ledger (entry v2.3.0); any future divergence between the two terms would be a methodology change, recorded there before use. The full argument for the name is on Why “Software Defined”?.

The math

MFid aggregates the four dimensions using the geometric mean:

MFid = (D × E × O × I)^1/4

Each dimension is normalized to the interval [0, 1], where 1.0 means perfect correspondence between claim and referent on that dimension.

Why geometric and not arithmetic? Fidelity is multiplicative, not additive. A claim with three strong dimensions and one weak one is not mostly-honest at three-quarters strength. It is fragile: the weak dimension is a hole through which the buyer can be deceived, and the strong dimensions do not compensate.

Worked example. A vendor scores D=0.9, E=0.9, O=0.9, I=0.1.

Arithmetic mean: 0.700
Geometric mean: 0.520

The geometric score is not a claim that the vendor is honest or dishonest. It is a conservative aggregation rule: a low Integrity score remains visible in the composite instead of being diluted by high scores elsewhere. In this example, the arithmetic mean reports 0.700 while the geometric mean reports 0.520; the difference is the model’s explicit refusal to treat unrelated strengths as compensation for a weak dimension. The interpretation still depends on the evidence and rubric used to assign each dimension.

The geometric mean of any dimension scoring zero is zero. This is the correct behavior: a claim with one dimension fundamentally broken is not a partially-honest claim, it is a broken claim.

How the four dimensions interact

The aggregate is a product. That single choice fixes how the dimensions trade against each other — or rather, how they refuse to. Five consequences follow directly from the formula; none of them are extra policy bolted on afterward.

1. Equal relative leverage, unequal absolute leverage

In log space the geometric mean is an arithmetic mean: log MFid = ¼(log D + log E + log O + log I). A 1% relative improvement in any dimension moves the aggregate by ¼% — the four dimensions have identical elasticity. No dimension is privileged.

The absolute sensitivity is different: ∂MFid/∂X = MFid / (4X). The lower a dimension already is, the more each absolute point of improvement is worth. With D = E = I = 0.95 and O = 0.60, spending +0.05 on the weak dimension (O → 0.65) lifts the aggregate from 0.847 to 0.864; spending the same +0.05 on a strong one (D → 1.00) only reaches 0.858. The formula itself prices remediation: fix the weakest dimension first.

2. The weakest dimension sets a hard ceiling

Every factor is at most 1, so the aggregate is bounded by the weakest one: MFid ≤ (weakest dimension)^1/4, no matter how strong the other three are.

Weakest dimension	Aggregate ceiling (other three perfect)
0.9	0.974
0.8	0.946
0.5	0.841
0.25	0.707
0.1	0.562
0	0

Read the table as a diagnostic in reverse: because the weakest dimension can be no higher than the geometric mean and no lower than its fourth power, a published aggregate of 0.84 pins the weakest dimension inside [0.50, 0.84]. The composite cannot hide the weak link; it can only bound it — from both sides.

3. Strong dimensions cannot buy back weak ones

Along a constant-MFid surface, relative changes must cancel exactly: a 20% relative drop in one dimension (×0.8) requires a 25% relative gain (×1.25) somewhere else to hold the score. But every dimension is capped at 1.0, so any dimension already above 0.8 has no 25% of headroom to give. Near the top of the scale — which is where vendors sell — losses are unrecoverable by compensation. The only way to restore the score is to fix the dimension that lost it. This is the mathematical form of the claim that fidelity gaps are non-substitutable.

4. Observability gates the other three epistemically

D, E, and I are computed from telemetry. O measures what fraction of the required telemetry exists. When O is low, the D, E, and I values are computed over a smaller observed surface than the claim covers — they may be nominally correct, but they are evidence-poor. Multiplying by O makes the aggregate discount exactly the scores whose evidence base is thin. That is why O is a factor in the product and not a footnote beside it: the formula couples the quality of the measurement to the value of the measured.

5. The weakest-link policy recurses inside the dimensions

The aggregate is not the only place the policy is enforced. The published rubrics apply the same principle at every level of the roll-up, through three operators of increasing strictness:

Clip — min(1, …) inside E and the per-SLI D terms: over-performance is recorded but cannot compensate anything. As of methodology v2.4.0 the clip is never lifted; structural over-delivery earns the Verified Underreporter annotation with raw pre-clip ratios, and the score stays in [0,1].
Product — O = coverage × retention × freshness; I = (I_spec × I_trace × I_drift)^1/3; the aggregate itself: weakness multiplies through, smoothly.
Minimum — D is taken across SLIs by minimum, and the single worst observation bounds it through the tail cap D ≤ min(1, 2/z) (z = worst excursion in σ units): the worst observation is the score, continuously in its severity.

Read bottom-up: a single misbehaving SLI sets D by minimum; a low D drags the aggregate by product; an over-achievement anywhere is clipped before it can offset either. Every path from an individual measurement to the published number passes only through operators that preserve the weakest link. That is the mathematical statement of the ethic on the Manifesto page: no strong number is allowed to hide a weak one.

The limits of MFid

Four things MFid does not measure. These are not modesty disclaimers — they are the boundary of what the definition (fidelity = correspondence to claim) can support.

Whether the claim is desirable

MFid measures match, not merit. A vendor claiming “we monitor every employee keystroke” can score 1.0 MFid if the system is in fact built to monitor every keystroke and operates as such. MFid says nothing about whether keystroke monitoring is desirable, legal, or ethical.

Behavior outside the claim

MFid scores against what was claimed. Activity that cannot be traced to a documented behavior does cost the vendor — the I_trace sub-score counts it as unscored — but that penalty measures the coverage gap, not the behavior inside it. MFid cannot tell you whether the unclaimed behavior is benign or harmful, only what fraction of activity the claim surface fails to cover. Judging the uncovered behavior itself requires a spec to test against, which is precisely what is missing.

Future fidelity

MFid measures current correspondence. It does not predict whether the vendor will continue to deliver under load, time, or change of conditions. A trend-MFid (the same instrument applied across time windows) could address this; base MFid does not.

Strategic fit

MFid answers “is the claim true.” It does not answer “should I buy this.” A purchasing decision needs three inputs: fidelity of claim, utility of the thing being sold, and cost. MFid contributes the first. The other two require their own instruments.

Our own dates discipline

We publish no dates we cannot commit to. A roadmap is itself a fidelity claim — the gap between a promised ship date and an actual one is measurable, and we hold our own commitments to the same standard we hold a vendor’s. When we have nothing we can stand behind, we say so rather than publish a milestone.

MFid and SLO / error-budget practice

An SLO (Service Level Objective) and an error budget are well-formalized in the SRE community. They are not redundant with MFid; they are complementary.

	SLO / Error Budget	MFid
Measures	Performance against a numerically agreed target	Correspondence between published claim and reality
Target	Agreed between buyer and seller	Whatever the vendor publishes, including unilateral claims
Dimensions	Single (the SLO itself)	Four (D, E, O, I)
Output	Error budget	Non-compensatory aggregate score in [0,1]
Time scope	Continuous, real-time	Periodic, point-in-time

An SLO portfolio maps into MFid rather than competing with it: attainment history against the stated target feeds Dependability (dispersion and shortfall relative to tolerance), SLI coverage feeds Observability, and an SLO whose target is a cost or performance-per-resource figure feeds Efficiency. The mapping is the Form-2 roll-up on the Methodology page. MFid extends to claims SLOs do not formalize: stated architectural intent, instrumentation completeness, qualitative consistency claims.

A mature buyer uses both: SLO for the contractual layer, MFid for the broader claim layer.

Where to next

Methodology — the operational spec: evidence tiers, scoring procedure, version history, how scores are produced.
Walkthrough — how MFid scores a real public SLA, demonstrated on Cloudflare.
Compare — MFid against SLOs, DORA, and ISO 25010: what each measures and what each leaves on the table.
Manifesto — the ethic that underlies the instrument.
Status — our own MFid, live, as the working proof point.

Software Defined Corporation

Theory v2.6.1 · 2026-08-05

Fidelity is the correspondence between a claim and its referent. MFid is the instrument that measures it.