Design principles
SIplusAI is built around one rule: AI assists, the Engineer decides. AI models help understand requests, read evidence and propose plans. Limits such as budgets, approvals, package qualification and evidence rules are enforced by deterministic code, and every final decision belongs to a human engineer.
This article describes how the parts fit together. Each capability is marked Available, Partial or Planned according to the platform's own implementation records as of the review date. Partial and Planned capabilities are not offered as operational features.
Discovery and scope definition
Work starts with a description of the need in the customer's or engineer's own words, within a service that is open. An AI-assisted scope conversation, guarded by a budget, turns that description into a structured scope. Evidence can be attached as files, or collected by a read-only collector that the Engineer runs; a discovery role then builds an AS-IS baseline and scores how well each statement is grounded in evidence.
Orchestrator and specialised agents
The platform uses an orchestrator and five specialised roles. No role talks to another directly: every handoff passes through the orchestrator and is recorded.
- Orchestrator: records handoffs, plans tasks from the scope and states the next action. It cannot approve plans, change scope or run anything on a device.
- Discovery: reads attached evidence and collector output to build the baseline. It never changes device state and never receives credentials.
- Engineering: proposes plans within an engineering profile enforced by the server, and builds execution packages. It cannot approve its own plan or make a live change.
- Validation: qualifies every package before release, and judges results only against evidence.
- Execution: a local runner on the Engineer's PC, started by the Engineer. The server never connects to customer devices.
- Reporting: renders frozen, versioned reports from records only.
MCP as controlled infrastructure tool access
SIplusAI keeps a reloadable pool of MCP server packages. Being listed in the pool does not make a tool usable. An operator has to qualify specific operations, each marked read-only or change and constrained by arguments, after testing their real behaviour. Names and descriptions are never treated as proof that an operation is safe.
When planning, the AI only sees qualified operations with their actual input schemas. A proposed step records the operation, schema hash, target and package fingerprint, all of which become part of the plan the Engineer approves. Every change operation must be paired with independently qualified read-only post-checks.
Automation and execution
Execution is engineer-run. The Engineer downloads a qualified package and runs it on a PC that can reach the target. Credentials are typed into a masked local prompt, stay in memory on that machine and never reach SIplusAI or a model. The run produces a report that the Engineer uploads; uploading is not acceptance.
Validation and reporting
Results are checked against the prepared package: a node with no evidence cannot be observed or passed, partial readings are warnings and failed collection is marked unavailable. The Engineer's confirmation is recorded separately from any automatic verdict, and reports are generated from records and frozen with a version.
Capability status
| Capability | Status | Detail |
|---|---|---|
| Service catalogue | Available | Unified Communications and Network are open; other domains are listed as coming soon. |
| AI-assisted scope conversation | Available | Budget-guarded, for services that are open. |
| Handoff ledger and task planning | Partial | Handoffs are recorded and tasks are planned from scope; scope locking and versioning are not complete. |
| Evidence baseline with grounding score | Partial | Implemented; first production run and lab run of the collector are pending. |
| Plan approval bound to plan hash | Available | A change needs the Engineer's approval on the exact plan. |
| Package qualification before release | Available | Packages are checked before the Engineer can run them. |
| Qualified read-only MCP collection | Partial | First qualified binding: Cisco CUCM service inventory, run locally by the Engineer. Other domains require their own qualification. |
| Server-side MCP change operations with post-checks | Partial | The contract is implemented; scope-to-target authorisation and unattended multi-step execution are not. |
| Generic One-Click configuration packages | Planned | Not implemented. |
| Local Agent for outbound-only execution | Planned | Design only; nothing is built. |
| Frozen, versioned reports | Available | Generated from records; review and acceptance routing is partial. |
References
- MCP Specification: Architecture (opens in a new tab)Model Context Protocol
- MCP Security Best Practices (2026-07-28) (opens in a new tab)Model Context Protocol