Skip to main content
v2

Version History

2.0.9​

2.0.9 is the prompt-control and correction-routing release line. Compared to 2.0.8, this adds Thymeleaf-backed prompt rendering, richer runtime routing for confirmations/corrections, new rule capabilities, and a consumer-friendly verbose adapter.

  • Shared Thymeleaf rendering path:
    • prompts now render through ThymeleafTemplateRenderer
    • ce_verbose.message / ce_verbose.error_message render through the same engine
    • supported prompt styles:
      • legacy {{var}}
      • #{...}
      • [${...}]
    • session-aware template variables include session, inputParams, rawInputParams, context, schema, schemaJson, promptVars, and metadata.
  • Prompt/session variable upgrades:
    • PromptTemplateContext now includes standalone_query and resolved_user_input
    • resolved_user_input is derived from standaloneQuery first, then user_input
  • Rule engine expansion:
    • new action: SET_INPUT_PARAM
    • new phases:
      • POST_SCHEMA_EXTRACTION
      • PRE_AGENT_MCP
    • phase/state rule lookup now uses a dedicated cache path for faster repeated evaluation
  • Dialogue and correction flow upgrades:
    • new DialogueAct: ANSWER
    • new CorrectionStep inserted before intent/schema resolution
    • confirmation routing now uses routing_decision
    • confirmation AFFIRM can skip reclassification/re-extraction and continue to MCP
    • confirmation EDIT can patch a single field in existing context without full schema extraction
  • Verbose and audit coverage expansion:
    • added LLM input/output/error verbose events across:
      • dialogue act
      • intent resolution
      • schema extraction
      • MCP planning
      • response generation
    • MCP_TOOL_CALL now emits richer metadata (tool_code, args, action, intent, state, routing decision, observation context)
  • Consumer extension support:
    • new ConvEngineVerboseAdapter allows hooks, container transformers, response transformers, and custom beans to emit either:
      • DB-resolved ce_verbose events
      • direct UI verbose text events

2.0.8​

2.0.8 is the runtime observability and deterministic-progress release line. Compared to 2.0.7, this adds database-driven verbose messaging, step telemetry in session context, stream envelope upgrades, and tighter MCP schema completeness behavior.

  • New control-plane table for runtime verbose messaging:
    • ce_verbose added across DDLs (ddl.sql, ddl_postgres.sql, ddl_oracle.sql, ddl_sqlite.sql).
    • seed rows added across seeds (seed.sql, seed_postgres.sql, seed_oracle.sql, seed_sqlite.sql).
    • standalone SQL assets added:
      • src/main/resources/sql/verbose_ddl.sql
      • src/main/resources/sql/verbose_seed.sql
  • Static cache integration for verbose table:
    • StaticConfigurationCacheService#getAllVerboses() with cache key ce_verbose.
    • preload and integrity validation wired into startup (StaticTableCachePreloader, StaticScopeIntegrityValidator).
    • validation now enforces step_match in EXACT|REGEX|JSON_PATH and non-empty step_value / determinant.
  • New verbose runtime transport model:
    • VerboseStreamPayload DTO added.
    • stream envelope (AuditStreamEventResponse) now includes:
      • eventType
      • optional verbose payload
    • both SSE and STOMP publish AUDIT and VERBOSE events on conversation channel.
  • Step telemetry model added to session:
    • new StepInfo model
    • EngineSession.stepInfos now stores per-step status/timing/outcome/error metadata
    • pipeline writes deterministic step markers (STEP_ENTER, STEP_EXIT, STEP_ERROR).
  • Verbose publishing across core pipeline and resolvers:
    • step lifecycle (EnginePipelineFactory hook path)
    • intent lifecycle (AgentIntentResolver)
    • rule lifecycle (RulesStep, RuleActionResolverFactory)
    • response/output resolver selection (ResponseTypeResolverFactory, OutputFormatResolverFactory)
    • tool + MCP lifecycle (ToolOrchestrationStep, McpToolStep)
    • response resolution (ResponseResolutionStep)
  • MCP schema completeness hardening:
    • new stage MCP_SKIPPED_SCHEMA_INCOMPLETE
    • new status STATUS_SKIPPED_SCHEMA_INCOMPLETE
    • McpToolStep now skips MCP execution when schema-required fields are missing and writes lifecycle metadata deterministically.

