EdgeVISS Cloud Manager
Engineering Workspace
Every change headed to a gateway — AI-drafted commissioning or an engineering-adapter change — moves through one governed lifecycle, visible in one list, from first draft to verified outcome.
The lifecycle
Six stages a change actually passes through — no status is skipped or inferred.
1
DRAFT
A commissioning or SCADA change starts here — AI-drafted or hand-built, nothing sent anywhere yet.
2
READY_FOR_REVIEW
Compiled against the real gateway and proven to translate, before anyone is asked to approve it.
3
APPROVAL_REQUIRED
A human reviewer sees exactly what compiled — no re-draw between review and execution.
4
QUEUED → EXECUTING
Approval and job dispatch happen atomically. The signed job lands in the gateway’s durable inbox and runs.
5
VERIFYING
Fresh checks run after every execution — and after every manual re-verify, even on a change that already succeeded.
6
SUCCEEDED / FAILED
Derived from the actual check outcomes, not from whether the job merely finished running.
Not every change goes straight through
Rejected
A reviewer sends it back with a reason. Status moves to CHANGES_REQUESTED — the change stays alive, not scrapped.
Re-verify after the fact
Network blip, power cycle, or just wanting a fresh read: re-running Verify on a SUCCEEDED change reopens it to VERIFYING and resolves to whatever the fresh result says — the record always reflects the latest check, never a stale pass.
Execution rejected mid-flight
If the gateway’s own guardrails reject a queued job (e.g. it no longer matches what was approved), the change returns to CHANGES_REQUESTED instead of silently vanishing from the queue.
Why the status you see is the truth
One envelope, two change kinds
Commissioning changes and SCADA/engineering-adapter changes are typed differently underneath, but both report through the same EngineeringChange status — one Workspace list shows the true state of everything moving toward a gateway, not two.
Every mutation is a guarded, row-locked transaction
A single Postgres function is the only path any code takes to change a status. It no-ops rather than corrupts on a mismatched expected-from state, a null id, or a terminal status without explicit re-entry — a status bug can never silently strand a change or double-fire an approval.
Status plumbing never blocks the real work
If recording a status transition itself fails, the approval, job dispatch, or verification result it was attached to still completes — a logging-layer defect can’t stall a gateway waiting on real approval.