Overview
This article follows a single piece of work through SIplusAI. At every stage, AI helps with understanding and preparation, deterministic code enforces the limits, and the Engineer makes the decisions. Status labels reflect the platform's implementation records as of the review date.
- RequirementsDescribe the need in your own words.
- DiscoveryAI-assisted scope and evidence-based baseline.
- PlanningTasks and an engineering plan.
- ApprovalThe Engineer approves the exact plan.
- ExecutionQualified package, run by the Engineer.
- VerificationEvidence-based checks and a frozen report.
1. Customer and project requirements
A project starts in a service that is open, currently Unified Communications or Network. The customer or engineer describes the project or problem in plain language. There is no need to translate it into product terminology first; that is what the next stage is for.
2. AI-assisted project discovery
A scope conversation, limited by a budget, asks the questions needed to turn the description into a structured scope. Organisation standards fill values that are already known, so they are not asked again. Evidence such as exports or configuration files can be attached, or collected by a read-only collector that the Engineer runs on a machine with access to the environment. The discovery role builds an AS-IS baseline in which each statement is scored for how well it is grounded in evidence.
| Capability | Status | Detail |
|---|---|---|
| Scope conversation | Available | For open services. |
| Evidence baseline and grounding score | Partial | Implemented; first production run pending. |
3. Scope and execution planning
The orchestrator plans tasks from the scope using deterministic rules. The engineering role then proposes a plan for each task within an engineering profile that the server enforces. Where MCP is involved, the plan can only use operations that an operator has qualified, and records the exact operation, schema and package fingerprint.
4. Engineer review and approval
- The Engineer reviews the plan, its targets and its checks, and approves or rejects it.
- Approval is bound to the plan's hash. Changing the plan or the MCP package invalidates the approval.
- Scope changes require the Engineer; no AI role can change scope on its own.
5. Controlled automation
For a new installation, the engineering role builds a package from the form, the validation role qualifies it, and only then is it released. The Engineer runs it with One-Click on a PC that can reach the target, typing credentials into a masked local prompt. Credentials stay on that machine. The server never connects to customer devices.
| Capability | Status | Detail |
|---|---|---|
| Engineer-run One-Click packages | Available | Qualified before release; run locally by the Engineer. |
| Read-only MCP collection | Partial | CUCM service inventory is the first qualified binding. |
| Generic change packages via MCP | Planned | Not implemented. |
| Unattended multi-step execution | Planned | Not offered. |
6. Verification and reporting
The Engineer uploads the run report. The platform checks it against the prepared package and recomputes verdicts instead of trusting summary counts: a node without evidence cannot pass, a partial reading is a warning and failed collection is unavailable. Post-installation checks follow, and the Engineer's own confirmation is recorded separately. Finally, the reporting role renders a frozen, versioned report from the records.
References
- MCP Security Best Practices (2026-07-28) (opens in a new tab)Model Context Protocol
- KCS v6 Practices Guide (opens in a new tab)Consortium for Service Innovation