2.0.7​

2.0.7 is the MCP revamp release line. Compared to 2.0.6, this adds planner-scoped prompts, advanced tool execution modes, stricter static scope validation, richer MCP runtime metadata, and renamed rule phases.

  • Advanced MCP execution model:
    • DB handler-first path (DbToolHandler) with SQL-template fallback.
    • HTTP handler models:
      • HttpApiProcessorToolHandler (api-processor / RestWebServiceFacade path)
      • HttpApiRequestingToolHandler (framework-managed request policy path)
      • classic HttpApiToolHandler.
  • HTTP policy support in framework invoker:
    • timeout, retry/backoff, in-memory circuit breaker, auth providers, response mapping.
  • MCP planner scoping table:
    • ce_mcp_planner with intent/state scoped prompt selection.
    • seed support added for Postgres/SQLite planner rows.
  • MCP context metadata model for rule branching:
    • context.mcp.lifecycle.*
    • context.mcp.toolExecution.*
    • enables deterministic ce_rule.match_pattern JSON_PATH checks.
  • Guardrail behavior clarity:
    • when planner proposes blocked next tool, fallback answer is written to context.mcp.finalAnswer.
    • POST_AGENT_MCP rules still run, then normal response resolution.
  • MCP guardrail + determinism upgrades:
    • planner output is validated against allowed-next-tool policy before execution.
    • blocked decisions emit deterministic lifecycle metadata for rule branching.
  • Tool execution observability upgrade:
    • direct tool mode writes rich metadata into context.mcp.toolExecution.* including toolCode, toolGroup, status/outcome, scope mismatch flags, and tool row metadata.
  • Scope consistency hardening in static config:
    • ce_mcp_tool / ce_mcp_planner scope values are validated at load/startup (intent_code, state_code) against allowed forms (ANY, UNKNOWN, configured values).
    • invalid scope rows fail fast to prevent cross-intent tool leakage.
  • ce_intent_classifier enhancement:
    • state_code support (default UNKNOWN) so classifier can set state directly without extra transition rules.
  • Rule phase naming update:
    • PRE_RESPONSE_RESOLUTION (old PIPELINE_RULES)
    • POST_AGENT_INTENT (old AGENT_POST_INTENT)
    • POST_AGENT_MCP (old AGENT_POST_MCP)
    • POST_TOOL_EXECUTION (old TOOL_POST_EXECUTION)
    • runtime normalization keeps old phase values compatible during migration.
  • MCP docs expansion:
    • advanced guide updates for metadata and rule patterns.
    • new dedicated MCP Deep Dive with chat-by-chat flow, table impact, and step graph.

2.0.6​

2.0.6 focused on cache reliability and diagnostics to eliminate static-table query noise in consumer environments.

  • Proxy hygiene for static caches: StaticConfigurationCacheService helper paths now resolve through the Spring proxied bean so @Cacheable consistently suppresses repeated ce_* static table SQL after warmup.
  • ConvEngineCacheAnalyzer + diagnostics endpoint: Added GET /api/v1/cache/analyze (with optional warmup flag) to expose active CacheManager metadata, Spring cache properties, cache infrastructure beans, runtime AOP proxy/advisor diagnostics, SimpleKey.EMPTY entry visibility, native cache counts, and warmup timing deltas.
  • Operational debugging uplift: Teams can now validate cache hit/miss behavior directly in runtime and quickly detect provider/proxy misconfiguration in enterprise deployments.

2.0.5​

