DEV Community: TongWu

🚀 Debut Success: qOntology Named AtomGit’s Most Influential Open-Source Project

TongWu — Wed, 04 Nov 2026 07:41:25 +0000

Following qData and qKnow, qiantongtech’s open-source exploration has received another recognition.

Recently, the AtomGit open-source community platform announced its list of Most Influential Open-Source Projects, and qOntology — the ontology engineering platform recently open-sourced by qiantongtech — was successfully included.

What makes this especially meaningful: the recognition came only a very short time after qOntology was officially open-sourced. In the open-source world, a project’s influence and maturity usually require long-term version iteration and community accumulation. As a newly open-sourced project, we are deeply honored to receive this recognition so quickly.

🏆 An unexpected surprise and recognition

AtomGit is an open-source community platform for developers worldwide. Its selection of Most Influential Open-Source Projects is based on a combination of platform project data and real feedback from global developers. qOntology’s inclusion also made us realize that at the current stage of rapid AI development, the industry and developers indeed have an urgent need for a high-quality knowledge foundation.

This recognition feels like a vote of trust in the technical direction of knowledge engineering.

💡 qOntology: an attempt aimed at underlying needs

qOntology did not emerge from nowhere. It is qiantongtech’s attempt to move toward the more foundational and core field of knowledge engineering, building on its data middle platform (qData) and intelligent agent building platform (qKnow).

As an ontology modeling and knowledge graph construction platform for complex business scenarios, qOntology aims to address the pain points of traditional knowledge graph construction — high barriers, long cycles and difficult implementation — and provides a full-chain solution from underlying ontology definition to upper-layer knowledge reasoning.

In the current AI wave, everyone is exploring the boundaries of agent capabilities. qOntology hopes to serve as a solid underlying component and try to fill the gap between “data governance” and “intelligent agent applications.” It meets the demand of a new generation of AI applications for high-precision, strongly logical knowledge foundations.

We look forward to gradually improving the platform’s capabilities and application paths through open collaboration.

🤝 Final notes: a new starting point, moving forward steadily

Thank you to the AtomGit platform for the recognition, and thank you to every community partner who participated in co-building qOntology soon after it was open-sourced! Your trust has filled the project with vitality from the very beginning.

The open-source journey has only just begun. Next, qiantongtech will continue to refine the product, carefully handle community feedback, improve documentation and developer experience, and explore industry application co-building with universities and enterprises, so that platform capabilities can be validated and improved in concrete business scenarios.

👉 Welcome to try it and share your feedback. We look forward to building it together with you:

🔗 Open-source repository: https://atomgit.com/qiantongtech/qOntology 🔗 Demo address: https://qontology-demo.qiantong.tech/ 🔗 Demo account: qOntology 🔗 Demo password: qOntology123

We look forward to exchanging ideas with more developers and, through continuous technical practice and open collaboration, jointly improving qOntology.

OpenSource #KnowledgeGraph #Ontology #KnowledgeEngineering #AI #qOntology #AtomGit

🚀 qModel Algorithm Model Platform Open-Source Edition v1.4.3 is now released.

TongWu — Wed, 04 Nov 2026 07:38:19 +0000

This version focuses on the configuration and understanding stages of model invocation. By reusing API input parameter definitions and adding output structure descriptions, it further improves the model usage experience, making parameter configuration more standardized and returned results easier to understand.

Models need to be “connected” and also “easy to use” — experience gaps in the usage stage are emerging

In enterprises advancing algorithm applications, connecting a model to the platform is only the first step. Whether business users can correctly invoke the model, and whether system integration personnel and business analysts can understand returned results, also affects the practical use of algorithm capabilities.

As qModel continues to improve the chain from model onboarding to external services, model users are no longer limited to algorithm engineers. Business analysts may need to view model calculation results, system integration personnel need to invoke models based on interface parameters, and other users may complete related operations through calculation tasks or online debugging.

Different roles have different platform usage needs. Developers can understand interface definitions and JSON structures, but for those not directly involved in model development, how to fill in input parameters and what returned fields mean often requires additional documentation or confirmation from developers.

These issues mainly occur in two stages of invocation.

Input stage: parameter definitions exist, but users still need to fill them in repeatedly.

A model may require more than a dozen or even dozens of input parameters. If every calculation task creation or online test requires copying and filling in items one by one against interface documentation, the operation is not only cumbersome but also prone to affecting invocation due to inaccurate parameter names.

From a technical perspective, existing input parameter definitions (inputSchema) of a model or interface have not been fully transformed into configuration content that can be directly used on the usage side. Repetitive operations remain between parameter definitions and actual filling.

Output stage: the interface returns results, but field meanings are not intuitive enough.

Models connected through APIs may return JSON data containing multiple fields, possibly with nested structures. Without field-level descriptions, users need to consult interface documentation or code to confirm the business meaning of each field. For example, what code, data and msg in the returned result represent, and what name, key and value under data correspond to, all require clear explanations for accurate understanding.

The problem in these two stages is not that models cannot be invoked, but that information before and after invocation is not yet easy to use. qModel v1.4.3 therefore focuses optimization on reusing input parameters and explaining output structures.

API input parameter retrieval: no more manual entry

For model interfaces that need to be invoked repeatedly, maintaining a separate set of parameter information for each usage scenario easily leads to duplicate work and is not conducive to unified parameter definition management.

qModel v1.4.3 adds an API access function under the “Data Management” module, unifying the management of data interface registration information and input parameter definitions. Scenarios such as calculation tasks and model online debugging can obtain corresponding parameter forms by selecting a registered API, without manually entering parameter names, types and descriptions item by item.

This capability mainly applies to creating new calculation tasks and online testing in model details.

Turning interface definitions into reusable parameter configurations

In actual use, users can first register the interface name, request address, request method and usage description on the “Data Management → API Access” page, and enter the corresponding parameter definitions. After registration, this parameter definition can serve as a parameter source for different usage scenarios.

When creating a calculation task, users can enter the “Data Binding” area; when performing online debugging in model details, they can also operate on the corresponding page. Click “Select API”, search and select the required interface from the pop-up window, and complete the binding.

After binding, the platform reads the registered input parameter definitions of that API and parses them to generate a parameter table. Information such as parameter names, whether required, parameter types and descriptions is automatically populated by the system, and users mainly fill in the corresponding parameter values to initiate calculation.

This approach transforms parameter definitions that previously required manual reference and copying into form information that can be directly filled in on the usage side.

The platform also handles parameter status when API binding relationships change: after canceling API binding, the system automatically clears and resets parameters to avoid residual parameters from the previous selection affecting the current calculation.

Practical significance for enterprise model usage processes

The focus of this adjustment is to transform parameter definitions from simple interface information into configuration references that can be reused in different scenarios. For models with many input parameters, users no longer need to consult documentation and enter items one by one each time; parameter names, types and descriptions are uniformly populated by the system, which also helps reduce errors caused by manual entry.

For teams that need to reuse the same interface in calculation tasks and online debugging, unified maintenance of parameter definitions can reduce repetitive configuration. When interface parameter definitions change, they can also be maintained in API access management, reducing the burden of repeated modifications in multiple places.

It should be noted that the platform automatically obtains already registered parameter definitions. Users still need to fill in parameter values according to actual business scenarios and confirm that input content meets invocation requirements. This function mainly improves the parameter configuration process and does not mean that all model invocations can skip parameter preparation and business validation.

Output definition descriptions: making model results understandable

Input parameters address how a model is invoked, while output structure determines whether users can correctly understand returned content after invocation.

For API-connected models, if returned results only present raw JSON, even if the interface invocation succeeds, business users may not be able to directly determine the meaning of each field. Especially with multi-level nested structures, understanding based only on field names can increase communication and troubleshooting costs.

To address this, qModel v1.4.3 adds output structure definition (outputSchema) capability, allowing output field information to be maintained in table form under “Result Definition” in model configuration.

From field values to field meanings: supplementing result descriptions

