DCH 3.2

What's New

Version 3.2 of the DCH stack includes the following new features and improvements.

Removal of the GBS UI and GBS v1 Endpoints

The legacy GBS UI has been removed, making DCH the only frontend. To support this change, the following updates were introduced:

Graph Security Layer

The Graph Security Layer toggle is now available only through the API endpoints under /api/v2/settings, and only administrators can change it.

Workflow Changes

Workflows have been updated to use the v2 API exclusively. This affects only workflows that include Rule transformation steps.

info

Workflows with Rule transformation steps must have their DAGs recreated.

New v2 API Endpoints

To prepare for the removal of the GBS UI, the following endpoints were added to the v2 API:

v1 Endpoint	Replaced by
GET /api/graphprocessing/getRelated	GET /api/v2/target-entities/{idOrAlias}/related
POST /api/graphprocessing/clearGraph	POST /api/v2/graph/clear
GET api/targetEntities/cont-limited	GET /api/v2/target-entities/{idOrAlias}/data-preview
GET /api/dashboard/getOverviewData	GET /api/v2/data-model/statistics
GET /api/dashboard/getHomeData	GET /api/v2/target-entities/{idOrAlias}/statistics

Removed Obsolete v1 Endpoints

With the GBS UI removed, a number of outdated v1 endpoints could also be retired:

• /api/configuration/*
• /api/dashboard/*
• /api/datapump/canMapDataPumpContainer
• /api/datapump/copy/{id}
• /api/datapump/getAllDataPumpContainers
• /api/datapump/getContainerEntityDataImporterAffectedListAsync
• /api/datapump/getDescription
• /api/datapump/getEntitiesAll
• /api/datapump/getEntityDataImporterAffectedList
• /api/datapump/getName
• /api/datapump/getParameters
• /api/datapump/load
• /api/datapump/preLoad
• /api/datapump/preloadNewInitDataPumpContainerData
• /api/datapump/smokeTest
• /api/datapump/preLoadFromInitAsync
• /api/datapump/entityCreateData
• /api/datapump/getDataPumpEntitiesInitData
• /api/graph-access-rule/getAllRulesData
• /api/graph-access-rule/getGraphAccessPropsAndRelationsData
• /api/graph-access-rule/addCreateAccessGraphRule
• /api/graph-access-rule/editAccessGraphRule
• /api/graph-access-rule/deleteAccessGraphRule
• /api/graph-access-rule/deleteAccessGraphConditionalValueRule
• /api/graph-access-rule/setActiveRuleState
• /api/graphprocessing/*
• /api/importer/*
• /api/keycloak/*
• /api/loadplan/*
• /api/queuejob/*
• /api/servicestatus/getAllServicesStatus
• /api/settings/*
• /api/targetEntities/*
• /api/worker/killjob
• /api/workers/getWorker

Alias to Slug Migration

The alias field has been renamed to slug across all DCH services to more accurately reflect its purpose. As part of this change, slug validation has been harmonized so that all slugs follow a consistent format. In addition, the relationship alias field has been renamed to type, which better describes its actual meaning. All existing data is migrated automatically.

info

Requests and responses now include a slug field alongside the existing alias field. The alias field is deprecated and will be removed in the next version. Please update your integrations accordingly.

Affected Endpoints

Linked Data Api

Endpoint	Notes
GET /api/v2/views	Response
POST /api/v2/views/	Request and response
GET /api/v2/views/{id}	Response
PUT /api/v2/views/{id}	Request and response

GBS

Endpoint	Notes
GET /api/v2/functions	Response
POST /api/v2/functions	Request and response
GET /api/v2/functions/{id}	Response
PUT /api/v2/functions/{id}	Request and response
GET /api/v2/relationships	Response
POST /api/v2/relationships	Request and response
GET /api/v2/relationships/{id}	Response
PUT /api/v2/relationships/{id}	Request and response
GET /api/v2/target-entities	Response
POST /api/v2/target-entities	Request and response
GET /api/v2/target-entities/{idOrSlug}	Response
PUT /api/v2/target-entities/{idOrSlug}	Request and response
GET /api/v2/target-entities/{idOrSlug}/related	Response
GET /api/v2/target-entities/{idOrSlug}/statistics	Response

M4AI

Endpoint	Notes
GET /api/v1/agent-systems/	Response
POST /api/v1/agent-systems/	Request and response
GET /api/v1/agent-systems/{agent_system_id}	Response
PUT /api/v1/agent-systems/{agent_system_id}	Request and response
POST /api/v1/agent-systems/{agent_system_id}/duplicate	Response

Intake Agent API: slug-based configuration identifiers

Intake Agent API now uses slug (URL-friendly [a-z0-9-] format) as the primary identifier for data source configurations, replacing alias. The alias fields are still returned for backward compatibility but are deprecated. Key changes to the Intake Agent API specification:

• DataSourceConfiguration: new slug field (required), alias deprecated
• DataSourceConfigurationDataPreviewResponse: new dataSourceConfigurationSlug field, dataSourceConfigurationAlias deprecated
• StartDataJobRequest: new dataSourceConfigurationNameOrSlug field, dataSourceConfigurationNameOrAlias deprecated
• Data preview endpoint path parameter renamed from {alias} to {slug}

Intake Agents using DCH.IntakeAgentCore v2.2.0+ automatically support slugs. Custom Intake Agents should add slug to their configuration responses.

Neo4j Processing Improvements

Data processing to Neo4j has been optimized to transmit only relevant data, enabling better handling of large data volumes while minimizing the performance impact on Neo4j. The following enhancements were introduced:

• Process since: A timestamp can now be specified to determine which data is included in a given processing run. This makes it possible to process only new or selected data, removing the need to reprocess the entire dataset each time.
• Relationship processing modes: Relationship processing is now configurable, supporting all relationships, outgoing only, incoming only, or a custom selection. This provides finer control over which data gets processed.
• Improved performance: Processing speed has been significantly increased thanks to automatic differentiation of how nodes are created in Neo4j.

Queue Jobs Redesign

Queue Jobs have been redesigned to provide a more detailed and transparent overview of what happens during job execution. The new details view gives a comprehensive summary of the target entities and data sources involved in the job.

For each target entity, you can now inspect:

• The build configuration that was used
• The selected import configurations and relationships
• Direct links to the target entity and its associated import configurations for further inspection

In addition, a new Stages tab lets you drill down into the individual stages executed during the job, making it easier to trace progress, diagnose issues, and understand the overall job flow.

Jobs can also be rerun using the same build configuration as the original execution, simplifying repeated runs and troubleshooting.

Unified Model and Build

Model and Build have been combined into a single, unified workspace to provide a smoother experience when designing the data model and importing data. This eliminates context switching and makes the path from modeling to ingestion much more direct.

Key improvements include:

• Direct selection from the canvas: Within the isolated model view, target entities can be selected directly on the canvas and forwarded into a build configuration with a single action.
• Advanced build configurations: The build configuration now supports more sophisticated use cases, such as processing only specific portions of the staging data or selected relationships.
• Build graph preview: A new graph view of the build configuration visualizes exactly which entities and relationships will be imported and processed, making it easy to validate the scope before execution.

License Handling in DCH

A new System section was added to the DCH menu. It includes links to the Services page, which was previously available through a submenu, and the Info page. The Info page provides basic instance details, license information, and imprint data. Administrators can also use this page to upload a new license.

Instance Name Handling

The instance name is no longer stored in SysConfiguration or retrieved through the frontend API. Since this value is only relevant on the DCH side, it has been moved to DCH environment variables instead. DCH now shows the instance name in both the info box and the Info page.

The Linked Data API endpoint used to fetch the instance name has been removed:

• GET /api/system/instance-name

Provider Embedding

Users can now link memories to a specific embedding provider configuration, allowing precise control over the embedding model and settings applied to each memory.

Automatic staleness detection: Whenever a memory or its linked embedding provider configuration changes, the system flags the affected data as stale automatically. During the following sync, stale entries are re-embedded using the current settings, and the stale flag is removed, keeping embeddings consistently up to date.

Runtime provider resolution: During execution, the system resolves the appropriate embedding provider for each memory dynamically, based on its configuration.

Agent execution guardrails: The agent execution flow now includes safety guardrails to prevent misuse and guarantee reliable behavior.

Management of embedding provider configurations is now handled on a dedicated page.

Memories

This release brings major improvements to how memories are managed and consumed by agents.

Memory Page

To simplify working with memories, a new memory page has been added. Previously, memories could be managed only within Agents. This page supports memory management tasks such as listing, editing, and deleting existing memories, along with creating new ones.

Projection Memories

Projection memories are a new memory type that enables agents to leverage published Views and Functions for reasoning. By drawing on a targeted portion of the knowledge graph, they significantly reduce the embedding footprint and improve overall performance.

If a projection requires parameters for execution, these parameters must be declared directly in the prompt.

Problem Details

Error responses from the GBS v2 API now follow the Problem Details standard, providing a consistent and structured format for communicating errors in HTTP API responses.

info

To maintain backwards compatibility, the message and statusCode fields continue to be included in the response body, but they will be removed in the next version.

Worker Auto-Registration

The POST /api/v2/workers endpoint in GBS has been updated to support auto-registration. Auto-registration is implemented by all workers shipped with the DCH stack. This allows workers to register themselves with the DCH stack automatically, eliminating the need for manual configuration.