Introduces massive execution path optimizations targeting latency removal, background history persistence, and static framework component caching.

  • Static Configurations Cache Loader: All static framework properties (ce_intent, ce_rule, ce_mcp_tool, etc.) are pre-loaded entirely into memory on JVM live via StaticTableCachePreloader, dropping complex query I/O across RulesStep and InteractionPolicyStep to sub-millisecond evaluate times.
  • Cache Eviction API: Deployed /api/v1/cache/refresh endpoint natively inside ConvEngineCacheController to allow database administrators to immediately flush and reload RAM without bouncing the application.
  • Async LLM Call Logging: Integrated @Async onto LlmCallLogPersistenceService. Lengthy physical HTTP prompts/completions are recorded in background threads preserving microsecond user-facing SLA times.
  • History DDL Revolution: Hard-deprecated noisy legacy role & stage ce_conversation_history table arrays. Decoupled history updates away from the core DbAuditService pipeline loop entirely, deploying an explicit user_input + assistant_output monolithic string format that tracks asynchronously inside the final PipelineEndGuardStep.
  • SQLite Timezone Idempotency: Normalized all underlying timestamp extractions across standard JSON mapping using formal JVM jackson-datatype-jsr310 deployments and rigorous OffsetDateTime string converters preserving micro-transaction timezone stability across disparate engine host OS profiles.

2.0.4​

Patches internal OffsetDateTime JSON serialization stability when executing audit cache inspection.

  • JavaTimeModule Jackson Integration: Formally added the jackson-datatype-jsr310 dependency to the core engine pom.xml build matrix.
  • CacheInspectAuditStep Modularization: Refactored the step to insulate itself from potentially unconfigured host Spring application contexts. It now natively spins up and governs a strictly private internal ObjectMapper exclusively pre-configured with the JavaTimeModule and ISO-8601 formatting to cleanly convert internal OffsetDateTime objects found inside ce_conversation.

2.0.3​

Introduces deep cache auditing utilities and executor-level history optimization.

  • Cache Inspection Audit Logging: Added a dedicated CacheInspectAuditStep and the convengine.audit.cache-inspector boolean property. When enabled, the engine evaluates a full JSON snapshot of the hydrated EngineSession conversation cache tree and logs it to ce_audit under the CACHE_INSPECTION stage before user input audits finalize.
  • Global Audit Meta Metadata: The DbAuditService now natively intercepts convengine.audit.cache-inspector triggers to permanently append a discrete _cache analysis object map inside the _meta root node across all audit phases for continuous memory visibility.
  • Optimized Executor History Provisioning: Refactored the underlying conversational history provisioner array evaluation (historyProvider.lastTurns(...)) natively into the root DefaultConversationalEngine.process ingress method. This formally prevents downstream LLM nodes from executing entirely redundant ce_conversation relational database queries across consecutive lifecycle turns.

2.0.2​

Introduces deep performance optimizations targeting conversational latency, RAG context injection, and rigid data payloads.

  • Query Rewrite (Contextual RAG): Added convengine.flow.query-rewrite.enabled property. DialogueActStep now natively evaluates conversation history to extract a standaloneQuery into session parameters, allowing downstream RAG tools to receive explicit context without incurring secondary LLM execution penalties.
  • JSON Payload Flattening: Patched EngineSession storage logic to aggressively filter redundant structural blocks (CONTEXT, SCHEMA_JSON, SESSION) before database serialization, permanently resolving exponential payload bloat inside ce_conversation.input_params_json.
  • Framework Caching & Async Pipelines
    • Integrated standard Spring @Cacheable and @Async interfaces over all state persistence mutations to entirely decouple zero-latency edge delivery from blocking background Relational Database I/O.
    • Introduced explicitly managed @EnableConvEngineCaching and @EnableConvEngineAsyncConversation consumer integration decorators.
    • Automatically intercepts the internal engine pipeline via Spring's CacheManager to execute synchronous memory writes while offloading slow I/O Relational DB saves to background asynchronous threads.