Output definitions support maintaining field names, example values and usage descriptions. Taking the fields mentioned in the original text as an example: code represents the return status code; data represents the return data structure; data.name is the indicator name; data.key is the indicator key; data.value is the indicator value; msg is the request response message.

For nested structures, the platform supports layer-by-layer expansion of definitions, enabling users to view corresponding information by field hierarchy rather than facing a piece of JSON data lacking explanation.

Comparing results during online debugging

Output definitions are not only used for model configuration but are also displayed synchronously on the online debugging page. The left side of the debugging page displays execution results and logs, while the right side displays the result definition table. Users can view actual returned content while comparing field names and usage descriptions to understand information in the returned structure.

This approach helps business users understand output fields without directly reading code, and provides a clearer basis for information transfer between model providers and users. For example, when business users need to confirm what a returned field represents, they can first check the result definition instead of asking developers each time. When invocation issues occur, field descriptions can also serve as a reference for understanding returned content, reducing communication caused by unclear field meanings.

It is important to distinguish that output definition descriptions explain field structures and their purposes. They do not automatically change model calculation results, nor can they replace judgment on the correctness and business meaning of returned data.

Upgrade notes and precautions

In addition to functional updates, this version also involves adjustments to database scripts, menu permissions and request method dictionary display.

Users who have already deployed qModel Open-Source Edition should pay attention to the following when upgrading to v1.4.3.

Database scripts

v1.4.3 provides complete database initialization and upgrade scripts, located in the sql/mysql directory of the project. For new environments, use the v1.4.3 initialization .sql file. For existing environments, execute the upgrade script corresponding to the version. Before execution, confirm the version of the current environment and select the matching script to avoid mixing initialization scripts with existing upgrade scripts.

Menu permission refresh

This update adds table structures and menu permissions related to Data Management (API Access). After the upgrade is complete, users need to log in again to refresh menu display.

Dictionary display adjustment

The HTTP request method dictionary is now displayed in uppercase: GET, POST, PUT, DELETE. This adjustment only affects display format; underlying data encoding remains unchanged and does not affect existing configurations.

Suggestions for existing models

For models already connected through APIs, it is recommended to supplement and improve output definition descriptions. After completing the corresponding configuration, users can use the newly added result definition capability to view and understand the meaning of model return fields.

Making algorithm model usage more convenient

From actual enterprise usage scenarios, completing model registration and enabling external services does not mean all issues in the usage process are resolved. How parameter definitions are reused and how invocation results are understood are also stages to consider when model capabilities move toward business applications.

qModel Algorithm Model Platform Open-Source Edition v1.4.3 makes targeted improvements around these two stages:

On the input side, API access management and automatic parameter retrieval reduce repetitive entry and allow parameter definitions to be reused in scenarios such as calculation tasks and online debugging.

On the output side, the new output structure definition supplements field names, example values and usage descriptions to help different roles understand model return content.

This update does not change the business logic of model invocation itself, but further improves configuration and information descriptions before and after invocation. For enterprises that require algorithm teams, business users and system integration personnel to jointly participate in model applications, clearer parameter definitions and output descriptions help reduce repetitive communication and make the model usage process smoother.

Going forward, qModel will continue to refine the product experience across the full chain of “development, deployment, invocation and understanding,” and continue to advance the application of algorithm capabilities in actual business.

AlgorithmPlatform #ModelInvocation #APIIntegration #OutputSchema #OpenSource #qModel

🚀 qKnow Intelligent Agent Building Platform Open-Source Edition v2.4.4 is now released.

TongWu — Wed, 04 Nov 2026 07:35:07 +0000

This update focuses on Agent conversation continuity, reasoning process display and orchestration asset reuse. It adds memory control, reasoning process display configuration, and Agent and workflow resource import capabilities, while continuously optimizing the agent creation, debugging and orchestration workflow to help developers build and reuse lightweight intelligent applications more conveniently.

Improving long-term memory for Agents to make cross-session conversations more coherent

In intelligent agent applications, conversations are not always completed in one session. Users may continue the same task at different times, and follow-up questions may depend on information already exchanged. If an Agent cannot carry context across sessions, conversation continuity can be affected.

Previously, Agents under the Bot system still lacked long-term memory control, making it difficult to stably carry context in cross-session scenarios. This affected use cases requiring continuous communication and increased developers’ need to configure Agent conversation behavior.

To address this, qKnow Open-Source Edition v2.4.4 adds conversation history and long-term memory switches. Developers can independently control whether to enable memory capabilities according to actual needs. When enabled, Agents can continuously carry context across sessions, supporting long conversation continuity. Developers can also decide whether to enable memory based on application requirements, rather than having memory fixed as a single usage mode.

This update mainly addresses two issues:

🔹 Continuity of conversation context: supporting Agents in carrying previous context for scenarios requiring multi-turn communication and cross-session continuation.

🔹 Autonomous control of memory capabilities: developers can decide whether to enable conversation history and long-term memory based on application requirements.

For intelligent applications requiring continuous interaction, conversation continuity is an important factor affecting user experience. This update provides developers with clearer memory control, though specific effects still depend on actual application scenarios and memory configuration.

Adding reasoning process display configuration for debugging and demonstration needs

During agent development, debugging and external demonstrations often have different display requirements. When troubleshooting, developers need to understand the Agent’s reasoning process to analyze execution and locate issues. When demonstrating features to external users, the focus is usually on final conversation results, and detailed reasoning processes may not need to be displayed.

If display methods lack flexible control, it is difficult to adapt to both development debugging and external demonstration scenarios. To meet this need, qKnow Open-Source Edition v2.4.4 adds Agent reasoning process display configuration, supporting on-demand enabling or disabling of Agent reasoning process display.

During debugging, developers can enable the display to view the complete reasoning chain and assist in locating issues. During external demonstrations, reasoning process display can be disabled to hide related details and make conversation results more concise.

The focus of this capability is not to change the Agent’s reasoning ability, but to provide a configurable display method for the reasoning process, allowing the same Agent to adjust displayed content according to different usage scenarios. For developers who need to repeatedly debug, validate and demonstrate Agents, this configuration allows debugging analysis and result presentation to adapt to different needs, providing more flexible options for troubleshooting and application demonstrations.

Supporting Agent and workflow resource import to reduce repetitive orchestration

Intelligent agent application development includes not only single Agent configuration, but may also involve workflows and their orchestration relationships. After completing local debugging, if developers need to migrate existing orchestration results to the platform for continued use, repeated configuration and rebuilding increase workload.

This issue can be summarized as: Agent and workflow orchestration assets completed through local debugging cannot be quickly migrated and reused, with many repetitive configuration processes, increasing the onboarding cost for developers building lightweight intelligent applications. As orchestration assets accumulate during development, making existing results easier to bring into the platform and continue using has become a practical need in open-source development scenarios.

To this end, qKnow Open-Source Edition v2.4.4 adds Agent and workflow resource import capabilities, supporting the import of locally debugged orchestration process assets into the platform to reduce repetitive configuration and rebuilding.

This update focuses on the flow and reuse of existing orchestration assets. Developers can import already debugged Agent or workflow resources into the platform for continued use, without having to rebuild the same orchestration content from scratch every time. Its practical value is mainly reflected in three aspects:

🔹 Reducing repetitive configuration: existing orchestration resources can be imported into the platform, lowering the workload of repetitive building.

🔹 Promoting asset reuse: turning locally debugged orchestration results into resources that can continue to be used.

🔹 Improving development continuity: making resource flow between local debugging and platform use more convenient.

Continuously optimizing the full-chain agent experience to lower the developer onboarding threshold

In addition to the three specific capabilities above, qKnow Open-Source Edition v2.4.4 also continuously improves the basic experience of the full agent creation, debugging and orchestration process. From a development perspective, building intelligent agent applications is not a single operation but involves creation and configuration, debugging and validation, orchestration and organization, and subsequent adjustments. When the experience in these stages is not sufficiently polished, developers need to spend more time familiarizing themselves with operation processes, which is also not conducive to accumulating and reusing existing orchestration results.

