EdgeVISS Cloud Manager
Engineering Knowledge
What your team already knows — conventions, reusable configuration, and lessons from real commissioning history — feeding every future AI proposal, without ever skipping review.
Three surfaces, one guardrail
Chat text alone can never become trusted knowledge, and applying a template always produces a new EngineeringChange revision — never a direct write to OT.
Engineering Standards
Your own conventions for naming, addressing, polling, alarms, and MQTT export — versioned, with an explicit review/verification trail. Inform AI proposals; never bypass approval.
Engineering Templates
Reusable configuration derived from reviewed work — parameterized, with gateway IDs, network addresses, credentials, and tenant IDs deliberately excluded from the template itself.
Field Knowledge
Durable lessons from real commissioning history — successful patterns, verification failures, warnings, field corrections, operator confirmations. Every entry links back to a real EngineeringChange, revision, verification, or evidence record.
Nothing becomes knowledge without a trail
Standards
Named, versioned, with a description and creation trail — reviewed the same way a device profile is, not a free-text note.
Templates
Named and described, applied by producing a fresh EngineeringChange revision — the same governed lifecycle every other change goes through.
Field Knowledge
Typed (pattern, failure, warning, correction, confirmation) with an explicit trust state, and required to cite the real record it came from.
How this connects to AI Commissioning
A drafted device config isn't generated in a vacuum — it can be informed by your own naming and addressing standards, built from a template distilled from prior reviewed work, and, over time, shaped by what field knowledge says actually held up in production. Every one of those still lands as a normal draft: compiled against the real gateway, reviewed, and approved before anything is written.
More on AI Commissioning →