Product.
1 Matrix Systems Innovations Ltd, Cardiff CF10, United Kingdom
Abstract
We describe the WebMatrix product surface as three subsystems — MatrixEdge, MatrixObserve and MatrixGuard — operating on a single control plane and a single, OTLP-aligned data model. We argue that the operational value of a control plane that holds all three is qualitatively different from a stack that assembles them post-hoc, and we sketch the seams along which the three subsystems must (and must not) speak.
One data model, three surfaces.
A great deal of the energy spent operating modern web infrastructure is spent reconciling models that ought to have been the same model from the start. The CDN's request object is not the WAF's request object is not the observability platform's span envelope. Each is shaped by what its vendor needed to make their slice of the problem efficient. The reconciliation work falls on the team that owns the application, and it is the work that produces, at 03:14 on a Saturday, the four disagreeing dashboards.
WebMatrix takes the position that the data model is the product. The model is OTLP-aligned at the spine, extended in a documented way at the surfaces (route, policy hit, edge decision), and frozen into a signed schema per release. All three surfaces speak that schema. The control plane reasons over it.
The edge surface.
MatrixEdge is the cache, the routing layer and the TLS terminator. It is also, importantly, the surface against which we publish the reinforcement loop that decides per-route TTLs. The loop reads the data model — not a bespoke metric pipeline — and writes its decisions into the same model, so that the observability surface and the policy surface can see, and reason about, the cache's behaviour without a second integration.
The deployable shape is conventional: anycast PoPs, BGP-announced, the customer's certificate, the customer's origin. The behavioural shape — the auto-tune loop, the constraint set, the published calibration plots — is the part we publish in the open. Read the MatrixEdge note →
The observability surface.
MatrixObserve joins logs, traces, RUM and synthetic checks into one graph. The inference layer reads the graph at incident time. The output is not a wall of correlated lines; it is a paragraph, written in English, that names the symptom, the proximate cause, and the upstream cause. The eval set is public, the monthly eval results are public, and the things the system is bad at are documented in the same monthly note.
The hard part is not the inference; the hard part is the join. The data model from §2.1 is what makes the join cheap. Read the MatrixObserve note →
The policy surface.
MatrixGuard takes a policy written as a specification — "refuse requests where the session token has been rotated in the last 90 seconds and the request originates from an autonomous system different from the session establishment" — and compiles it, deterministically, into enforcement. The simulator runs the compiled policy against the last 30 days of production traffic on the same data model. The promotion gate is the simulator's output. The runtime emits a per-block explanation onto the data model, where the observability surface picks it up.
The control plane.
The control plane is a single API surface. Auth is OAuth 2.0 with hardware tokens for any write path. The configuration is data — there is no UI-only setting that is not also a configuration record — and the configuration record is signed against the release tag. The deprecation policy is twelve months parallel availability; we have, in two years of operation, made no unannounced breaking change to the public API.
| Surface | Emits | Reads | Reasons over |
|---|---|---|---|
| MatrixEdge | D · edge decisions | R · request envelope | route × time × region |
| MatrixObserve | (none, read-only) | R, S, P, D | the incident |
| MatrixGuard | P · policy hits | R, session state | specification → enforcement |
Table 1 Read/write seams between the three surfaces. The model M = (R, S, P, D) is defined in §2.1. No surface writes outside its column.
Begin with an engineering call.
The most useful first conversation about WebMatrix is held against your origin, your trace volume and your existing policy file. Forty-five minutes; written technical note same day; no obligation to continue.