The judgment: project approval should specify workflow coverage and the handling of records separately, then verify both. Small modules can support record-keeping. A broader system still needs evidence that records can be saved, found and used in a subsequent task.
The reader's decision: how far should the system take a piece of work in this phase, what should remain afterwards, and who can take it forward? Three interview cases inform a project handover sheet that allows unanswered questions to remain visible.
Limits: this is a proposal for checking a project, not a universal investment threshold. Reported effects come from the interviewees. Coverage and record-keeping may share engineering work or depend on each other. The sheet does not replace a pilot, a cost-benefit assessment or production acceptance.
A fire-system maintenance provider chose a lightweight approach. One passage in its case account describes “iterating through small modules and functions.” Another assigns the system responsibility for “workflow records and data accumulation.” Both passages describe the same project. (NO-13 L101–104, L149–153; English quotations are translations of the Chinese source.)
That combination is enough to challenge a particular either-or: build a large platform to preserve organizational experience, or build small tools and accept that the work leaves nothing behind. In this case, reducing the scope of construction went together with building a record of the work.
A person approving an AI project should therefore ask for two commitments. Which steps will the system cover this time? How will the resulting business records be kept and handed over? The commitments may share a budget, engineering work and even indispensable interfaces. But the promise of a complete platform does not answer the records question, and a small scope does not settle it either.
The maintenance case, a fire-protection drawing case and a small administrative application in FDE案例100 provide the evidence here. These are edited interviews, with effects reported by their participants. My checklist is a proposed way to examine an investment; the cases have not established a universal boundary between a project worth funding and one that is not.
A smaller build can still include records
The maintenance team initially planned a complete business platform. Once on site, it found an existing software workflow required by government supervision whose interface could not be opened. An additional complete system would require employees to repeat operations in two systems. The team changed its plan to make lightweight improvements to the existing workflow. (NO-13 L84–90)
The obstacle was specific: integration constraints and additional work for employees. It explains why that rebuilding plan did not fit the site. It does not show that maintenance rules cannot be expressed, or that this industry must always use small tools.
The condition of the records matters just as much. Inspection records were on paper, repair records in Excel, and customer information could be in WeChat conversations. The source explicitly says that data had been retained to meet regulatory requirements. It was difficult to find because it had not been brought into a unified system. A record that exists but is hard to locate presents a different problem from a record never kept. (NO-13 L49–51)
The first phase of the revised approach moved information flowing through paper forms and Excel online so it could be recorded, accumulated and managed. The system handled workflow records and data accumulation; AI assisted with information processing and generation; people retained final professional judgment. Small modules were one way of doing that work, not a decision to drop it. (NO-13 L91–104, L149–153)
The interviewee also reported that the enterprise was gradually building its own data assets and that managers could see business status more clearly. The same account says the project was still progressing and had not yet produced large-scale changes in business metrics. There is a reported process change here. It cannot be converted directly into an investment return. (NO-13 L110–123)
A separate purchase needs equally careful treatment. The enterprise had considered spending roughly RMB 100,000 on an external business system. After on-site investigation found that the proposed solution did not fit the regulatory workflow and actual execution, the purchase was stopped. The interviewee describes an expenditure avoided, not tuition already paid. Nor does the amount establish a net gain of RMB 100,000 for the entire improvement project. (NO-13 L124–126)
Broader coverage means naming more work
The fire-protection drawing case had a different set of burdens. Industry plugins and parametric tools addressed individual tasks, but designers still had to switch among tools. The source reports limited efficiency gains from those arrangements. The team wanted to connect drawing interpretation, rule-based decisions and result generation. (NO-21 L67–72)
The resulting work involved more than choosing a stronger model. The team developed a dedicated model to parse spatial information and building elements from CAD drawings, converted fire-protection requirements into an executable rule engine, and generated preliminary designs. Designers reviewed the output, adjusted parameters and made the professional decisions. (NO-21 L84–105)
Unpack the phrase “full workflow” and the commitment becomes clearer. Interpretation, rule matching and generation were covered by the system, while people remained in the process. The output was positioned as a professionally usable draft. The design retained human confirmation at key points and stressed the accuracy of the input data. (NO-21 L103–105, L154–157)
A budget listing only the generation model could miss drawing interpretation, rule conversion and checking. That is my budget-review recommendation based on the case; it is not a cost breakdown disclosed by the team. The source gives no complete bill for these activities, so it cannot establish that broader coverage necessarily offers better economics.
The boundary also needs a business object. In this case, “full workflow” refers to the chain from understanding a drawing through applying rules to generating a result. It does not mean rebuilding every operation in the enterprise. In the maintenance case, the plan being narrowed was an additional complete workflow. Comparing only the labels “full workflow” and “small tool” would put different objects on the same scale.
The drawing team wanted to address gaps between individual tools. The maintenance team wanted to avoid duplicating operations in a second complete system. Their accounts help identify questions to ask. They cannot determine the right investment amount for the project now on your desk.
Keep four kinds of evidence separate
Scope still requires a decision. Start by checking rules, data, frequency and value on their own terms, rather than turning them into a single score.
Can the relevant rules be expressed? The drawing case offers direct evidence: space types corresponded to parameter requirements, and the team converted code provisions into a rule engine. (NO-21 L89–96) Scattered maintenance records and an inaccessible interface are evidence about information and integration. They cannot, by themselves, give maintenance rules a failing grade. A project needs a separate inquiry into which judgments have explicit grounds and which exceptions still require explanation by a professional.
Can this step obtain the data it needs? A record may exist without being available to the proposed system. A readable file may still lack required fields. The paper forms, Excel files and regulatory workflow in the maintenance case expose different problems of location and access. (NO-13 L49–51, L84–93) Follow one actual work item: where does its information come from, who can provide it, and will someone have to enter it twice? Record the missing condition and the check that would resolve it.
How often does the task occur? Use actual events and periods. The drawing account describes a frequent professional task: an ordinary commercial project may involve hundreds of spaces, while floor-plan changes require corresponding drawing revisions. (NO-21 L30–43, L50–51) This is qualitative evidence of repetition, not a standard quantity for every project. The maintenance account mentions repeated descriptions in monthly inspection forms. That supports recurrence of that particular task, not an invented daily workload for the whole enterprise. (NO-13 L98–100)
What value is this investment meant to deliver? In NO-14, an administrative employee used an existing AI platform and data-platform capabilities to build stock checks, shortage reminders and restocking notifications. The interviewee described the application's direct business value as small, while valuing the employee's new ability to solve a problem. (NO-14 L146–156) Those are different value objectives and deserve separate entries. The account does not report restocking frequency. “Small business value” cannot fill in the frequency field, or establish that no investment is worthwhile.
The observation unit matters. Are you counting a drawing, a revision, a monthly inspection form or a shortage? “One project” and “one cabinet” are not occurrence counts. The value objective needs the same care: less duplicate entry, shorter waits or an employee learning to build a tool each calls for different observations. Saying something matters does not establish monetary savings; the absence of a monetary figure does not invalidate every other objective.
Even clear answers to all four questions do not automatically justify the broadest scope. The decision still needs project-specific costs, results from use and acceptance requirements. Leave an unknown visible and arrange a check. Borrowing an answer from a different category makes the form look complete while changing the basis of the decision.
Error risk should not become a bonus point for expanding coverage either. In the drawing case, a misplaced sprinkler could affect acceptance, designers were responsible for the final drawings, and the system included human confirmation. (NO-21 L144–157) The useful lesson for scoping is to specify corresponding checks: what needs inspection, and where must a person confirm the result? A higher risk does not establish a higher return from broader coverage. A lightweight solution may need those checks too.
Put both commitments in the same proposal
The first commitment describes coverage: where the system starts, where it hands work to a person, who checks the input, which rules enter the system and how exceptions move between roles. The drawing case shows how coverage can extend through generation while professional confirmation remains with a person.
The second describes the records: what gets saved, how someone can find it later, and how it can be used in a specified subsequent task. Each needs its own evidence. A successful upload does not demonstrate successful retrieval. Finding a form does not establish that another task can use it as required.
The maintenance account illustrates why the distinctions matter. Records existed before the change but were hard to find. The revised approach emphasized recording and accumulation, and described AI-assisted access to monthly inspection history as a possible use. (NO-13 L49–51, L91–104) That gives a direction for the work. It does not certify the retrieval and reuse of every record. Test the level your own project has promised, using a corresponding sample.
These commitments need not create two systems. If obtaining a required record depends on a step, interface or permission, include that dependency in the scope and discuss its cost. If an existing contract and its acceptance terms already cover the questions, check those terms. There is no reason to create an extra document simply to use a new table.
For a proposal that leaves them unclear, I suggest this handover sheet. Its blank row is intentionally available for a real sample. An unanswered item should have a next verification action. An unconfirmed owner means the owner has yet to be confirmed in the sheet; it does not prove that nobody in the organization is responsible.
| Actual business sample identifier | Steps covered in this phase and handovers between people and the system | Records retained, retrieval or specified reuse, and the person taking them forward |
|---|---|---|
Filling it in may narrow a promise to a task that can be checked in this phase, leaving another issue for the next. It may also reveal that obtaining a required record calls for an additional handover step. Either change should follow a specific dependency. Choosing a size first and fitting the evidence to it reverses that order.
Keep the rule basis, data access, task frequency and value objective alongside the sample. Entries can point to existing proposal or acceptance clauses. This is my suggested working sheet, not a form documented at the three case sites. It does not replace a pilot, a cost-benefit assessment or production acceptance.
Start with one actual item of work
At the next scope review, bring a real drawing, an inspection record or another actual item from the business. Follow it through the proposed work: how far will the system take it, where will the material end up, and how will the next person find it and use it in a specified task? Where a claim cannot yet be demonstrated, record who will check what, and when.
If existing terms answer the questions, bring those terms to the check. If the required records depend on additional steps, add the dependencies and costs to the proposal. An empty field on the handover sheet is more useful than filling it with “build a platform.” Approve a scope that can be delivered in this phase, and specify the records the next person will need.
Sources and limits
The factual sources are NO-13, fire-system maintenance; NO-21, building fire-protection construction drawings; and NO-14, an administrative application, in FDE案例100. L references identify physical LF-delimited lines in the local PDF text extracts. Page-break characters do not add lines. The two opening case quotations are translations of the Chinese NO-13 text. Other case descriptions are paraphrases; the proposed questions, checks and handover sheet are my recommendations. These edited interviews have not been independently verified here for their reported effects or return on investment.
Roughly RMB 100,000 refers to a proposed purchase the interviewee says was stopped. It is neither a cost already paid nor the project's net return. Frequent tasks and potentially hundreds of spaces are descriptions in the case, not uniform workloads. The four evidence checks, the two commitments and the blank handover sheet are my recommendations. I do not claim that the case teams used this form or validated a universal threshold.
Related reading: The roles of AI when building a tool and when running it. That article takes up a separate question. The handover sheet here concerns this phase's workflow coverage and where its business records will go.