AI Assisted Development
AI Assisted Development helps configurators create, understand, validate, and improve tSM configuration artifacts while keeping the normal review and publication lifecycle authoritative.
tSM 2.4 delivered the documentation assistant, top-bar AI chat, contextual SpEL assistance, and REST/MCP script bindings. Form, TQL, and BPMN assistance plus a shared configurable assistant platform are the unreleased tSM 2.5 target.
Version Boundary
| Surface | Available in tSM 2.4 | tSM 2.5 target |
|---|---|---|
| Documentation | RAG-based chatbot and MCP access to tSM documentation | Shared evidence and project-knowledge providers usable from in-app profiles |
| SpEL | Contextual generation, explanation, debugging, validation, and editor accept/reject | Stronger deterministic gates, reusable project rules, versioned evaluations, and shared profile governance |
| Forms/JEXL | Existing Form Designer and validation runtime | Generate or modify schema/layout/rules, explain behavior, validate, and show a diff before apply |
| TQL/listings | Existing TQL and listing tooling | Generate, explain, compile, and optionally execute safe read-only queries or filter proposals |
| BPMN/processes | Existing Process Designer, task templates, deployment validation, and runtime | Explain/generate/modify BPMN, validate tSM extensions and SpEL, test scenarios, and propose an editor diff |
| Complex configuration | Existing configuration lifecycle, packages, and change sets | Coordinated multi-artifact drafts; publication remains explicit and governed |
One Shell, Specialized Assistants
The same AI panel and conversation behavior should be reused, but each design surface retains a specialized assistant contract, context, tools, validation, and artifact renderer. A generic agent must not edit a form, query, script, and BPMN definition through one untyped text protocol.
The shared platform provides:
- authentication, conversation storage, streaming, attachments, and feedback;
- Assistant Profile resolution and version pinning;
- common tool safety and telemetry;
- evaluation and release controls;
- typed artifact and action events.
Each specialized assistant owns:
- the artifact input/output schema;
- domain instructions and examples;
- compiler, validator, or deployment dry run;
- safe read-only execution where applicable;
- diff and editor-apply behavior.
Safe Artifact Lifecycle
All configuration assistance follows the same controlled sequence:
AI output is a draft. Validation, privilege checks, artifact versioning, Change Sets, package installation, and deployment rules remain authoritative. The assistant does not silently publish or deploy an artifact.
Scripting
The 2.5 work extends the SpEL assistance introduced in 2.4:
- generate, explain, refactor, and debug expressions and scripts;
- discover certified service clients, helpers, and fields for the target microservice;
- validate syntax and project best practices;
- optionally run a controlled read-only verification;
- compare the proposal with the open editor content;
- keep reusable project guidance versioned and evaluated.
Script REST and MCP bindings remain important building blocks. A binding that is exposed to an AI profile also needs a typed contract, authorization policy, risk class, timeout, and evaluation case.
Form Designer
2.5 target
The Form assistant can:
- generate a form from a data model or use-case description;
- add or modify fields, layout, widgets, LOVs, validations, effects, and localization;
- explain JEXL and reactive form behavior;
- validate the complete form contract;
- show a structured diff before the user applies changes;
- recommend existing design patterns instead of duplicating configuration.
The open form schema is the artifact source of truth. Conversational context cannot override an explicit editor selection or replace deterministic form validation.
TQL and Listings
2.5 target
The TQL assistant can generate and explain a query using the selected microservice, index, columns, parameters, and current query. It compiles the result before returning it. Optional execution is read-only, limited, and uses server-owned routing and the current user's token; the model cannot choose an arbitrary service URL.
On a listing, the same capability can return a structured filter proposal. Users see and confirm the interpreted condition before it is applied.
Process Designer
2.5 target
The Process assistant can:
- explain the selected BPMN activity, tSM extension, expression, or process path;
- generate a new draft from a use-case description;
- add or modify user, service, external, Kafka, message, timer, and gateway patterns;
- recommend task templates and explicit transaction boundaries;
- validate BPMN structure, tSM extensions, SpEL, mappings, and required references;
- identify unreachable paths, missing defaults, unsafe retries, and non-idempotent external effects;
- run model-level tests or token simulation where supported;
- return a complete BPMN artifact and visual diff for explicit acceptance.
Process design assistance is separate from runtime Agent Tasks. The designer helps a human create a reliable deterministic model; runtime agentic automation executes only inside bounded process contracts. See Process Automation & Agentic Orchestration.
Multi-artifact Configuration Designer
Horizon — not a committed 2.5 deliverable
A future complex designer may turn a business description into a coordinated draft containing an entity type, characteristics, form, listing, statuses, process, notifications, and tests. It must produce a dependency-aware package/change-set proposal, not directly mutate the environment.
The user reviews each artifact, references resolve against the target environment, deterministic validation passes, and the normal configuration lifecycle controls promotion.
Project Configuration
Customers can tailor assistant behavior through versioned profiles and certified capabilities:
- project terminology and knowledge sources;
- starter requests and examples;
- allowed tools and read-only execution targets;
- validation and style rules;
- required privileges and data policy;
- model, time, step, and cost limits;
- evaluation fixtures and publication thresholds.
This is configuration over code, but not arbitrary prompt execution. Platform and project teams certify providers, tools, actions, and validators before a business configurator can compose them.
Evaluation and Governance
Every assistant/profile version is tested for valid artifact generation, deterministic gate success, correct tool selection, role and tenant isolation, forbidden operations, prompt injection, no-answer behavior, latency, and cost. Security and side effects use deterministic assertions; semantic quality may use reviewed examples or model-assisted scoring.
Trajectory telemetry records the profile and model version, validators, tool calls, repair attempts, user accept/reject outcome, and feedback. Hidden chain-of-thought is not a product audit artifact.
2.5 Delivery Sequence
- Consolidate the common AI shell and server-side conversation boundary.
- Complete specialized Form, TQL, and BPMN contracts and deterministic gates.
- Add profile configuration, versioning, evaluations, and release controls.
- Connect editor proposals to the normal diff, Change Set, package, and deployment lifecycle.
- Reuse the same platform for selected business-screen profiles without weakening editor safety.