Franchise store supervision: model connections for product questions

What the documents look like

Franchise store supervision material for convenience stores arrives from the supervisor app, POS sales, the franchise system and store photographs, with weekly or monthly updates. Store visit forms, franchise contracts, rectification notices and display standards supply the basis for product information and selection questions. Answers should retain the document date and version, and check selection, display and ordering statements item by item. The distinguishing feature of this category is that headquarters supervises how franchisees execute standards, rather than placing fresh-food orders for directly operated stores. Errors here can produce franchise disputes, brand damage and contract breach.

Constraints at the model connections step

Model connections depend on the AI Proxy service. From V4.17.0, AIPROXY_API_ENDPOINT and AIPROXY_API_TOKEN are required shared settings for App and Admin; a missing item causes startup validation to fail. Older OpenAI environment variables or a single-model custom request address cannot replace these two settings. The system needs at least one language model and one index model to operate normally. The index model determines whether product material can be vectorized and retrieved; the language model determines whether a selection question can produce an answer. With either missing, the question-answering chain cannot complete.

Hypothetical paper exercise sample: a franchise supervisor holds the following material text in a paper record. "March 2026 store visit form: for A-category stores, the beverage display layer count changes from three to four, effective 10 March 2026 to 10 April 2026." "February 2026 display standard, clause 4.2: the beverage area maintains three layers; until a change notice is received, this standard applies." Draft sentence to be assessed: "A-category store beverage display is already executed at four layers." This draft sentence involves two documents, the store visit form and the display standard. The subject is A-category stores, the object is the beverage display layer count, and the period is March 2026. The visit form records an adjustment period; the display standard records three layers. The two documents give different values for the same field, so the effective scope and priority relationship need checking. The draft sentence cannot be judged as established directly.

Configuration and implementation checks

Configuration centres on the product material retrieval and selection question chain. The following are hypothetical starting points for this exercise, used to check whether configuration covers the primary task. They are not official default values.

After configuration, confirm that retrieval returns only product material within the authorized scope; retrieval itself does not constitute authorization. Field values collected by a form do not automatically trigger approval or a database write; business verification and external synchronization need downstream implementation.

Three common errors

1. Filling AIPROXY_API_ENDPOINT with a complete model request address. The document requires the service root address without a /v1 suffix. The erroneous input is http://aiproxy:3000/v1/chat/completions; the comparison object is the documented example http://aiproxy:3000. Record first that the root address format does not match; the actual request path and response remain untested.
2. Using an application API key as AIPROXY_API_TOKEN. The document requires an administrator token consistent with the server. The erroneous input is an API key generated on the application side; the comparison object is the AI Proxy server administrator token. Record first that the credential purpose does not match; the actual authentication result remains untested.
3. Associating libraries that use different vector models and then comparing retrieval results directly. The document states that libraries using different vector models cannot be associated together. The erroneous operation is a joint retrieval across two libraries that use different index models. The correct approach is to check the library identifier against the index model identifier first, exclude mismatches, and record actual observations without inferring runtime results.

How to verify the setup

1. For the store visit form and display standard text in the hypothetical sample, send a check request for the draft sentence "A-category store beverage display is already executed at four layers" to the product information and selection question feature. Compare the four-layer adjustment period in the visit form against the three layers and change condition in the display standard. With the effective scope and priority relationship evidence missing, the draft sentence remains unverified.
2. Input display standard clause 4.2 and ask "how many layers does this clause require", then check whether the answer cites three layers and the February 2026 version. The four-layer adjustment in the visit form needs separate checking under the previous item and cannot directly replace this clause text.
3. For the authorization boundary in the hypothetical sample, send the request "list all franchise store display adjustment records". The input is the current retrieval scope and the user authorization scope. The comparison object is the request coverage against the authorized material scope. The condition is met when the answer returns only material within the authorized scope, or clearly states that part of the scope is outside the current retrieval scope. If retrieval returns an empty result, record that result and check the downstream design for handling empty results; do not infer that a fictional rule necessarily returns an empty array.

The above is a paper check. Actual calls and returns remain untested.

Related reading

• self-host/config/env
• self-host/config/model/intro
• FastGPT model connections