On page 1 of the semi-annual evaluation report of Cathay New Point Software’s 2026 action plan, in the smart procurement business section, it is proposed to explore the FDE delivery model, convert business problems into executable AI tasks, and build an intelligent delivery knowledge base. The original article provides directional disclosures and does not list a verifiable knowledge base structure, client contracts, and task samples. This article retains the original abbreviation of FDE and only conducts methodological research based on its delivery context.
An experience needs to explain under what circumstances it is effective
Below are ChinaOPC’s independent recommendations for small team delivery. A record in the knowledge base should answer at least four questions: what problem was encountered originally, what conditions were available at the time, what treatment was adopted, and how to know that the treatment was effective. With only a final prompt word or a screenshot of success, people who take over later often cannot tell whether it can be used for their own customers.
For example, when a material classification task is precipitated into experience, you can attach the input data type, directory allowed to be read, classification rule version, and fuzzy categories that must be confirmed by humans. Examples should use desensitized or specially constructed data and indicate how it differs from real customer profiles. This saves it in a way that can be reviewed, rather than turning the client file into the default material for other projects.
Separate reusable parts from customer configuration
Different customers may use similar business terms but have different fields and confirmation processes. Teams can put common parsing steps in common components and the customer's own directories, accounts, approvers, and exception rules in independent configurations. The next time you use it, check the configuration conditions first and then decide which part to reuse; you cannot copy the entire set of connection methods of the previous company just because the industry name is the same.
Experience entries can also be attached with failure samples: how to prompt when data expires, how to stop when fields conflict with each other, how to return tasks to manual work when the interface is unavailable. The failure path can help the successor see the applicable boundaries and allow the team to judge whether it needs to continue investing in research and development. Its value should be observed through actual calls and review records, and cannot be measured solely by the number of knowledge base entries.
Before updating knowledge, also know which projects are using it
A rule change adopted by multiple customers may have an impact beyond the current support ticket. It is recommended to keep a list of versions, review dates, and associated projects for experience entries. Before updating, use a fixed sample to compare the differences, confirm which changes are expected improvements and which are new errors, and then arrange to go online according to the agreement of each project. The old version can be discontinued, but a record of why it was valid at that time should be left.
When an experience is no longer applicable, it can be marked for review or discontinued, and the reasons should be clearly stated, such as input system changes, customer rule adjustments, or external service deactivation. Don't just overwrite old answers and leave historical delivery without basis for interpretation. For teams with limited staff, it is often easier to maintain a small number of items that are actually reused than to sort through a large amount of unverified material at once.
New Point Software’s public materials allow us to see the direction of accumulation of delivery experience, but this article does not identify the actual benefits of one of its customers based on this, nor does it refer to large software companies as OPC. Small teams can start with an authorized real task, verify whether the experience can be reproduced by another collaborator, and then consider expanding the knowledge base.
Extended reading: Evidence chain of project delivery and What to do after the case data is updated, focusing on task basis and data time point respectively.