What the documents look like
Retail plastic bag and single-use item reporting centres on compliance submissions about single-use plastic use and recovery. The data sources named in the brief are the Ministry of Commerce reporting system, POS plastic bag sales records, procurement systems and store ledgers. The documents handled day to day are plastic bag procurement ledgers, sales vouchers, half-year reports and self-discipline commitments. This page deals only with the interactive forms step of product and marketing copy drafting: collecting the information a draft needs through interaction nodes, and routing to different branches according to the user's choice. It does not cover the reporting submission itself.
Two features of this category shape the drafting task. First, the material that supports a promotional sentence is a ledger, a voucher or a commitment text, and each of these records specific subjects, objects and states. Whether a drafted sentence is supported depends on whether the material states the same field. Second, the drafting information arrives through an operator filling a form or making a choice, so the quality of the draft depends on which fields are required and how missing fields are handled downstream.
Constraints at the interactive forms step
The form input node is a user-interaction node. When it triggers, the conversation enters an interaction state, the workflow state is recorded, and execution waits for the user to complete the interaction. After the user fills the required information and submits, the node collects the submitted form information and passes it to later nodes. The node does not include a business database function of its own.
The user selection node is also a user-interaction node. When it triggers, the conversation enters an interaction state and the workflow state is recorded. When the user makes a choice, the node judges that choice and executes the "yes" branch, which is how different workflow paths are designed around user feedback.
Field validation, business approval, write-back and batch operations are implemented as needed in external systems or in later nodes. The interaction nodes collect values; they do not perform business verification or approval.
Hypothetical worked sample. The material text for checking is a store ledger entry reading "this batch purchased 5,000 plastic bags, used for weighing and packaging in the fresh produce area", a sales voucher reading "3,200 of the same batch have been sold", and a self-discipline commitment text reading "this store undertakes not to provide ultra-thin plastic bags to consumers free of charge". A draft sentence to be judged is "all plastic bags in this store are degradable material". The draft sentence concerns a material property. The material text records quantity, purpose and a commitment item, and does not state material. The draft sentence is therefore unsupported and needs material testing or procurement specification material before it can be judged. This sample is a paper exercise; nothing was run.
Configuration and implementation checks
The table lists only settings documented in the official material or implementation checks relevant to this page's main task.
| Configuration item | Type | Check point for this page |
|---|---|---|
| Form input node | Documented node | Collects the fields the draft needs; passes them to later nodes after submission |
| User selection node | Documented node | Executes the "yes" branch on the user's choice; used to design different paths |
| Required field list | Implementation check | List the information this task cannot omit; test the missing case and the completed case separately |
| Interaction state | Documented behaviour | Trigger records state and waits; execution continues after interaction completes |
| Downstream division of work | Implementation check | Validation, approval and write-back are implemented in external systems or later nodes |
| Starting value for this exercise | Hypothetical value | Set required fields to 3, chosen to cover subject, object and state; compared against the missing-field case |
Three common errors
- Treating the user selection node as a personnel directory or business data selector, entering a store name and expecting all of that store's ledgers in return. Check: input the store name from the sample, compare the node output against a branch decision, and record a mismatch if the output is a personnel or data list.
- Treating retrieval relevance as a permission or entity isolation mechanism, assuming a similarity setting excludes unrelated business or unauthorized records. Check: input a query spanning subjects, compare the subject identifier on returned records, and note that isolation is not implemented by retrieval if a non-authorized subject appears.
- Judging a field the material does not state as a contradiction or a denial. Check: input the draft sentence "all plastic bags in this store are degradable material", compare whether the material text contains a material field, and record the result as unsupported when the field is absent, not as a conflict.
How to verify the setup
- Verification one. Input the sample material text and the draft sentence. Compare whether the subject, object and state of the draft sentence match the same fields in the material text. When the material text has no material field, the expected output is unsupported. That result satisfies the condition.
- Verification two. Use a paper input of an empty result to check the downstream design. Compare whether, after form submission, the later nodes handle the missing-field branch. The condition is satisfied when later nodes do not trigger business approval or a database write, which matches the documented division of work.
- Verification three. Input the two branch options of the user selection node. Compare whether each choice enters its corresponding branch. The condition is satisfied when, after the choice, the conversation continues downward from the interaction state. All three are paper expectations and were not actually run.