What the documents look like
An MCN agency manages long-term account compliance for several creators, so the working set covers creator contracts, training records, violation handling forms and account schedules. These come from the MCN back office, platform violation notices, creator account data and the contract ledger. For order fulfilment and after-sales questions, three of these decide what a reply may cite and what remains unverified: the signed contract, the violation handling form and the account schedule. The contract ledger records signing and effective information, the violation handling form records the violation and its handling status, and the account schedule records time-slot arrangements. Update frequency is daily or weekly; this page does not depend on batch synchronisation or transaction-triggered mechanisms.
A creator contract has a signing date, a cooperation term and a signing status. A violation handling form has a violation event, a date and a handling status. An account schedule has time slots. A signing status and an effective status are separate facts, and a handling status of pending review is not a completed handling.
Constraints at the multi-turn prompts step
Multi-turn dialogue must separate a new session from a continued session. When chatId is passed, the system takes the session from the database and uses the last item of the messages array as the user question, ignoring the remaining messages. When chatId is not passed, the context is built entirely from the supplied messages. The prompt must state the material scope, the answering task and how to behave when evidence is missing, so the model does not write in business facts of its own.
Context carried in from history needs to be checked against its actual content. The reply format follows what the downstream step consumes; when json_schema is selected, the corresponding format requirement must be filled in and the returned structure verified. Retrieval and similarity do not perform permission or entity isolation, and a same-vector-model requirement inside one knowledge base does not extend to external systems.
Hypothetical paper test case: an MCN operations staff member holds creator A's signed contract, which records a signing date of 1 March 2025, a cooperation term of 12 months and a status of signed. On the same day a violation handling form records that creator A committed a violation during a live stream on 1 March 2025, with a handling status of pending review. The staff member intends to submit this request to the after-sales question system: "Creator A's contract is in effect, please arrange the March schedule under the contract." The material text to be checked is: the contract signing status is signed, and no effective status is stated; the violation handling form status is pending review. The draft sentence treats "signed" as the same fact as "in effect" and treats the pending-review violation handling form as not affecting scheduling.
Configuration and implementation checks
The settings below relate to the multi-turn prompts task on this page. The values are hypothetical starting points for this paper exercise, not official defaults.
| Configuration item | Hypothetical starting point | Reason and comparison method |
|---|---|---|
| Memory rounds | 4 rounds as a hypothetical starting point | After-sales answers need recent dialogue; compare with the default value and observe whether too much history is carried in |
| Reply limit | 2000 as a hypothetical starting point | A fulfilment answer must state status completely; compare against observed truncation |
| Temperature | 0.3 as a hypothetical starting point | Rule-bound fulfilment scenarios need stable answers; compare divergence against a higher value |
| Reply format | Plain text | A fulfilment answer needs no fixed structure; compare with json_schema when a downstream consumer requires it |
| Multimodal recognition | Off | This sample has no image or audio input; compare against recognition results when it is on |
| Hide AI output | Off | The answer must be shown directly; compare with downstream consumption when it is on |
Three common errors
- Treating "signed" as "in effect". The contract signing status and the effective status are different fields. In the sample the effective status is not stated, so a draft sentence that schedules work on that basis is not supported.
- Treating a violation handling form marked "pending review" as not affecting scheduling. Pending review is not completed handling and is not authorisation to schedule. A draft sentence that ignores this status leaves an evidence gap.
- Treating retrieval similarity as a permission or entity filter. Similarity reflects textual relatedness only. It does not exclude unrelated creators or unauthorised records, and a retrieval result cannot replace an authorisation check.
How to verify the setup
- Input the contract text and the draft sentence from the sample, and compare the two fields "signed" and "in effect". The condition is met when the system answer states that the effective status is not recorded and that scheduling cannot be based on it. This is a paper check and has not been run.
- Input the violation handling form text and the scheduling request from the sample, and compare "pending review" with "handling completed". The condition is met when the system answer states that pending review does not constitute a basis for scheduling. This is a paper check and has not been run.
- Input the retrieval query from the sample and compare the returned results with the authorised scope. The condition is met when the system does not treat a similarity result directly as a basis for authorisation. This is a paper check and has not been run.
In all three checks, the material text required for the comparison must sit inside a retrieval scope the operator may access, or be supplied as an explicit manual input. When it is missing, record the gap. A pending request is not an approval, an offered option is not an execution, and an unsigned termination is not a completed termination.