This update optimizes the experience around the full Agent creation, debugging and orchestration process, and combines memory switches, reasoning process display configuration and resource import capabilities to further improve the development experience for lightweight intelligent applications.

These capabilities act on different stages:

🔹 Creation and conversation stage: on-demand control of memory capabilities through conversation history and long-term memory switches.

🔹 Debugging and display stage: adapting to different needs of troubleshooting and external demonstrations through reasoning process display configuration.

🔹 Orchestration and reuse stage: reducing repetitive building of existing orchestration assets through Agent and workflow resource import.

Viewed within the entire development process, these updates are not isolated feature points but respectively respond to practical needs such as conversation continuity, debugging display and orchestration resource reuse. For open-source developers hoping to quickly build lightweight intelligent applications, continuously improving these basic stages helps reduce repetitive operations during development and makes existing capabilities and orchestration results easier to put into subsequent use.

Summary: Continuously improving the agent building experience around actual development needs

The updates in qKnow Intelligent Agent Building Platform Open-Source Edition v2.4.4 mainly focus on three specific issues in agent development and use:

🔹 Lack of memory control for cross-session conversations;

🔹 Different display needs for reasoning processes in debugging and demonstrations;

🔹 Difficulty in quickly reusing locally completed Agent and workflow orchestration assets.

To address these issues, this version adds conversation history and long-term memory switches, Agent reasoning process display configuration, and Agent and workflow resource import capabilities, while continuously optimizing the full-chain experience of agent creation, debugging and orchestration.

From the product iteration direction, these updates focus on supplementing basic capabilities and improving usage processes rather than simply increasing the number of features. For enterprises and developers, building agents requires not only capability configuration but also consideration of whether conversations can continue, whether debugging is convenient, and whether existing orchestration results can be reused.

Going forward, qKnow will continue to focus on the actual usage needs of open-source developers, continuously refine the basic capabilities and user experience in the agent building process, and support the development and iteration of lightweight intelligent applications.

IntelligentAgents #AgentMemory #WorkflowOrchestration #OpenSource #qKnow #AIApplicationDevelopment

🚀 qKnow Intelligent Agent Building Platform Professional Edition v3.1.5 is now released.

TongWu — Wed, 04 Nov 2026 07:30:46 +0000

This version deeply optimizes intelligent application development efficiency by expanding workflow orchestration and invocation capabilities and officially launching the Text2SQL plugin. It connects underlying metadata with upper-layer orchestration assets, further lowering the barrier to building data-driven intelligent applications.

From capability invocation to data query, application development can be more connected

As intelligent application business logic becomes increasingly complex, a single Agent or standalone tool often cannot meet complete business processing needs. How to reuse validated orchestration resources, how to make different tools work together in the same process, and how to help large models understand database structures more accurately have become key considerations in application development.

Making existing orchestration resources easier to reuse

In complex application development, if Agent and workflow resources lack convenient nested invocation methods, developers need to rebuild existing logic repeatedly. For processes that have already been debugged and validated, the inability to reuse them directly also increases subsequent development and maintenance costs.

Making different capabilities work together in the same process

MCP, Skills and various tools carry different capability responsibilities, but if they can only be invoked through separate entry points, data processing tasks are easily split into multiple stages. For business scenarios that require continuous execution of multiple steps, developers also need to handle the connections between different capabilities.

Giving natural language queries more complete data context

Natural language database queries are not just about converting user questions into SQL. Models also need to understand which tables exist in the current data source, which fields those tables contain, and how these structures are related. Without metadata such as data sources, tables and fields, large models cannot fully understand database structures, and natural language SQL generation is limited by insufficient context, especially in query scenarios involving multi-table joins.

Reducing the work of building SQL capabilities from scratch

SQL generation, correction and optimization usually involve multiple stages. If the platform lacks directly usable Text2SQL assets, users need to build related processes themselves and then combine and adjust capabilities according to actual needs.

To address these issues, qKnow Professional Edition v3.1.5 updates workflow invocation, MCP metadata query and Text2SQL capabilities, further improving the orchestration and data query chain for intelligent applications.

What’s new in this release?

🔹 Expanded workflow orchestration capabilities: existing resources can continue to be combined

This version expands workflow invocation capabilities and supports importing and invoking existing Agent and workflow resources. At the same time, MCP, Skills and various tools can also be orchestrated through a unified workflow entry point. This means developers can organize new business logic based on existing resources and connect different capabilities into the same workflow without building the complete process from scratch every time. By combining existing resources, workflows can carry more complex processing logic, help reduce repetitive construction work, and enable validated capabilities to be reused across different applications.

🔹 MCP metadata query: adding structural information for data queries

This update enhances MCP metadata query capabilities, supports obtaining information about data sources, tables and fields, and supports executing SQL. With these capabilities, Agents can obtain more complete database structure information when handling data query tasks. Compared with understanding query requirements only from user input, combining table structures and field information from actual data sources helps provide necessary context for subsequent SQL generation. This capability provides a foundation for natural language data queries and creates conditions for combining Text2SQL with database metadata.

🔹 Text2SQL plugin officially launched: covering multiple stages of SQL processing

This version officially launches the Text2SQL plugin asset. Built on the platform’s Bot and workflow orchestration capabilities, the plugin provides multiple capabilities around SQL processing, reducing the work required for users to build related processes from scratch.

SQL generation and rewriting: Text2SQL supports SQL generation and rewriting, which can be used to convert query requirements into SQL or adjust existing SQL according to new requirements.

SQL correction and performance optimization: In addition to generation and rewriting, the plugin also covers SQL correction and performance optimization capabilities, helping users handle issues encountered during SQL writing and adjustment.

SQL comment generation and continuation: The plugin also supports SQL comment generation and SQL continuation, further covering needs related to SQL writing and improvement.

Unlike implementing each SQL function separately, Text2SQL organizes the above capabilities into reusable workflow units. Each SQL sub-capability can be used independently and can also be combined into other Agents or applications according to application needs. This organization provides a foundation for reusing SQL capabilities in different business scenarios, allowing users to combine corresponding processes according to actual needs without fixing all capabilities in a single application.

🔹 Combining Text2SQL with MCP: improving the natural language data query chain

When Text2SQL is combined with MCP metadata query capabilities, structural information such as data sources, tables and fields can be used as context input, providing more specific data structure references for SQL generation. On this basis, the platform can better support natural language to SQL and provide capability support for scenarios such as complex multi-table queries. Users can also further build customized data query and analysis assets according to their own business needs.

From workflow resource reuse to MCP obtaining database structure information, and then to Text2SQL covering SQL processing stages, this update further connects intelligent application orchestration and data query capabilities.

Final notes

qKnow Professional Edition v3.1.5 makes targeted improvements around workflow orchestration, MCP metadata query and the Text2SQL plugin:

Workflows support invoking existing Agent and workflow resources and uniformly orchestrating multiple types of tools;

MCP can obtain metadata for data sources, tables and fields;

Text2SQL covers SQL generation, rewriting, correction, performance optimization, comment generation and continuation, and supports reusing each capability as a workflow unit.

These updates provide a more complete capability foundation for building complex intelligent applications, organizing data processing flows and carrying out natural language data queries. Specific usage can be configured according to actual business needs and application flows.

In the digital economy era, enterprises have urgent needs to activate data assets and apply intelligence. The release of qKnow Professional Edition v3.1.5 is a precise iteration based on the actual pain points enterprises face when building complex business agents. Through orchestration expansion for asset reuse, structural completion of underlying metadata, and standardized encapsulation of Text2SQL plugin assets, qKnow further broadens the boundaries of building data-driven intelligent applications.

In the future, qKnow will continue to deepen its work in enterprise-level AI infrastructure and help enterprises move steadily forward on the path of intelligent transformation with more professional and easier-to-use product capabilities.

IntelligentAgents #WorkflowOrchestration #Text2SQL #MCP #DataQuery #EnterpriseAI #qKnow

🚀 qData Data Middle Platform Professional Edition v3.0.1 is now released.

TongWu — Wed, 04 Nov 2026 07:26:53 +0000

