Make change routine—and reversible.

Routine should not mean careless.

A GIS upgrade should have a recovery plan before it has a deployment date. The goal is to make changes small, repeatable, and ordinary—not to remove the checks that make them safe.

Honua’s operating model gives people, Console, and agents a shared view of health, findings, proposals, and execution. The server remains the source of truth for operational state.

The Ops Inbox starts with a finding.

Telemetry is the input, not the resolution. A useful operational finding explains a bounded condition, points at the evidence, and identifies an available action when one exists.

Findings in the documented operating loop are deterministic and evaluated on demand; they do not require a server-side model inference. An agent can inspect the same health and evidence, explain the situation, and propose an in-scope action.

This separates automated detection and recommendations from unrestricted model-driven changes. A generic latency problem does not imply there is a single safe remediation. Some findings are observable or diagnosable without being automatically fixable.

A proposal is not permission.

Agent proposals pass through the platform’s operation controls. A separate authorized principal approves them. The agent cannot create its own second approval path.

The default posture is proposal-only. Selected deterministic, low-risk concerns can be opted into automatic application only with an existing executor, explicit policy, guardrails, bounded impact, durable coordination, audit, and a kill switch.

Direct editing of source GIS data is not exposed to the agent. The presence of a tool in a design document is also not enough: the live supported-operation catalog determines what can actually be routed.

Protect a supported change.

A protected operation checks the intended change and recovery availability before activation. It observes the result through its declared protection window, then confirms success or restores and verifies a previous version when policy requires it.

Unknown telemetry can block a new change. During an already-approved protected operation, its bound policy may require deterministic recovery even when telemetry is missing. That does not grant broader authority for another change.

A traffic switch or provider acknowledgement alone does not prove recovery. The original supported workflow needs functional evidence. If recovery cannot be proven, the operation needs attention rather than a green “restored” label.

Three different kinds of “back.”

Configuration revert changes the desired definitions, with a reviewable Git history. Release rollback changes the deployed application artifact. Data restoration recovers database or artifact state through a distinct recovery procedure.

These mechanisms are related, not interchangeable. A Git revert does not restore overwritten feature data. An earlier container may not understand a newer database schema. Recovery depends on the operation and compatibility of the states involved.

Durable history makes the decision explainable: what was approved, what ran, which version was active, and what happened afterward. It is not a universal undo button.

Close the loop on the user’s work.

The final question is not “did deployment succeed?” It is “does the workflow now behave as intended?” Record the answer alongside the operation and its supporting evidence.

For a defect, the same discipline extends through support: a reproducible case, a regression test, a reviewed fix, a qualified release, installation, and a check of the original failure. The fully automated support journey is a direction, not a claim that every step is automated today.

That is the promise behind routine change: more confidence to improve the platform, with a durable account of how it changed and how to recover.