Group-buy presale orders: model connections for copy drafting

Review model connections for copy drafting in Group-buy presale orders. Check document scope, failure paths and source evidence through controlled tests.

What the documents look like

Presale group-buying collects orders first and organizes purchasing and fulfillment afterward. Copy drafting for this category works from four document types: the presale product table, the group-formation result, the purchasing plan, and the cut-off notice. These materials update daily or per session, so any stock figure, formed-group quantity, or cut-off time cited in drafted copy comes from the current day or the current session.

Model connection and configuration determine whether the drafting step can produce checkable copy sentences from the source wording, and whether those sentences can be traced back to specific fields. The presale product table carries the product name, presale status, and cut-off time. The group-formation result carries the formed quantity for each product. The purchasing plan records whether a product has been included in the current session's procurement. A drafted sentence that asserts a formed group, continued ordering, or remaining availability has to be compared against these three fields for the same product and the same session.

Constraints at the model connections step

The system requires at least one language model and one index model to operate normally. AI Proxy is a required dependency. The App service and any Admin service that reuses App/Service configuration must set AIPROXY_API_ENDPOINT and a non-empty AIPROXY_API_TOKEN; missing either one causes startup validation to fail. The model ID is the value of the model field in the interface request body and is globally unique. The model name is used for display. A model channel is configured by protocol type, and the proxy address field takes a BaseUrl.

Model status probing applies only to system models that are currently enabled. Disabled models do not participate in probing and produce no history records. After a first probe failure, the system retries automatically at most three more times, so a single round makes at most four attempts. Only when all four attempts fail is the model judged abnormal.

Hypothetical paper exercise sample. The source material reads: "Presale product table row 12: product name 'Spring bamboo shoots 500g', presale status 'cut-off closed', cut-off time 18 March 20:00; group-formation result row 3: formed quantity for this product is 0; purchasing plan row 5: this product is not listed in the current session's procurement." The drafted sentence to be judged is: "Spring bamboo shoots 500g has formed a group this session and can continue to be ordered." The comparison object is the same product, the same session, and the same fields. The comparison checks the values of presale status, formed quantity, and purchasing plan in the source material against the claims in the drafted sentence.

Configuration and implementation checks

Configuration itemHypothetical starting value for this exerciseReason and comparison method
AIPROXY_API_ENDPOINTThe AI Proxy service root address, with no /v1 appendedMatches the documented requirement; compare whether a path suffix was appended
AIPROXY_API_TOKENA non-empty administrator token consistent with the server configurationThe document requires a non-empty value; compare whether an application API key was used instead
Model IDIdentical to the model in the model channelThe document states the model ID is globally unique; compare the model field in the request body
Model typeAt least one language model and one index model eachThe document requires at least one of each; compare the enabled model list
Model status probingApplies only to enabled system modelsThe document states disabled models do not participate; compare the probe scope
Retry countAt most three retries after a first failureThe document states at most four attempts per round; compare the probe records

Three common errors

  1. Entering a full model request address in AIPROXY_API_ENDPOINT with /v1 appended. The input is the environment variable value; the comparison object is the documented requirement not to append /v1; the observable result is whether startup validation passes.
  2. Using an application API key in place of AIPROXY_API_TOKEN. The input is the environment variable value; the comparison object is the documented requirement that the token be consistent with the server configuration and non-empty; the observable result is whether startup validation passes.
  3. Including a disabled model in the probe scope. The input is the enabled model list; the comparison object is the documented statement that probing covers only enabled system models; the observable result is whether a disabled model appears in the probe records.

How to verify the setup

  • Verification one. Input the presale status field for "Spring bamboo shoots 500g" from the hypothetical sample. Compare the drafted sentence "has formed a group this session" against the source value "cut-off closed". Observe whether the drafted sentence matches the source value. The expected result is a mismatch, so the drafted sentence needs revision or the evidence gap needs recording.
  • Verification two. Input the formed quantity field for "Spring bamboo shoots 500g" from the hypothetical sample. Compare the drafted sentence "has formed a group" against the source value "formed quantity is 0". Observe whether the drafted sentence is supported by the source. The expected result is unsupported, so additional material is needed or the wording needs adjustment.
  • Verification three. Input the purchasing plan field for "Spring bamboo shoots 500g" from the hypothetical sample. Compare the drafted sentence "can continue to be ordered" against the source value "not listed in the current session's procurement". Observe whether the drafted sentence is consistent with the purchasing plan. The expected result is a mismatch, so the gap needs recording and the source wording needs to be retained.

These verifications apply only to the hypothetical sample on this page and do not claim that any test was actually executed. The model status probe's alert webhook, event types, and request body fields are checked against the documented description; when no webhook is configured, no push is produced. Retrieval and relevance scores do not carry authorization or entity-isolation duties.