Building on v3.0.1, this version further improves business planning, data modeling and indicator management. It adds version management for business entities and multiple model types, and optimizes data standard association, data integration task validation and FTP file access — continuing to improve platform completeness and stability.

Here’s what’s new:

Modeling overview and category tree statistics

The modeling overview now includes statistics for data domains, subject areas, conceptual models, logical models, indicator models and published models, and supports viewing model layering distribution and model status distribution.

A new “latest activity” section covers additions, modifications and deletions of logical models and indicator models, as well as logical model publishing.

The category tree now improves object counts for subject areas and conceptual models; source-aligned, dimension, fact, summary and application logical tables;

and atomic indicators, business constraints and derived indicators. Users can drill down from the data domain list to the business planning page, and from the subject area list to the business entity page, with corresponding filters automatically applied.

Business entity relationship management and historical versions

qData v3.0.1 supports maintaining relationships between business entities, including inheritance, association, flow, predecessor/successor and containment. Relationship validation is improved during business entity creation and editing, and conceptual model relationship data is maintained based on entity relationships.

The business entity list now displays inheritance and containment relationships, supports expand/collapse and one-click expand/collapse, and allows users to view the conceptual model diagram of entity relationships.

A new business entity version management capability supports viewing historical versions and comparing differences between versions.

Conceptual model relationship graph

A new conceptual model relationship graph is added, with filtering, viewing, editing and linked operations. It supports displaying conceptual model categories by data domain, subject area, business object classification and business object layering.

The left side supports filtering by data domain, subject area and business entity. Users can click relationship-type legends to highlight corresponding relationships, click node legends to highlight nodes, and select a node to highlight its entire related node relationship. Entity node and relationship details can also be viewed.

The graph supports quick editing of business entities, and creating logical tables, sub-objects and associated entities directly from the graph. Legends for node types and relationship types can be expanded or collapsed, and clicking a legend highlights corresponding nodes or relationships on the canvas. The relationship graph can also be viewed in the business entity tab of data domain details.

Logical model design optimization

For source-aligned logical tables, the update adds source physical table structure detection and synchronization, supporting manual detection of structural changes and synchronization to the source-aligned logical table. Model history versions can be viewed and compared.

For dimension logical tables, the platform supports automatic generation of foreign key fields and associated dimensions based on entity relationships. Default fields and field attributes can be modified. Multiple associated dimensions can be configured, with automatic matching and display of associated dimension information based on associated business entities.

If the selected business entity does not yet have a corresponding logical table, users can quickly create one during associated dimension selection. Dimension logical tables also support importing fields from existing logical tables and generating table structures through SQL parsing.

For version maintenance, application table version maintenance capabilities are also listed, including viewing model history versions and comparing different historical versions.

For fact logical tables, business event tables support automatic generation of primary keys, associated entity IDs and event time fields. Business process tables support automatic generation of primary keys, associated event time, process start time and process end time fields. Default fields can be modified, field attributes maintained and fields manually added, and multiple associated dimensions configured. Business event tables support automatic matching and display of associated dimension information based on associated business entities, with quick creation of logical tables if needed. Fact logical tables support importing fields from existing logical tables and generating table structures through SQL parsing. Version maintenance provides application table history version viewing and comparison.

For application logical tables, the update supports importing fields from derived indicators, data elements and code tables, and generating table structures through SQL parsing. Users can view application table model history versions and compare different historical versions.

For summary logical tables, when creating or maintaining derived indicators, the platform automatically matches summary logical tables based on the selected statistical granularity and establishes ownership between derived indicators and summary logical tables. Users can view associated logical table information in the upstream dependencies of derived indicators. Summary logical tables also support viewing model history versions and comparing different historical versions.

Indicator management and new derived indicator module

Atomic indicators now support viewing bound derived indicators in their details, and add version management with historical version viewing and comparison.

Business constraints now support viewing associated derived indicators, and improve version management and historical version comparison. For business constraints with downstream dependencies, a dependency protection mechanism restricts destructive editing, deletion and disabling operations that may affect downstream use.
indicator management module supports viewing and managing derived indicators. Users can filter by derived indicator name, associated summary logical table and status, and add, view details, modify, delete and manage status. The list displays derived indicator information, ownership information, atomic indicators, business constraints and statistical periods. Details include basic information such as name and ownership. A new upstream dependencies tab shows associated logical table information, including logical table name, type and ownership.

Derived indicator version management supports viewing historical versions, version generation time, change type and operator, and comparing different versions with field-level differences.

Data standard association, data integration and FTP access

For data standards, when asset fields are bound to data elements or code tables, the details of the corresponding data element or code table display information about the currently associated assets.

For data integration tasks, pre-execution configuration and parameter validation are enhanced, with relevant logs output. Validation is improved for cases such as insufficient database field length that may cause task failure. For insufficient task memory and resources, guardrail handling and resource configuration suggestions are further improved.

The FTP input component is optimized for multi-file access when an FTP directory contains multiple data files, TXT file parsing when TXT files are used as input with field separators, and cleanup of processed files after FTP file access.

In summary

qData Data Middle Platform v3.0.1 continues to improve product capabilities around two main lines: data modeling and indicator management.

At the business planning level, it adds business entity relationship maintenance, historical version management and conceptual model relationship graph interaction.

At the logical model level, it improves source table structure detection and synchronization, dimension and fact logical table field design, application logical table field import, summary logical table and derived indicator association, and historical version viewing and comparison for multiple model types.

At the indicator management level, it adds a derived indicator management module and improves association viewing and version maintenance for atomic indicators and business constraints.

The platform also improves associated asset information for data elements and code tables, and optimizes pre-execution validation, resource configuration suggestions and the FTP input component for data integration tasks.

qData Professional Edition will continue to advance product iteration around actual usage needs and gradually improve data middle platform capabilities.

DataMiddlePlatform #DataModeling #IndicatorManagement #DataIntegration #qData #DataGovernance

qData Data Middle Platform Open-Source Edition v1.6.5 Released: Enhanced Doris Data Source Adaptation and New Demo Data Cleanup Script

TongWu — Wed, 04 Nov 2026 07:21:20 +0000

As data platform scenarios continue to expand, database compatibility and post-deployment experience are becoming increasingly important for developers. Platforms need to let existing data sources participate in more functions, and they also need to consider how to clean up the demo environment after product experience is complete.

qData Data Middle Platform Open-Source Edition v1.6.5 is officially released. This update focuses on enhanced Apache Doris data source adaptation and a new demo data cleanup script, improving data management and development capabilities as well as the data cleanup process for demo environments.

Expanded Doris Data Source Support to Improve Data Management and Development

Apache Doris is an open-source analytical database for real-time analytics, commonly used in data analysis, report queries and other business scenarios. Previously, qData Open-Source Edition already supported Doris data source connection, data query and data integration. Based on that, v1.6.5 further extends Doris data source support to metadata management and data development, enabling it to participate in more daily data management and development processes.

Metadata management now supports Doris data sources

In enterprise data platforms, data tables and fields continue to increase as business grows. Beyond connecting to and querying data, the platform also needs to understand the structure and basic information of data resources for subsequent data management. After this update, the metadata management module of qData Open-Source Edition supports Doris data sources. Users can bring relevant Doris data resources into the platform’s metadata management process, further improving unified management of data resources. This update complements Doris adaptation in metadata management scenarios, allowing it to be used for data resource management within the platform in addition to existing connection, query and data integration capabilities.

Data development now supports Doris data sources

In actual data processing, Doris can serve not only as a target for data storage and query, but also be used directly for data processing and SQL development. Therefore, whether a data source can be used in the data development module is also part of database compatibility. v1.6.5 also expands support for Doris data sources in the data development module. Users can use Doris data sources in the qData data development module for relevant data development work. Through this expansion, the application scope of Doris data sources in qData Open-Source Edition is further complemented, and existing capabilities such as data connection, data integration, metadata management and data development can form a more complete connection.

New Demo Data Cleanup Script for More Convenient Environment Data Management

