← Back to Projects

leptons1618@anishgiri.dev:~/projects/ai-perspective-builder cat project.toml

Systems 2026 Active development

AI Perspective Builder

An Ignition module that docks an AI assistant into the Designer. The Designer holds a chat panel and nothing else — every model call crosses an RPC boundary to the gateway, and nothing reaches a project without a person approving it.

Read the case study → Leptons1618/ignition-copilot-gateway ↗
category
Systems
year
2026
status
Active development
stack
6 tools
highlights
5
write-up
7 min read

01Highlights

  1. One module in three jars — common, gateway and designer — so provider clients and API keys load on the gateway and never in the Designer's JVM.
  2. A declared RPC contract in `common`, implemented on the gateway and called from the Designer, is the boundary the whole safety story rests on.
  3. API keys are stored with AES-256-GCM authenticated encryption, as Base64 of salt, IV and ciphertext, and decrypted only where a request is actually signed.
  4. Provider types are a closed enum — `OPENAI`, `CLAUDE`, `NVIDIA_NIM` and a custom OpenAI-compatible entry — resolved through a `ProviderRegistry` behind an `LLMService`.
  5. `testConnection` is part of the RPC contract and of the `LLMProvider` interface, so the gateway can prove a credential works before the Designer ever offers it.

02Built with

  • 01Java
  • 02JDK 11
  • 03Maven
  • 04Swing
  • 05Ignition 8.1
  • 06AES-GCM

03Case study

August 20, 2026 7 min read 1,500 words

LLM Copilot — An AI Assistant in the Ignition Designer, Kept Away From the Keys

The interesting engineering in this Ignition module is not the model calls. It is four RPC methods, a context budget that gates live tag values, and a credential store bound to the host it was encrypted on.

The problem

The Ignition Perspective Designer is where a controls engineer does their real work — binding tags, building session templates — and it runs in a JVM frequently attached to a plant that is currently producing. An assistant that can edit a live project is genuinely dangerous; one that can only read it is not much use. The problem was to find the smallest amount of authority worth handing to a model, inside a platform where Designer code and Gateway code run in separate processes with different reach.

The solution

Split the module across the boundary Ignition already imposes. Common holds the DTOs and a four-method RPC contract; the gateway holds the provider clients, the context gatherer and the encrypted credential store; the designer holds nothing but a Swing chat panel. Whether the model sees the plant at all is an explicit argument on the chat call rather than an ambient permission, and live tag values are only gathered when the caller asks for FULL context.

Outcomes

  • One module in three jars — common, gateway and designer — so provider clients, HTTP clients and the credential store never load into the JVM that owns the project.
  • A four-method RPC contract is the Designer's entire surface: it holds no API key, opens no provider socket, and decides no policy.
  • `includeContext` and `contextLevel` are explicit arguments on the chat call, so access to the tag tree is requested rather than ambient.

+7 more in the write-up

Inside the write-up

  1. The problem with putting a model next to a running plant
  2. Ignition loads code in two JVMs, so the module ships in three jars
  3. The RPC contract is the design
  4. What the model is allowed to see
  5. Turning context into a prompt
  6. Secrets stay on the gateway, and are bound to the host
  7. Failing in a way the Designer can act on
  8. Where I would want to go next
Read the full case study →