Home / The model / The graph / The three layers

The three layers

A customer will disagree with some of this vocabulary, and they will often be right about their own estate. The wrong response is to merge their definitions into these, because merging is a destructive operation and what it destroys is the finding. The right response is three layers.

Layer 1: shared facts, owned by nobody

The factual graph, published here: 23 capability primitives, 10 verbs, 9 object classes, 5 reach classes, 4 barriers, 9 deployment shapes and what each one grants. Nobody has to agree about what any of it means to agree that it is the case.

This layer is free, public, versioned and hash verified, and it stays that way. It lives at /data/ with cross origin access, so a vault reads it over the network rather than forking it. A consumer pins a version, because a clone that floats against the latest has no reproducible output.

Layer 2: per-party formulas

Each party classifies those shared nodes with its own rules. A node type here is a formula rather than a label, which is exactly what makes this possible: a customer does not need us to change a field, they write their own formula over the same facts.

The formula here	A customer's version, and why
`[Control] := a [Barrier] -enforced_by-> an [Enforcer] the [Grant] does not include`	A regulated customer may require a control to be evidenced as well as enforced: `... and -backed_by-> [Evidence] -observed_on-> [System]`. Their unbounded excess is then higher than ours, on the same facts, and both numbers are correct.
`[Excess] := a [GrantedCapability] with no -authorised_by-> path`	A customer whose mandates are written per role rather than per deployment computes the same delta against a different mandate node. The capability rows do not move.
The five reach classes	An estate with a hard tenancy boundary may split `tenant` into two nodes. They add nodes in their own vault; ours are untouched.

Three different answers over one set of facts, each internally consistent, each inspectable. None of them requires this site to change.

Layer 3: declared bridges

Explicit edges connecting the two vocabularies at specific points, owned by whoever declared them and revisable without renegotiating anything. The edge is similar_to, it is symmetric, and it is partial on purpose.

our read.record.browsing similar_to their PII.access.browser Partial. Traversable. Arguable. And crucially: a third party can add that edge without touching either node. You do not need our permission, and we do not need yours. Why anchor nodes rather than conformance claims.

The wrong move is a conformance claim: we are compliant with vocabulary X. That is all or nothing, and it is usually a lie by the second field. Partial mapping is the normal case, not a defect.

What a vault actually holds

A customer vault is layers 2 and 3, pointing at layer 1 by address, version and hash. It does not fork the facts.

In the vault	Not in the vault
Their mandates, in their own words	The capability primitives, which are read from here
Their formulas, including their own definition of a control	Our formulas, which are read from here
Their bridges to our vocabulary, and to any other	Any merged vocabulary, because there is none
Their deployment shapes, measured from their own estate	The nine published shapes, which are read from here
Their stored deltas, derived and never authored	Anything they authored by hand into a delta

And the version they pinned. Anything computing from these files states which version it computed against, so a delta produced in the vault in March can be recomputed in September and the difference attributed to the right side. That is the same rule the stored deltas follow here.

Why this is one mechanism rather than two

Customisation and consolidation are the same operation. Do not store a consolidated text and maintain it; hold the base plus the amendments and compute the result. A customer's vocabulary is the base plus their amendments, and so is ours, and so is the next customer's. There is no special case for the customer who disagrees, which is the test of whether the model is actually fractal: if zooming into a node needs a new format or a special case, the system is hierarchical rather than fractal.

The claim that carries this whole page. Parties can disagree about meaning while still agreeing about facts, which is the only stable basis for working together. A customer who cannot accept our definition of a control can still accept that their agent can read every file the account can reach, and that is the sentence the ABP needed them to reach.

The declared bridges as JSON · The lexicon · Why vocabularies are bridged rather than merged