To help developers quickly get familiar with product functions, qData Open-Source Edition provides demo data so users can experience data integration, data development and other functions after deployment. However, demo data is mainly for product experience. After the experience is complete, users may need to clean up related data and organize the environment according to their actual needs. Manually cleaning table by table is relatively cumbersome and prone to omissions.

For this scenario, qData Data Middle Platform Open-Source Edition v1.6.5 adds a demo data cleanup SQL script, making it easier for users to centrally clean up related data in the demo environment.

How does the script clean demo data?

The script mainly uses DELETE FROM statements to delete records in specified data tables. While cleaning the corresponding data, it retains the table structure, reducing repeated manual SQL execution table by table. For developers who want to experience the product first and then configure data according to their own needs, this update makes subsequent cleanup of demo data more convenient and further improves the workflow from product experience to environment organization.

Please note that before executing the cleanup script, users should confirm that the corresponding data tables do not contain business data that needs to be retained, and make necessary backups in advance to avoid accidentally deleting important records. Especially in data environments already used for actual business, the cleanup scope should be checked before executing related operations.

Continuous Improvement of Data Source Adaptation and Open-Source Product Experience

The two updates in qData Data Middle Platform Open-Source Edition v1.6.5 focus on data management capabilities and environment experience. On one hand, Doris data source support is further extended to metadata management and data development modules, complementing Doris usage in daily data management and development workflows. On the other hand, the new demo data cleanup SQL script provides a more convenient way to organize data after product experience is complete.

For developers who continue to use qData, continuous supplementation of data source adaptation helps more existing databases participate in the platform’s data management and development processes, while improved demo data cleanup makes environment organization after product experience clearer. Continuous iteration of open-source products is reflected not only in new features, but also in ongoing improvements to existing functions, database adaptation and usage details.

In the future, qData will continue to focus on developers’ actual needs and community feedback, and continue to optimize core capabilities such as data integration, data development and data governance to provide users with a more flexible and easy-to-use open-source data middle platform.

Welcome to download and experience qData Data Middle Platform Open-Source Edition v1.6.5, and provide feedback on issues and suggestions through Gitee Issues or community channels.

Project addresses:

Gitee: https://gitee.com/qiantongtech/qData GitHub: https://github.com/qiantongtech/qData

Let’s work together to support the continuous improvement of qData Open-Source Edition and make data management and development simpler and more efficient.

🎉 Introducing qOntology Open-Source: From Documents and Scripts to a Unified Ontology Engineering Workbench

TongWu — Tue, 27 Oct 2026 03:09:16 +0000

As enterprise data and AI agents grow, a fundamental problem emerges: Are business concepts across different systems actually the same thing? For example, is the "Supplier" in a procurement system the same as the "Vendor" in contracts? Relying on scattered documents causes constant semantic ambiguity for data integration and knowledge graphs.
To solve this, we are thrilled to announce that qOntology is officially open-sourced! 🚀
qOntology goes beyond simple relationship diagramming. It brings Ontology Engineering into a unified workflow, turning scattered business definitions into manageable, reusable semantic assets.
Why move from "Modeling" to "Engineering"?
As models scale, definitions become hard to unify, structures get out of sync, and version control turns into chaos. Downstream users need to know what changed and which version is valid.
What the Current Open-Source Version Offers:
🎯 Goal Management: Start with the business problem, define scope, and set clear boundaries.
📖 Terminology & Enums: Centrally maintain definitions and aliases (e.g., unifying "Supplier" and "Vendor") to build a shared semantic understanding.
🧱 Ontology Modeling: Define object types, attributes, and relationships with clear business meanings, making the model fully explainable.
(Upcoming Roadmap) We plan to add Quality Checks (rule-based validation) and Version Release & Standard Export to complete the engineering cycle.
Open for Developers
Developers can pull the code, follow the Quick Start guide, and validate the workflow in real-world scenarios.
Let’s move from "modeling once" to "continuously maintaining enterprise semantic assets." 🌐
👉 Explore the Repository:
🔗 Gitee: https://lnkd.in/g4DkjZ5C
(Note: Please refer to the actual license terms and latest release notes in the repo for usage.)

qOntology #OntologyEngineering #KnowledgeGraph #OpenSource #DataManagement #AI #SemanticWeb

🚀 Iteration for open-source products isn't just about expanding new features; it's about continuously polishing daily pain points

TongWu — Tue, 27 Oct 2026 03:07:25 +0000

Today, we are thrilled to announce the official release of qData Data Middle Platform Open-Source v1.6.4!
For a data middle platform, an excellent user experience lies in accurate feedback for every configuration and seamless access to every documentation page. Rather than a massive refactoring, this version is deeply rooted in real feedback from our community developers, precisely addressing three specific issues that directly impact the user experience:
🛠️ Data Modeling: Fixed abnormal status prompts for data warehouse layering.
Say goodbye to the confusion of mismatched operation feedback and actual status (e.g., displaying "Disabled" after being enabled), allowing developers to confirm configuration states more intuitively and accurately.
📚 Help Documentation: Fixed 404 redirect errors on the standard data elements page.
We've repaired the documentation access link, reducing extra search steps when developers need to consult instructions while operating, making feature learning and troubleshooting much smoother.
💾 Database Adaptation: Fixed Kingbase data integration encoding issues.
We have improved the processing logic within existing Kingbase integration scenarios to reduce the impact of specific encoding anomalies on synchronization tasks, enhancing the actual usage experience.
The voice of the community is the driving force behind our continuous evolution.
qData Open-Source will keep refining feature stability, operational experience, and developer convenience, better supporting your learning, research, technical validation, and actual data processing scenarios.
If you encounter any issues or have suggestions for improvement while using qData, we welcome you to connect with us at any time!
👉 Gitee: https://lnkd.in/gniHYFQ5
👉 Community: https://lnkd.in/gkT_3HFT
👉 Feel free to submit feedback via Gitee Issues and join us in continuously improving qData!

qData #DataPlatform #OpenSource #DataModeling #TechUpdate #DeveloperCommunity #Kingbase

Accurately Tracking River Diversion Dynamics to Enhance Water Resource Dispatch Capabilities

TongWu — Fri, 23 Oct 2026 06:55:35 +0000

Business Pain Point Analysis

Water resource scheduling depends on timely awareness of the latest status of different water intake objects such as rivers and canals, wells, and pump stations. However, monitoring object types are diverse, and water intake information is scattered across different business scenarios. Management personnel often need to search separately among river and canal monitoring stations, wells, and pump station data, making it difficult to quickly form an overall judgment of regional water intake conditions.

At the same time, data at different time scales serves different analytical functions: real-time water regime reflects the current status of a monitoring station, hourly water regime presents short-term change processes, and daily water regime is used to understand and verify daily water regime conditions. Without a coherent way to view them, management personnel may see data at a single point in time but find it difficult to combine current status with stage changes for analysis.

Daily water regime also involves both reviewed data and automatic monitoring data. Once the two types of data are viewed separately, it not only increases verification workload but also makes it difficult to promptly identify differences between them. How to centrally view different water intake objects, connect different time scales, and intuitively conduct data comparison constitutes an important foundation for improving water resource scheduling efficiency.

To address these problems, the platform builds centralized water intake and water regime monitoring capabilities, aggregating river and canal real-time water regime, hourly water regime, and daily water regime, and centrally presenting the latest water intake information of wells and pump stations. Management personnel can view the current data of each monitoring station, further query historical records and change processes of monitoring stations, and compare reviewed data with automatic monitoring data in daily water regime, providing data reference for water regime verification and water resource scheduling.

Core Function Description: From Centralized Monitoring to Process Traceability

1. River and Canal Water Diversion

Real-Time Water Regime: Grasp Current River and Canal Water Diversion in One Table

River and canal real-time water regime centrally presents the most recent monitoring results of each station. After entering the page, management personnel can view monitoring time, water level, and flow, quickly forming an overall judgment of the current river and canal water diversion situation. The page provides filter conditions such as basin, administration bureau, management office, management station, and station type, supporting both retrieval by regional scope and gradual narrowing of the viewing scope along the management hierarchy.

