Plan, apply, verify is the safety model
Why Mqttable turns MQTT writes, load, fault injection, and report persistence into explicit confirmation plans.
Mqttable EngineeringMqttable lets agents help with MQTT operations, but it does not let them silently mutate local state. The safety model is simple: plan first, apply only after explicit confirmation, then verify by reading state again.
Interactive diagram
State machine: draft input, masked plan, human confirmation, apply, verify evidence.
Placeholder for the interactive diagram. Replace with the generated artifact when ready.
Plan
Planning validates the action input against the same contract used at runtime. It produces a bounded plan with operation, side effects, masked diff, risk, validation notes, expiration, and a confirmation token.
Apply
Apply does not accept the original business payload. It consumes the stored plan plus the confirmation token. This prevents a model or client from swapping in a different broker, payload, toxic, or TLS reference at the last second.
Verify
Verify is operation-specific. A broker update reads the broker back. A runtime control action reads runtime state. A report persist reads the report store. The result is evidence, not a promise.
Where this matters most
Use the model for broker config, connection config, publish actions, subscriptions, scheduled messages, benchmark runs, proxy fault injection, TLS reference binding, and report persistence.