2.0.1​

Add audit metadata support for prompt rendering and context

  • Introduced new fields in PromptTemplateContext:
    • templateName
    • systemPrompt
    • userPrompt
    • session (EngineSession)
  • Updated all response format resolvers (JsonOutputFormatResolver, TextOutputFormatResolver) to build a context that includes the new metadata.
  • Updated intent resolution, disambiguation, schema extraction and MCP planner steps to supply the new metadata when creating PromptTemplateContext.
  • Enhanced PromptTemplateRenderer:
    • Collects metadata (selected prompt, system/user prompts, session dump, and prompt variables) into a map.
    • Throws ConversationEngineException with the metadata via withMetaData.
  • Added a metaData field and withMetaData() method to ConversationEngineException.
  • Updated imports across modified classes.
  • Adjusted the database DDL for SQLite to use strftime('%Y-%m-%d %H:%M:%f', 'now') for timestamp defaults.
  • Bumped project version to 2.0.1 in pom.xml.

These changes provide richer audit traces for prompt usage and enable better debugging of engine behaviour.

2.0.0​

Major runtime engine evolution focused on production-grade turn control, tool orchestration, safety, and observability.

Major runtime engine evolution focused on production-grade turn control, tool orchestration, safety, and observability.

Major runtime engine evolution focused on production-grade turn control, tool orchestration, safety, and observability.

1. Robust Pending Action & Task Execution Lifecycle​

  • Introduction of ce_pending_action: A new core configuration table used to catalog multi-turn action candidates by intent, state, and action_key. Features indexed lookups idx_ce_pending_action_lookup across enabled, action_key, intent_code, and state_code.
  • PendingActionRepository: Added Spring Data JPA queries focused on filtering eligible actions by phase, intent (intentCode IS NULL OR ...), state (stateCode IS NULL OR ...), and enabled status, ordering strictly by integer priority.
  • CePendingAction Entity: A JPA entity mapping to ce_pending_action with bean_name, method_names, priority, intent_code, and state_code enabling highly parameterized late-binding invocations.
  • ActionLifecycleStep: A top-level orchestration step responsible for managing the state transitions of modular pending actions within the conversation. Actions are stored in the session context as IN_PROGRESS pending definitive confirmation from the user. It evaluates configurable Time-To-Live parameters (convengine.flow.action-lifecycle.ttl-turns and ttl-minutes).
  • PendingActionStep: A core execution step designed to finalize these actions. It routes the action to the corresponding bean_name and method_names if the user successfully confirms the action sequence.
  • CeTaskExecutor: A specialized executor pattern designed to securely evaluate and invoke pending tasks synchronously within the strict temporal limits of the conversational turn.
  • Context Lifecycle Persistence: The engine tracks the holistic lifecycle of these actions (OPEN, IN_PROGRESS, EXECUTED, REJECTED, EXPIRED) purely in the stringified JSON memory context map (pending_action_runtime), meticulously decoupled from the static table definition.
  • Disambiguation Matrix Controls: Pending actions that are ambiguous or require explicit missing slot inputs before execution dynamically trigger the new disambiguation mechanisms to halt execution, stash the context, and query the user.