On the basis of grasping the current status, clicking the station name allows further viewing of the station's time-period water regime. After setting the start time and end time, the system displays water level and flow records within the corresponding period and simultaneously generates a water level and flow process line, extending data at a single point in time into a continuous change process.

Current query results and station details both support export, and process charts can also be saved as images, facilitating retention of water regime materials and providing data reference for subsequent analysis and scheduling decisions.

Hourly Water Regime: Extending from Real-Time Data to Change Processes at the Hourly Scale

Real-time water regime focuses on "now," while hourly water regime further presents changes in water regime at the hourly scale. The page displays water level, flow, and hourly water intake corresponding to each station by time, helping management personnel understand water intake performance in different periods. Combined with filter conditions such as basin, management unit, and station type, stations requiring attention within the scope of responsibility can be quickly located.

After clicking the station name, the page expands the station's hourly water regime records within the specified period in chronological order and presents changes in water level and flow through process lines. Management personnel can thereby connect the latest data with preceding and following periods and judge whether short-term changes are continuous and whether the change amplitude is significant.

The hourly water regime list and station details both support export, and process charts can also be saved separately, facilitating organization of staged water regime materials and providing a basis for change analysis and scheduling assessment.

Daily Water Diversion Regime: Same-Screen Comparison and Verification of Reviewed Data and Automatic Monitoring Data

Daily water diversion regime focuses not only on the daily data itself but also on verification between different data sources. After selecting a date, management personnel can complete the query in combination with conditions such as basin, administration bureau, management office, management station, and station type. The page simultaneously displays reviewed water level, reviewed flow, data source, as well as automatic monitoring water level and automatic monitoring flow, enabling daily water regime and its source to be viewed comparatively within the same interface, with differences intuitively presented.

For stations requiring further verification, clicking the station name allows viewing daily water regime records within the specified date range. In the list, reviewed data and automatic monitoring data are presented side by side, and water level comparison charts and flow comparison charts are generated respectively, allowing intuitive identification of whether differences exist between the two types of data.

Station lists and detail data both support export, and the two sets of comparison charts can also be saved as images, facilitating daily water regime verification, difference analysis, and retention of related materials.

2. Centralized Presentation of Engineering Water Intake Information: Classified Viewing of Wells and Pump Stations

Well Water Intake: View the Latest Water Intake Information by Specific Well

The well water intake page organizes monitoring information by specific well. Management personnel can select one or more basins to centrally view management unit, well name, well code, monitoring time, and the latest water level and flow, and further drill down from the management unit to specific wells to grasp the most recent water intake monitoring situation of relevant wells.

Pump Station Water Intake: View the Latest Water Intake Situation of Pump Stations Level by Level According to Management Hierarchy

The pump station water intake page organizes data level by level according to management office, management station, and monitoring station, and displays the monitoring time, water level, and flow of each station. Management personnel can limit the viewing scope by one or more basins and then, combined with the management relationships in the table, grasp the latest monitoring results of different stations, thereby forming an overall understanding of regional pump station water intake dynamics.

Business Application Value: Four Improvements from Scattered Viewing to Centralized Grasp

1. More Centralized Information Viewing

The platform brings river and canal real-time water regime, hourly water regime, daily water regime, and well and pump station water intake information into the same water intake monitoring module. Management personnel can switch views according to actual business scenarios, reducing the workload of repeatedly searching across different systems or scattered materials and improving the efficiency of obtaining water intake information.

2. More Intuitive Water Intake Changes

Real-time data is used to understand current status, hourly data is used to observe short-term changes, and daily water regime is used to grasp and verify daily conditions. Combined with station time-period queries and water level and flow process lines, management personnel can trace from a certain point in time to the change process over a period of time, forming a more coherent understanding of the water regime.

3. More Convenient Data Verification

Daily water regime presents reviewed data and automatic monitoring data side by side and intuitively presents differences in water level and flow through two sets of comparison charts. Management personnel can complete data verification within a specified date range for a station without repeatedly switching between different data sources.

4. More Evidence for Scheduling Assessment

By centrally viewing water level and flow information of different water intake objects and different time scales, management personnel can promptly grasp water intake dynamics, analyze stage changes, and verify daily water regime data, providing more complete and intuitive data reference for water resource scheduling.

Conclusion

The platform aggregates river and canal water diversion, well water intake, and pump station water intake information, achieving viewable current conditions, traceable change processes, and verifiable data differences, promoting the transformation of water intake information from scattered viewing to centralized grasp, and providing data support for refined water resource scheduling.

From "Knowing" to "Doing": Empowering LLMs with Native MCP in qKnow Professional Edition

TongWu — Fri, 23 Oct 2026 06:54:47 +0000

I. From "Can Answer" to "Can Execute": The Missing Link in LLM Implementation

Enterprises have built many business systems and continue to accumulate APIs, tools, and data services. However, large models themselves do not naturally perceive the existence of these capabilities, nor can they automatically identify which services can be called, what parameters are needed, and how call results should be written back to business processes.

In actual projects, models can often explain problems but struggle to directly complete tasks. When users ask "What branches are available nearby," "Is this invoice authentic," "Where is this IP located," or "Help me look up a batch of materials," if the model lacks a reliable tool entry point, its output can only remain at the level of reasoning and suggestions.

qKnow Professional Edition fully integrates the MCP Service Management module, aiming to solve the problem of whether agents can truly execute—in a secure, standardized, and manageable way—when querying maps, reading business data, retrieving literature, validating invoices, or calling enterprise tools.

In the past, many large model projects remained at the stage of knowledge Q&A and process suggestions for a long time. Once entering real business scenarios, they often face challenges such as system isolation, scattered interfaces, unclear permissions, and untraceable call processes. The value of MCP lies precisely in establishing a governable connection protocol between models and enterprise systems, pushing agents from "can talk" further toward "can do."

II. qKnow Professional Edition: Making MCP a Manageable Service Entry Point

In qKnow Professional Edition, MCP is no longer confined to configuration files in developers' hands but is brought into a platform-based unified management system. Administrators can view each service's name, description, type, tool count, status, creator, and creation time in the MCP list, and control whether the service is open to agents through an enable/disable switch. As a result, enterprises do not need to expose all external capabilities to the model at once but can ingest them in batches based on specific scenarios and enable them on demand, keeping capability supply aligned with business needs.

III. Custom MCP Services: Bringing Existing Enterprise Systems into Unified Integration

qKnow Professional Edition also supports adding custom MCP services. Administrators only need to enter the service name, description, type, URL, and request header information to encapsulate existing business systems, data interfaces, or professional tools as standard MCP services.

This path better fits enterprise internal implementation scenarios. The reason is that capabilities with real business value are often not on the general internet service side but concentrated in enterprises' own order systems, knowledge bases, operations platforms, data assets, approval processes, and industry applications. With custom MCP, these capabilities are unified under the same protocol, eliminating the need to develop a separate integration logic for each agent.

IV. Sync, Enable/Disable, and Import: Turning Capability Integration from "Code Modification" into "Platform Selection"

After services are integrated, the platform also needs to ensure the tool list stays up to date. The sync operation in the MCP list can re-pull the tool list of a specified service, preventing agents from calling expired capabilities. For services no longer suitable for exposure, their status can be directly disabled.

In the agent orchestration phase, MCP supports import just like knowledge bases, tools, and Skills. Builders only need to select an enabled MCP service, and the agent gains the corresponding tool capabilities. At this point, capability integration shifts from "code modification" to "platform selection."

V. The Real Key: Keeping AI Actions Controllable

The change MCP brings is not just a few more tool entry points in the interface. It enables enterprises to describe capabilities with a standard protocol, manage capabilities through platform entry points, control capabilities with status switches, sync capabilities with tool lists, and then assign these capabilities to specific agents.

For business users, agents no longer just answer "what should be done" but can execute queries, retrievals, validations, planning, and task triggering within permission boundaries. For administrators, AI's action capabilities are not spreading uncontrollably but are gradually brought into the enterprise governance system under the joint constraints of service registration, enable/disable management, permission boundaries, and call auditing.

