Zum Hauptinhalt springen

Extend the framework

The Zeq kernel ships with 1,500+ canonical operators across 64 physical domains and a state-contract DSL that covers triggers, payload predicates, aggregations, cross-slug subscriptions, and webhook execution. Most use cases are already in the catalogue.

When they're not, the framework is built to be extended. The same primitives the framework uses for its own operators — the master equation, the seven-step wizard protocol, the ≤0.1% precision gate, the canonical clock — are available to you through three concrete extension points:

The three things you can plug in​

1. Operators. A new piece of math, registered into the catalogue. Once it passes the ≤0.1% precision gate against ≥3 reference cases, any state machine can call it. The 5-step DERIVE → VERIFY → REGISTER protocol lives at POST /api/zeq/agent/operators/derive. See Custom operators.

2. Protocols. External APIs and their use as pre_actions / post_actions on a state contract transition. You register an API by name; your contracts then call it without re-implementing auth, retries, or rate-limits. See Custom protocols.

3. Wiring to a machine. Once an operator is promoted and a protocol is registered, you reference both by name from a state contract. Each machine ends up with its own operator vocabulary and its own protocol surface. See Wiring to a state machine.

The thesis​

Every operator is a function. Every protocol is a state-machine trigger or action schema. Both compose through the framework's master equation:

□φ − μ²(r)φ − λφ³ − e^{−φ/φ_c} + φ₄₂ Σ_{k=1}^{42} C_k(φ) = T^μ_μ + β F_μν F^μν + J_ext

The Σ_{k=1}^{42} C_k(φ) term is where every kinematic operator — built-in or yours — couples into the system. When you derive a new operator the kernel proves the coupling preserves the ≤0.1% precision bound before the operator goes live. Nothing approximate ships unless you ask for it.

What you don't have to build​

You don't write authentication. You don't write a scheduler. You don't write an entangled state log, an audit table, a credits balance, a rate-limiter, an oracle, or a webhook retry queue. The framework provides all of that for every machine, every state contract, every API call. When you plug a new operator in, those guarantees travel with it.

The journey​

A typical extension looks like this:

  1. Identify the gap. The wizard or your contract is reaching for math or a data source the catalogue doesn't cover.
  2. Define it. Either derive a new operator (formula + units + parent operators) or register a new external API.
  3. Verify. For operators, the 5-step protocol auto-runs and gates on ≤0.1% precision. For APIs, you test one call from the workbench.
  4. Promote. A promoted operator becomes part of the catalogue; the API becomes a named reference your state contracts can use.
  5. Wire it. Add the operator / API by name in your contract. Deploy. The kernel ticks it like anything else.

Next​

Start with Custom operators — that's where the kernel work lives and where the precision gate is enforced. If you only need to wire external data into a state machine, jump to Custom protocols. For an end-to-end build, read Worked example: thermal router.