2. Deterministic Interaction Policies & Dialogue Acts​

  • DialogueActStep: A brand new classification pipeline step heavily augmenting the traditional NLP pass. Instead of relying purely on heavy LLM intent classification for simple operational conversational shifts, this step evaluates the user's raw input against fast strict Pattern Regex patterns (AFFIRM, NEGATE, EDIT, RESET) before triggering fallback heuristic LLM logic.
  • Dialogue Act Taxonomy: Standardized ENUM classification integrated precisely into ConvEngineInputParamKey.DIALOGUE_ACT including AFFIRM (yes, proceed), NEGATE (no, cancel), EDIT (change something), RESET (start over), QUESTION (inquiry), and NEW_REQUEST (topic switch).
  • DialogueActResolveMode Enum: Explicit execution evaluation modes (REGEX_ONLY, REGEX_THEN_LLM, LLM_ONLY) allowing the system to rapidly identify acts using extremely fast regex thresholds prior to paying LLM generation costs.
  • InteractionPolicyStep & InteractionPolicyDecision: The primary "brain" of the v2 matrix routing implementation. This step evaluates the DialogueAct alongside the current discrete SessionState. For instance, if a pending action is marked IN_PROGRESS in memory, and the new turn evaluates to the act AFFIRM, it makes an instantaneous deterministic policy decision EXECUTE_PENDING_ACTION. If it evaluates to NEGATE, it selects REJECT_PENDING_ACTION. If it's QUESTION, it evaluates to FILL_PENDING_SLOT. This massive enhancement completely bypasses stochastic LLM generative behaviors for discrete boolean pathing.

3. Strict MCP Tool Management and Orchestration Scoping​

  • CeMcpTool Scope Isolation: The intent_code and state_code columns were physically integrated into the ce_mcp_tool table architecture to formally mandate extreme compartmentalization of tool access limits. Tools are strictly bound to domains and are no longer assumed "global by default."
  • McpToolRepository Refactoring: Updated JPQL definitions in the repository (findEnabledByIntentAndState, findByToolCodeEnabledAndIntentAndState) leveraging the Spring Data @Param annotation to guarantee tools are flawlessly filtered. The internal McpPlanner is logically isolated from discovering tools sitting externally to the current active conversational domain intent scope.
  • McpToolRegistry Improvements: A hardened centralized registry mechanism uniquely responsible for standardizing tool_group domains and resolving perfectly legal tools for a given conversation cycle loop, mathematically preventing hallucinations where an LLM invokes an unbound tool.
  • McpToolExecutor Interface Expansion: Designed a formalized executor functional contract natively implemented by a vast array of specialized business adapters for standardized output structures.
  • New Executor Adapter Implementations: Delivered fully mocked execution wrappers capable of expanding to live implementations:
    • McpDbToolExecutor: For parsing database querying and modification parameter mapping tools.
    • McpHttpApiToolExecutor: For serializing outbound REST/SOAP API tool integrations.
    • McpWorkflowActionToolExecutor: For complex cross-system async workflow pipeline triggers.
    • McpDocumentRetrievalToolExecutor: For executing dynamic RAG (Retrieval-Augmented Generation) Knowledge Base queries.
    • McpCalculatorTransformToolExecutor: For executing deterministic programmatic mathematical transformations.
    • McpFileToolExecutor: For OS-level file parsing, reading, generation, and file management tools.
    • McpNotificationToolExecutor: For serializing logic aimed at SMS/Email/Push notification gateways.
  • Early-Exit Execution Guardrails: ToolOrchestrationStep and McpToolStep logic matrices were fortified to immediately halt and bypass tool discovery planning on simple conversational greetings (e.g., regex checks against hi, hello, good morning) or explicit internal dialogue acts (AFFIRM, NEGATE) to drastically curb overhead computational latency and expensive LLM generative token expenditures.

4. Advanced Pipeline Governance: Memory, Guardrails, and Graphs​

  • GuardrailStep Framework: A foundational preventative pipeline step strategically positioned to screen dynamic inputs against hardcoded blocked configuration patterns or sanitize output payload injections before advancing. Generates robust metrics to soft-block or strictly hard-block the ConvEngineInputParamKey.STATE_GRAPH_VALID control parameter.
  • DisambiguationStep Integration: An autonomous discrete evaluation system boundary. If multiple valid intents or competing multi-turn pending actions exhibit mathematically adjacent probabilities (Confidence score collisions), this step halts the internal execution state transitions and forces a deterministic query back to the end user for explicit disambiguation.
  • StateGraphStep Validation: Built an internal compliance enforcement algorithm explicitly assessing whether the current proposed transition route from State A -> State B functionally complies with the statically mapped topologies inside the convengine.flow.state-graph.allowed-transitions logic limits.
  • MemoryStep and ConversationMemoryStore Context Modeling: Engineered a long-term conversation compression service layer. The orchestration engine dynamically aggregates rolling conversation turns bounded by the recent-turns-for-summary threshold and compresses them into a highly compact ConvEngineInputParamKey.MEMORY_SESSION_SUMMARY. This drastically scales up context capacities, permitting the underlying LLM to seamlessly address sliding-window follow-up questions without wasting tokens continuously re-parsing huge historical payload stacks.