For this reason, the core value of qKnow Professional Edition integrating the MCP Service Management module is not to make large models appear "smarter" but to give agents the real action capability to connect to real systems, call professional tools, and complete complex tasks.

AI implementation should not remain at the level of paper plans—it needs hands and feet that can safely reach into business operations.

MDM Implementation Pitfalls: 5 Critical Questions to Ask Before You Start

TongWu — Fri, 23 Oct 2026 06:53:59 +0000

Every time an enterprise conducts a data asset inventory or plans next year's IT roadmap, an old problem resurfaces: many systems have been built, yet data still doesn't "match up."

Master Data Management (MDM) is often expected to solve this, but during implementation, projects often get stuck in the same place—IT feels business isn't cooperating, business feels IT is "talking to itself," and the project eventually risks becoming an abandoned effort.

As a technology company long dedicated to the data domain, we've combined frontline experience to summarize the 5 questions enterprise customers ask most often during MDM implementation. This article aims to explain key issues in a straightforward way, helping enterprises identify risks early and avoid detours during inventory and planning.

I. Many Systems Built, Why Is Data Still Hard to Align?

During inventory season, enterprises often face an awkward reality: ERP, CRM, SRM, finance, and supply chain systems are all running, but customer names are inconsistent, multiple material coding schemes exist, supplier information is duplicated, and organizational definitions don't match.

The more systems there are, the more scattered the data becomes, and the harder it is to form unified, trustworthy, and reusable data assets.

This is why MDM is often mentioned. But MDM is not a "buy and use" tool—it is a management system built around master data standards, models, processes, quality, integration, and distribution. When implementation fails, it's usually not a single technical point issue, but a failure to connect business consensus, rule design, and system collaboration.

1. Why Does the Focus of Master Data Management Fall on Model Management and Master Data Management?

Master data is the core entity data of an enterprise, such as customers, materials, suppliers, organizations, and personnel. It is shared across multiple systems and must have unified definitions, standards, and maintenance. If each system builds its own coding scheme and maintains its own fields, data asset inventory will never match up.

Therefore, the focus of MDM is not just "centralizing data," but first defining what master data "looks like, what fields it has, how fields relate, who maintains it, how it is approved, how it is published, and how it is distributed." This corresponds to model management and master data management.

2. What Does Model Management Do? What Does Master Data Management Do?

Model management is responsible for structural definition and standard consensus of master data. It manages the "skeleton" and "rules": how master data models are built, how fields are defined, what coding rules are, how entities are associated, how versions are managed, and how standards are reviewed.

When model management is clear, business can intuitively see the structure and relationships of master data, and standards won't become IT's closed-door monologue.

Master data management is responsible for the full lifecycle of master data. It manages "data and processes": how master data is created, maintained, reviewed, published, distributed, and traced.

Models are standards; master data management is about making standards truly land in daily business actions.

3. What Are Multi-Source Fusion and Rule Management?

Multi-source fusion is the process of aggregating, mapping, cleansing, and merging data from different sources—databases, CSV/XLS/XLSX files, HTTP APIs—according to a unified master data model to form trustworthy master data.

Enterprises have many systems; the more data sources there are, the more critical multi-source fusion becomes.

Rule management is about configuring data governance requirements into executable rules.

Examples include type validation, date format unification, null handling, text format unification, deduplication, completion, and format conversion. Rule management makes data cleansing and quality detection no longer dependent on manual effort, but configurable, executable, and traceable.

Understanding these concepts makes it easier to find breakthrough points in the five high-frequency questions below.

II. Five MDM Implementation Questions: From Standard Consensus to Integration and Distribution

Q1: How Should Master Data Standards Be Defined So Business Departments Truly "Accept" Them?

How should master data standards be defined so business departments truly "accept" them? This is the first hurdle in MDM implementation. If IT defines standards behind closed doors, business may find them impractical and refuse to execute, turning standards into "castles in the air." Defining standards is like defining "Mandarin"—IT can't speak a dialect while business speaks a foreign language. Standards are not IT-exclusive; they are business consensus.

This corresponds to model management and master data management: model management unifies structures and relationships and supports review consensus; master data management clarifies who maintains, how to review, how to publish, and how to continuously iterate.

Without business owner participation, standards are hard to implement. It is recommended to start with core pain points such as customers and materials, involve business data owners, establish rules first and iterate, and gradually improve through review and use.

qData provides visual model management, supporting model definition, version comparison, and relationship graphs, allowing business to intuitively see master data structures and relationships. Standard formulation connects with platform approval capabilities, supporting multi-person, parallel approval to-dos and approval trail display, helping standards form consensus during business review.

Q2: When Legacy Data Cleansing Is Too Large, How to Avoid "Never Finishing"?

Legacy systems have run for years, with many duplicate, missing, and format-error data. Manual cleansing takes long, and projects easily fall behind. The approach is "urgent first, batch processing": historical garbage data should be archived if necessary, and core data should be cleansed first.

The essence is rule management and data quality—first clarify rules for deduplication, completion, and format conversion, then use tools to automate execution and continuously detect and rectify.

Implementation suggestions: establish cleansing rules, automate with tools, and layer historical data: core first, non-core archived, avoiding being overwhelmed by "full cleansing."

qData provides data governance capabilities with configurable rules. During ingestion, it automatically performs lightweight unification of types, date formats, null values, and text formats, and supports continuous detection and tracking of formal master data quality issues.

Q3: How Can the Master Data Platform Smoothly Connect with Existing Business Systems?

Enterprises have many systems, and ERP, CRM, SRM interfaces vary widely. Long development schedules and high integration costs are common realities. Integration is not about tearing down and rebuilding, but smooth integration like "building blocks," letting the master data platform act as the "central dispatcher" that distributes standard data to business systems. The core lies in data ingestion and multi-source fusion:

If the platform cannot easily ingest existing system data, nor fuse data from different sources according to a unified model, then subsequent standards, cleansing, and distribution have no foundation.

During implementation, multiple integration methods such as standard APIs, message queues, or direct database connections can be provided, chosen as needed. There is no need to pursue one-time full integration; instead, phased ingestion should be based on master data domains and business priorities.

qData supports three types of data source ingestion: databases, CSV/XLS/XLSX files, and HTTP APIs. Visual field mapping completes master data modeling without coding.

Q4: How Can Data Distribution Balance Real-Time Performance and Accuracy?

If master data changes but downstream systems are not updated, business errors easily occur—for example, a customer address changes but shipping still uses the old address, causing complaints. The distribution mechanism needs layering:

Core critical data is pushed in real time; non-core data is synchronized periodically. At the same time, there should be "receipt feedback" to ensure data is sent out and truly received and used downstream.

During implementation, it is recommended to establish a data distribution subscription mechanism combined with monitoring and alerting to detect and troubleshoot anomalies in time.

qData supports scheduled scheduling for data ingestion. Each execution generates an independent run record, and failure details can be traced to individual master data records and support re-execution.

Q5: Should MDM Projects Be Led by IT or Business?

If IT leads, business may not cooperate; if business leads, IT may not be able to implement it. With mutual buck-passing, projects easily fail. MDM is not a pure IT project, but a "top-leader project" plus a "business-led, IT-enabled" dual-track model.

During implementation, it is recommended to establish a joint project team: business departments are responsible for defining rules and acceptance, and IT departments are responsible for platform construction and technical implementation.

qData supports authorization for users, roles, and organizations in permission management, with fine-grained control by data scope, fields, and operation types. It also supports authorization validity periods and automatic expiration, satisfying IT's requirements for data security and traceability while allowing business personnel to conveniently participate in data maintenance and approval according to permissions.

III. Conclusion: Make Master Data Management a Consensus Project and Truly Make Data Assets Usable

Master data management implementation is not only a technical issue but also a management and consensus issue. Whether standards can be unified, data can be cleansed, systems can be connected, distribution can be reliable, and organizations can collaborate—avoiding these 5 pitfalls is what truly turns data asset inventory into business value.

