VisiCore AI — Extending X10
Reference

Architecture & Trust Zone

How AI extensions sit on the existing platform — and how customer data stays safe.

AI extensions attach to the existing X10 API broker. This page shows how data flows through them. It also shows how the Trust Zone keeps customer data, and VisiCore's methods, protected. The Trust Zone is the security and data-boundary model. It is the technical backbone of the compliance answer in decisions.

The Trust Zone: the golden rules

Customer data never leaves raw

We remove sensitive values the same way every time, before anything reaches an external model.

Sensitive work stays local

Analysis that must not touch a third party can run on local models inside the boundary.

Consent is explicit

Customers acknowledge and consent before any AI processing, both in the interface and in the contract.

Bring your own model

Customers can supply their own model keys. The AI provider stays their choice.

Every invocation is auditable

Every customer-visible action carries an audit trail: who asked, what ran, and what changed.

Dry-run before execute

The agent previews each action as a dry run, and an engineer approves it, before it touches a customer environment.

How data flows safely

Trust-zone data flow: a customer artifact passes rule-based redaction and encrypted storage; sensitive work routes to a local model and everything else to an enterprise model under a no-training agreement; findings end in senior engineer review

How the extensions sit on the platform

Platform topology: customer users enter through Microsoft SSO and customer Splunk/Cribl environments through connectors, both reaching the Lambda API broker, which fans out to ConnectWise, encrypted Cribl Lake storage, and the Vizzy extension

The tool suite

Three views, one suite. Each diagram answers a single question — what the pieces are, what depends on what, and how one unit of work flows through.

What the pieces are

The suite pairs rule-based automation (the platform CLIs) with an AI harness (Vizzy). The CLIs run vendor API calls exactly the same way every time. Vizzy assembles those commands, pulls curated expertise from the knowledge base, and records every action in ConnectWise.

Suite context: engineer works through Vizzy in X10, which draws credentials and expertise from ConnectWise, composes CLI commands, and reaches customer Cribl and Splunk environments through vendor APIs

What depends on what

The direction of dependencies tells you what keeps its value when something else changes:

  • The knowledge base depends only on delivered engagements. It grows with every engagement. It keeps its full value even if any tool, model, or vendor is replaced.
  • The CLIs depend only on vendor APIs. A change to a vendor API is their one maintenance driver.
  • Vizzy composes the CLIs and reads the knowledge base. Swapping a CLI, adding a platform, or changing the model does not break it.
  • The X10 platform supplies identity, UI, and integrations under everything. It depends on nothing above it.
Dependency graph: CLIs depend on vendor APIs; Vizzy composes CLIs, reads the knowledge base, is hosted by X10, and authenticates through ConnectWise; the knowledge base grows from delivered engagements

How one unit of work flows

Every change follows the same loop: compose, dry run, human approval, execute, record. The write-back at the end is what compounds. Each completed task adds to the knowledge base and the ticket history.

Work flow: a task enters Vizzy, which combines knowledge-base context and client credentials, composes a CLI dry run, waits for engineer approval, executes through the vendor API, and records results to the ticket and knowledge base

Design principles

Some platform internals here describe the current direction. The engineering team is still finalizing them. Treat the exact internals as living documentation.

On this page