What the documents look like
Promotion enrollment and price management for platform marketplaces centers on price, inventory, and campaign cadence rather than promotional wording review. The working materials are the campaign enrollment form, the promotional price approval sheet, the inventory lock sheet, and the campaign retrospective. These sit alongside conversation logs during an operations handover, because enrollment, price changes, and inventory locking each sit under a different authorization step, and a handover has to keep them separate. The brief gives weekly and per-campaign update frequencies; this page does not infer any automatic synchronization or real-time trigger from those frequencies.
Conversation logs and audit occupy a specific position here. A log records a session and its run process. It does not record an approval conclusion, and it does not replace the enrollment form or the approval sheet. The data is located by three identifiers: appId identifies the application, chatId identifies one session under an application, and dataId identifies one conversation under a session. Where chatId is a non-empty string, the system takes the session from the FastGPT database and uses the last item of the messages array as the user question, ignoring the remaining messages; chatId must be kept unique and shorter than 250 characters. If responseChatItemId is passed, it must be unique under the current chatId. These identifiers are used to match a target conversation against a business record. Similarity and retrieval do not carry permission or entity isolation duties, and retrieval is not authorization. Reconciliation, retention, and compliance obligations belong to a complete business solution implemented elsewhere; the existence of a log does not mean a compliance audit is complete.
Constraints at the conversation logs step
The conversation interface is the documented route for reading run detail. When detail is set and stream is false, intermediate values and the complete result are held in responseData. Which fields the interface actually returns is the limit of what can be checked; business data that is not returned cannot be assumed to be retained in full. The interactive node response returns only the display configuration, containing type and params; internal runtime fields such as entryNodeIds, memoryEdges, nodeOutputs, and nodeResponseId are not returned. When an internal children, loop, or tool wrapper interaction is hit, the interface returns the deepest user-facing interactive node.
Hypothetical paper exercise sample: on 3 June 2025, a brand hands over the promotional price approval sheet for one platform campaign from operator A to operator B. The approval sheet reads, in three sentences: "Campaign object: enrollment goods for shop S from 10 June to 12 June 2025; promotional price: the version approved by the finance business partner on 5 June governs; current status: the approval sheet has been submitted, and the finance business partner is reviewing it." The draft handover sentence reads: "The approval has passed, so B may lock campaign inventory on this basis and quote the promotional price externally." The question to decide: does the draft sentence match the approval sheet text.
Configuration and implementation checks
| Check item | Documented setting or implementation check | Relation to this page's sample |
|---|---|---|
| Application identifier | When calling chat/completions, passing body.appId in the request body is recommended; appId priority is body.appId, then apiKey-appId, then the appId associated with the apikey | Check which application the sample conversation belongs to |
| Session identifier | A non-empty chatId takes the session from the database; uniqueness and a length under 250 characters must be ensured | Check which session the approval-related conversation belongs to |
| Conversation identifier | dataId identifies one conversation under a session; responseChatItemId must be unique under the current chatId | Locate the single conversation round under audit |
| Run detail | With detail=true and stream=false, intermediate values and the complete result are held in responseData | See which fields that conversation round actually returned |
| Proxy identity | Using authProxy requires the team owner to enable it when creating or editing the key; the proxy identity still needs permission for the target application and session | Judge whether both handover parties hold permission for that application |
| Hypothetical starting point for this exercise | If 5 June is used as the approval version comparison date, that date comes from the sample text and is compared against the approval date stated on the sheet | For this paper check only; not an official default |
Three common errors
- Treating "under review" as "approved." The sample text states the finance business partner is reviewing it, while the draft sentence writes that the approval has passed. This is an inconsistent value for the same field, same subject, and same period. A pending review does not show that operating permission is missing, and it does not constitute a completed approval.
- Treating the existence of a log as completed business authorization. A log records a session and its run process and does not record an approval conclusion. Even where that conversation round can be found, this does not establish that B has been authorized to lock inventory or quote externally.
- Treating retrieval or similarity as a permission filter. Similarity is a degree of matching and does not carry entity or authorization isolation. Finding a record does not mean that record is usable by the current operator.
How to verify the setup
- Input the sample text "current status: the approval sheet has been submitted, and the finance business partner is reviewing it" together with the draft sentence "the approval has passed." Compare the status field of the same approval sheet in the same period. The "passed" determination is satisfied only where the source text contains an explicit statement of approval. Under the current source text that determination does not hold, and the item is recorded as awaiting verification.
- Input the appId, chatId, and dataId from the sample, request the run detail under the documented contract, and inspect responseData. Compare the returned fields against the fields the sample needs. "This conversation round is findable" is satisfied only where the actual return contains the corresponding conversation and run information. Where fields are missing, record the gap and do not assume full retention.
- Input the sample handover request "B may lock campaign inventory on this basis and quote the promotional price externally." Compare the action described in the request against the authorization scope stated on the approval sheet. The request is satisfied only where the approval sheet explicitly states that authorization. The current source text does not state it, and the item is recorded as unsupported. For empty-result downstream design, an explicit paper input of [] can be used to check the downstream design; this does not claim that a fictional rule retrieval necessarily returns [].