qData is committed to providing enterprises with a one-stop master data management solution covering standard formulation, data cleansing, system integration, distribution, and traceability, truly bringing data assets to life.

The "Last Mile" of AI: 5 Critical Engineering Questions for Model Deployment

TongWu — Fri, 23 Oct 2026 06:53:01 +0000

As algorithm models move from the lab to production environments, engineering implementation capability is increasingly becoming the key bottleneck constraining value realization. As algorithm frameworks and model capabilities mature, simply pursuing metric improvements is no longer enough to determine project success. What truly affects delivery efficiency and stability is often a series of engineering issues—environment configuration, API integration, log troubleshooting, version management, dependency alignment, and asset governance.

Inconsistent development and production environments, disconnects between technical delivery and business requirements, and fragmented team collaboration all lead to longer model launch cycles, higher problem-diagnosis costs, and increased iteration risk. Without unified platform support and standardized asset management mechanisms, the full chain from R&D to deployment is difficult to close.

To bridge this gap, we first need to clarify the five most critical questions in engineering implementation.

Q1: Why does code run locally but fail once deployed?

"It works on my machine" is probably the phrase algorithm engineers encounter most often during deployment.

The direct cause isn't complicated: inconsistent Python versions, missing third-party libraries, and incompatible system components can all cause a model to run fine locally but fail in production. Inconsistent runtime environments are one of the most important causes of model deployment failure.

The solution is to bring environments into a manageable, reproducible delivery scope—"Environment as Code." Through containerization, code, dependencies, and runtime environments can be packaged into a unified image, reducing the uncertainty of manual environment configuration. qModel Professional provides one-click runtime image building, automatically parsing source code and dependencies to reduce deployment risks caused by environment differences.

But before building, you still need to clarify delivery boundaries:

What is the entry file and startup method?
Are dependencies complete?
Where does the model file read from?
What environment variables does the service need?
How are request and response data structures defined?

qModel's build process typically includes basic configuration, file upload and validation, parameter definition, and build confirmation. The final step offers a choice between native script execution or independent image building. The former suits scenarios with simple dependencies where the platform runtime environment is sufficient; the latter is better for models with more dependencies that require isolated runtime environments.

After building, you should review build logs and validate service startup and inference chains using samples close to the production environment, avoiding pushing unverified artifacts directly to the business side.

Q2: When the business says the model is inaccurate, is it a data problem or an algorithm problem?

When the business reports "wrong results," algorithm teams tend to attribute it to data quality, while business teams may think model capability is insufficient. The core reason both sides struggle to reach consensus quickly is that the model runtime process isn't transparent enough—there's a lack of traceable input/output records and structured test validation mechanisms.

The solution is to use data to define problem boundaries. qModel Professional provides online visual debugging, allowing intuitive validation of model performance without writing additional test scripts. Combined with full call log retention, every API call becomes traceable, making it easier to locate whether the problem occurs in data, algorithm, or API adaptation.

An effective debugging session shouldn't just focus on whether the API returns 200. You should prepare samples covering normal values, boundary values, missing values, and abnormal formats, and verify input fields, field types, required constraints, and output structures and business meanings one by one. Troubleshooting can follow this order: whether the request conforms to the contract, whether preprocessing meets expectations, whether model output is reasonable, and whether post-processing and business interpretation are correct—avoiding conflating data quality, algorithm logic, and API adaptation issues.

Version, call type, execution time, status, and call time in call records help map business feedback to specific requests. When sensitive data is involved, follow organizational data compliance requirements and control log fields and access permissions.

Q3: How can model iterations avoid impacting existing business?

Model iterations often carry release risk. Without standardized version management and smooth upgrade mechanisms, a problematic new version can impact existing business and be difficult to roll back quickly. If every release relies on manually replacing files or temporarily adjusting configurations, the delivery process becomes uncontrollable.

The solution is to establish a verifiable, switchable, and rollback-capable version management mechanism. qModel Professional provides version management capabilities, supporting version information viewing, version comparison, and version switching. The business side can use the target version according to release agreements; when a new version has problems, it can switch back to a verified version, reducing release risk.

Note that specific switchover time, whether in-flight requests are affected, and how the business side specifies versions should be verified against actual deployment and integration methods. A rollback-capable version shouldn't just retain an old file—it should correspond to明确的 code, dependencies, model files, parameter definitions, and build artifacts, and include version descriptions, change summaries, creators, and timestamps.

Before release, validate the new version with representative samples and confirm which version business calls actually use. After release, continuously monitor call success rate, latency, and output quality. If the new version has problems, restore to a verified version using the platform's version switching capability and verify that callers have correctly taken effect. Multi-version coexistence helps reduce upgrade coupling, but grayscale ratios, automatic rollback, and zero-downtime switching should be based on actual deployment configuration—you can't assume these capabilities exist just because "version management" is available.

Q4: How can multi-team collaboration break down data and code barriers?

Without a unified platform, model collaboration often remains primitive: code passed via zip files, dependencies explained verbally, deployment relying on personal experience. This model is error-prone and difficult to accumulate and reuse. If enterprises lack a unified model asset carrier and collaboration platform, model knowledge is hard to form stable accumulation.

The solution is to replace manual experience with standardized pipelines. By centrally managing model files, dependency configurations, and runtime environments, platform-based management reduces information gaps in cross-team collaboration, shifting model delivery from "individual capability" to "organizational process."

When implementing collaboration, clarify each team's responsibilities and deliverables:

Algorithm teams are responsible for model logic, dependency lists, input/output contracts, and validation samples.
Platform or operations teams are responsible for runtime resources, network and permissions, release strategies, and operational assurance.
Business teams are responsible for providing real scenarios, determining whether results meet business rules, and confirming degradation or manual handling approaches for exceptions.

Model assets should have stable names and codes, owners, purpose descriptions, current status, version records, and invocation methods. This way, what gets handed over is no longer a temporary zip file but an identifiable, verifiable, and traceable service capability.

Q5: How does qModel Professional connect these scattered steps?

Facing the above problems, enterprises need more than isolated deployment actions—they need a collaborative workbench that supports models from build, validation, and release to call tracking, while gradually accumulating assets. qModel Professional provides platform capabilities around this chain, summarizing the model implementation process as:

Model asset registration → File and parameter configuration → Runtime environment build → Online validation → Version management → API calls and records

Standardized build: Complete basic information, file validation, parameter definition, and runtime method selection through step-by-step configuration; independent image building can be used for scenarios requiring custom dependency environments.
Online validation: Select a version on the model details page, fill in request parameters, and initiate a test; verify response content against result definitions, shortening the feedback path from build completion to business acceptance.
Traceable calls: View model, version, call type, status, duration, and time through call records, providing a basis for reproducing problems and analyzing service performance.
Manageable versions: Record model versions and change information, and select target versions according to actual release processes; pre- and post-release validation and rollback should still be incorporated into team release standards.
Reusable assets: Centrally search and manage models in the model center, combining classification, codes, tags, status, and integration methods so teams can identify existing capabilities and reuse them according to permissions.

It should be noted that platform capabilities solve standardization and traceability of the chain—they cannot replace business judgment, algorithm innovation, or team collaboration mechanisms. The ultimate goal of model engineering isn't simply completing deployment, but making the model delivery process more stable, transparent, and reusable.

Conclusion: The Last Mile Is About Engineering Consensus

The "last mile" of enterprise AI implementation is never a single-point technical problem—it's a systematic engineering effort spanning environment building, validation mechanisms, version governance, collaboration division, and asset accumulation. For partners, the earlier delivery boundaries, validation standards, version strategies, and responsibility ownership are clarified, the more communication costs and rework risks can be reduced later.

qModel Professional isn't intended to replace algorithm innovation, nor does it promise to solve all problems with one click. Rather, it aims to serve as a collaborative workbench that gradually standardizes, traces, and makes reusable the chain from model build, validation, and release to call tracking. The ultimate goal is to make models no longer just a zip file or a one-time demo, but an identifiable, verifiable, traceable, and reusable service capability for the enterprise.