I updated the four dimension framework today.

Section 4.2 introduces the TRUST posture model — the four components that make up a principal’s TRUST position: Human Identity Assurance, Traditional Non-Person Entity Assurance, Agent Identity Assurance, and System Integrity Assurance. It ends with a caveat I meant sincerely: no platform will surface all of these signals, so organizations should treat this as a governance architecture to work toward rather than a formula to compute precisely.

Two paragraphs later, in Section 4.3, I wrote:

“The multiplicative trust model is the correct aggregation structure.”

That is a formula. Asserted as correct. Immediately after I said not to offer one.

Where the changes came from

An earlier draft of the paper expressed TRUST posture as an actual equation, with a named aggregate term. This followed from previous work I had done on trying to create a “SCORE” on another program, one where they were also trying to do that around vulnerabilities. I removed it, for three reasons that still hold: the industry if evolving the standard functions quickly, the practitioner audience I am writing for doesn’t expect a scoring model, and the tooling to compute one at enterprise scale largely doesn’t exist.

The equation went. The conclusion it licensed stayed.

So did its vocabulary. The published paper still refers to “the TRUST score equation” in five places, and Section 7.2 still names a variable — T_explicit — from the draft I deleted. Anyone reading Section 7.2 carefully would go looking in 4.2 for an equation that isn’t there.

That’s a specific and slightly humbling kind of error. Not a claim that was wrong on the merits, but a claim that outlived its own justification. When you remove a formalism from a document, you have to audit everything downstream that was leaning on it. I didn’t.

The distinction I collapsed

There are two different assertions in play, and I stated the second as though it were the first.

The rule: no part of the model should be able to cover for a weak part elsewhere. A strong credential shouldn’t excuse an unverified sponsor. Strong model provenance shouldn’t excuse an expired group membership or a delegation chain that’s run past its authorized depth. This is a claim about accountability chains, and it’s the right claim — every link holds, or the chain doesn’t.

The mechanism: multiply the components together.

The first is a property the framework demands. The second is one way to enforce it.

And multiplication isn’t even the strict option

Here’s what makes this more than a wording problem. The property I wanted was that a strong component can’t rescue a weak one. Multiplication suppresses a low value. It doesn’t eliminate it.

Take three components at 0.7, 0.7, and 0.9. Multiplied, that’s about 0.44. Whether that passes depends entirely on a threshold I never specified — and with two components meaningfully weak, it might well pass.

A gate-based approach — where each component must independently clear its own threshold before you combine anything at all — rejects that case outright. It enforces my stated property more strictly than the formula I chose to enforce it with.

And gating isn’t the only alternative. Weighted averages and a few other statistical methods can also honor the rule, depending on how much you trust each signal and how independent those signals really are. I evaluated none of them. I picked one and called it correct.

I also never defined normalization, thresholds, or a worked example. Which means what I actually published was an equation with no operands.

What stays

The four components stay. The rule stays — no part covering for a weak part elsewhere is load-bearing, and I’d defend it against a weighted average any day of the week.

The SIA gate stays, and it’s worth being precise about why it’s a different kind of claim than the multiplication was. A gate is structural, not arithmetic. A perfectly attested agent running on a compromised host provides no TRUST assurance, and no weighting scheme should be permitted to trade that away. That’s a statement about what assurance means, not about how to compute it.

What’s demoted is the arithmetic — down to where it belonged from the start. Pick a method against your own telemetry. Define your thresholds explicitly instead of inheriting mine. Treat the choice as revisable as your signal availability improves. The requirement doesn’t move. The function that enforces it should.

Why post this rather than quietly edit the file

Two reasons.

The practical one: if you read the paper and took the multiplicative model as prescriptive, you should know I’ve withdrawn it — not because it’s wrong, but because I claimed more confidence than the evidence supports.

The structural one matters more. Governance frameworks are unusually prone to this failure mode. They live exactly on the seam between here is a property your system must have and here is how to build it, and those two things get conflated constantly — usually by the author, in a moment of wanting to be more useful. The cost shows up later, when the mechanism gets hardcoded into a product, or a reference architecture, or an RFP, and outlives the assumptions that made it reasonable.

So here’s the test I should have applied:

If someone implemented this differently and still satisfied the stated property, would I say they’d violated the framework?

For the rule that no component covers for another: no. A gate model satisfies it. So does multiplication. So the formula isn’t part of the framework.

For the SIA gate: yes. If a product treats system integrity as a factor that a strong credential can offset, it has not implemented this model. So the gate is part of the framework.

That’s the line. I had something on the wrong side of it.

Sections 4.2, 4.3, 7.2, and the migration playbook are being revised accordingly, and the updated paper will go up on the Resources page.

Next: the argument I actually think is the important one — why agentic AI is a category break, not an incremental extension of NPE governance.

— Ross Foard