preprint · arXiv:wm.2604.0005 · [cs.SE] · operational docs Submitted 15 Apr 2026 Matrix Systems Innovations Ltd · Cardiff · 15598218
W
WebMatrix Systems
AI-driven web infrastructure · est. MMXXIV
Cardiff · CF10 Companies House 15598218
Incorporated 27 Mar 2024
arXiv:wm.2604.0005 · [cs.SE] · cs.NI v1

Docs.

The WebMatrix engineering desk1

1 Matrix Systems Innovations Ltd, Cardiff CF10

Abstract

An operational reference for engineers integrating with WebMatrix. We document the onboarding path, the OTLP-compatible endpoint, the policy specification language, the API surface and the deprecation discipline. The reference is written for the engineer doing the integration, not for the person deciding whether to do it; that conversation belongs on the engineering call.

Four hours to first edge response.

A normal onboarding completes in about four hours. The route the customer's traffic takes is conventional: anycast PoP, BGP-announced from one of fourteen sites; TLS terminated against the customer's certificate held in the customer's HSM-backed key store; cache-key derived from the request envelope; origin selected by the operator's routing policy. The four hours are not in our infrastructure; they are in the customer's DNS propagation, certificate handoff, and the cache warm-up window. The platform itself accepts traffic the moment the routing policy is signed.

Configuration is data.

Every WebMatrix setting is a configuration record. There is no UI-only setting that is not also expressible as a signed YAML record committed to your repository. The control-plane UI is, by deliberate design, a renderer over the same records. The records are version-controlled, signed against the release tag, and auditable from the same data model the rest of the platform reads.

# wm/routes/profile.yaml apiVersion: wm.io/v1 kind: Route metadata: name: api-v1-profile signature: ed25519:0x8a91…7c3d spec: match: path: /api/v1/profile methods: [GET, HEAD] origin: pool: profile-svc-eu timeout_ms: 1200 cache: enabled: true autotune: v2 feasibility: max_ttl: 60s stale_while_revalidate: 12s refuse_when: - request.header.authorization.present observability: rum: true trace_ratio: 1.0 policy: bind: policies/credential-stuffing.spec
Listing 1 A representative route record. The signature is a hardware-key-backed ed25519 signature of the record, verified before promotion to enforcement. The policy.bind field links the route to a MatrixGuard specification by file path; the policy is itself a versioned record under the same repository.

OTLP endpoint.

Point your OpenTelemetry collector at otlp.webmatrix.systems:4317 (gRPC) or :4318 (HTTP). Authentication uses an OAuth 2.0 bearer token issued from the control plane and rotated automatically every 24 hours. The endpoint is OTLP-compatible at the wire level; what differs is the schema extension, documented inline, that lets MatrixObserve recognise the request envelope, the policy hit and the edge decision when they appear in the trace.

SignalEndpointSchemaNotes
Tracesotlp.webmatrix.systems:4317OTLP 1.1 + wm.v1 extroute/region attrs required
Logsotlp.webmatrix.systems:4317OTLP logs · wm.v1trace context required if available
RUM beaconsrum.webmatrix.systems/v1wm.v1.rumscript tag, signed
Synthetic checkssynth.webmatrix.systems/v1wm.v1.synthconfig as data

Table 1 Telemetry endpoints. All four feed the same graph and join structurally, not heuristically.

Policy DSL.

MatrixGuard accepts a policy as a natural-language specification embedded in a thin DSL frame. The DSL exists because English is bad at rate windows, set membership and cryptographic predicates; the rest of the policy is English. The compiler is deterministic; the simulator runs against the last 30 days of production traffic; the promotion gate is the simulator output. There is no exception path that lets a policy enter production having failed the gate.

# policies/credential-stuffing.spec spec_version: wm/v1 description: | Block any session in which the session token has been rotated more than three times in the last 60 seconds AND the request user-agent is on the list rotating_ua_set. predicates: rotation_count: count(session.token.rotations, window=60s) rotating_ua: ua in set("rotating_ua_set") action: block when (rotation_count > 3) AND (rotating_ua) explain: | Three or more session-token rotations in the last 60 s, with a user-agent on the rotating-UA list. See trace {trace_id}. promotion: fp_budget_pct: 0.05 simulator_window_days: 30 signoff: required
Listing 2 A MatrixGuard specification. The English description is normative; the predicates are evaluated against the WebMatrix data model; the explain string is interpolated and emitted on the data model on every block, so MatrixObserve can read it.

Read-only access to the WebMatrix graph.

The control-plane API is the single integration surface. Authentication is OAuth 2.0 with hardware tokens required for any write path. The OpenAPI 3.1 specification is published per release, signed against the release tag, and version-controlled in the public repository. The deprecation policy is twelve months of parallel availability between any two adjacent API versions; we have, in two years of operation, made zero unannounced breaking changes.

EndpointVerbPurposeAuth
/v1/routesGET / PUTList or upsert route recordsOAuth · HW for write
/v1/policiesGET / PUTManage MatrixGuard specsOAuth · HW for write
/v1/incidentsGETRead incident paragraphs and graphOAuth · read
/v1/decisionsGETRead edge decisions (auto-tune deltas)OAuth · read

Table 2 Four endpoints, one API surface. The control plane is small on purpose.

When the docs are not enough.

The documentation is sufficient for engineers who have read OTLP specifications before. When the documentation runs out — usually at the seam between WebMatrix and an idiosyncratic legacy system on the customer's side — open an engineering call. Forty-five minutes, written note same day, no obligation to continue.