5. Deterministic Evaluation and Replay CI/CD Logics​

  • ConversationReplayService Orchestration: Wrote advanced system test capabilities modeled exclusively for deep auditing metrics and automated CI/CD gating strategies. It fundamentally enables developers to parse a target conversation_id string into the service to perfectly replay historical conversational turns sequentially across the precise state parameters to test robustness over time.
  • TraceExpectation Object Structure: Represents the mathematical and contextual logical assertions required during a turn replay scenario (e.g., Assert Intent == X, Assert Dialogue Act == Y).
  • TraceReplayResult & TraceTurnResult Analytics: Deployed overarching replay evaluation metrics classes designed to empower automated pipelines with the tooling necessary to validate whether newly submitted behavior rules applied directly within ce_rule or ce_policy unexpectedly fractured long-standing static historically recorded conversation progression structures.
  • SQL Initialization DDL Enhancements: Segmented and significantly refactored database procedural seeding generation structures intended for clean, error-free automated platform tests. Explicitly divided the sprawling monolithic ddl.sql logic into dedicated dialect-specific SQL instances (seed_sqlite.sql, seed_postgres.sql, seed_oracle.sql). Spliced all auto-generated DBeaver boilerplate syntax elements and strategically configured dependency-oriented DROP TABLE definitions to ensure identically idempotent and stateless automated unit test deployment loops continuously without breaking consistency schemas.

Added new steps​

  • DialogueActStep
  • InteractionPolicyStep
  • ActionLifecycleStep
  • DisambiguationStep
  • GuardrailStep
  • ToolOrchestrationStep
  • StateGraphStep
  • MemoryStep
  • PendingActionStep enhanced for robust policy/lifecycle integration

Added new flow configuration model​

  • ConvEngineFlowConfig (convengine.flow.*)
    • dialogue act
    • interaction policy matrix
    • action lifecycle TTL
    • disambiguation options
    • guardrail controls
    • state graph settings
    • tool orchestration toggle
    • memory summary settings

Added new control table​

  • ce_pending_action
    • action catalog for pending-action execution
    • indexed by action key/intent/state/priority

Added new rule phases​

  • POST_AGENT_MCP
  • POST_TOOL_EXECUTION

Added tool execution architecture​

  • McpToolExecutor interface
  • group executors for:
    • DB
    • HTTP_API
    • WORKFLOW_ACTION
    • DOCUMENT_RETRIEVAL
    • CALCULATOR_TRANSFORM
    • NOTIFICATION
    • FILES
  • adapter interfaces for consumer implementations

Added memory and replay scaffolding​

  • ConversationMemoryStore
  • ConversationReplayService
  • replay model classes (Trace*)

Added audit stage coverage​

Expanded audit visibility for:

  • dialogue act and interaction policy
  • dialogue-act LLM input/output/error checkpoints (DIALOGUE_ACT_LLM_INPUT, DIALOGUE_ACT_LLM_OUTPUT, DIALOGUE_ACT_LLM_ERROR)
  • post-dialogue-act override hook via POST_DIALOGUE_ACT and SET_DIALOGUE_ACT
  • pending action lifecycle and execution
  • disambiguation requirements
  • guardrail allow/deny
  • tool orchestration request/result/error
  • state graph validation/violation
  • memory updates
  • post-phase rule metadata

1.x line​

Use the version dropdown to switch to v1 documentation.