Skip to main content

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 — a named closed form with an id. Every protocol is a state-machine trigger or action schema. Operators compose on the shared clock, and every one carries the mandatory KO42 carrier that phase-locks it to the 1.287 Hz HulyaPulse.

When you derive a new operator, it inherits its parent operators' unit dimensions, and the DERIVE protocol gates it on a real ≤0.1% numeric-accuracy check against the reference cases you supply — if any case exceeds the bound, nothing ships. That is the whole promise: nothing approximate goes live unless it passes.

The deeper symbolic form — the HULYAS master equation and its Σ C_k(ϕ) operator-coupling sum, which the solve() path actually integrates when it evolves a multi-force system over time — is documented on the master-equation page.

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.