MCN operations: workflow routing for copy drafting

Review workflow routing for copy drafting in MCN operations. Check document scope, failure paths and source evidence through controlled tests.

What the documents look like

MCN operations manage long-term account compliance for several creators at once, and the work spans more than a single brand session. For copy drafting, four document families arrive together: creator signing contracts, training records, violation handling forms, and account schedules. Source systems include the MCN backend, platform violation notices, creator account data, and the contract ledger. Updates run on daily and weekly cycles, so the same proposed sentence can require re-checking after a schedule confirmation and again after a violation record changes.

The drafting input normally comes from the schedule and the authorization scope recorded in the contract ledger. The contract ledger states which categories a creator may take and for what period. Training records state which compliance training has been completed. Violation handling forms state the handling status of past incidents. When a proposed sentence touches efficacy, price, or gifts, the basis for judgment sits in the specific wording of those materials. Retrieval similarity does not carry that judgment.

Constraints at the workflow routing 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 continues after the user completes the interaction. It collects required information and passes what the user submitted to later nodes. The User Selection node is also a user interaction node. It triggers the same interaction state, and when the user makes a choice the node evaluates that choice and runs the "yes" branch. Both nodes can be added repeatedly and both trigger execution. State recording is behavior of the interaction nodes; no separate global state-recording switch is documented.

Output handoff needs item-by-item comparison. Collected information must be passed explicitly to the later retrieval, judgment, or interface nodes that consume it. Order writes, document backfill, and external status synchronization require a separate business interface or a later flow; the interaction nodes do not perform those actions themselves.

Semantic recall and relevance scores do not perform permission or entity isolation. Libraries that participate in joint association must use the same vector model; libraries on different models cannot be jointly associated. Check the identifier first and exclude the non-matching library rather than running a cross-model retrieval to compare missed recalls. Optional paths shown in an overall flow diagram do not all execute on every request: image retrieval requires a corresponding image input and model capability, and reranking requires a model and must be enabled according to settings. For empty-result handling, a clearly labelled paper input of [] can be used to check the downstream design.

Hypothetical paper exercise

Material text for checking (hypothetical, not a real record):

  1. Creator signing contract (hypothetical number H-01) provides that Creator A may take on beauty and cosmetics category copy from 1 March 2025 to 30 June 2025, excluding health food.
  2. Training record (hypothetical number H-02) states that Creator A completed advertising-wording compliance training on 20 February 2025, and the training scope covered cosmetic efficacy wording.
  3. Violation handling form (hypothetical number H-03) states that Creator A received a platform notice on 10 April 2025 concerning one short video that did not carry an "advertisement" label, and the status is "appeal submitted, awaiting platform reply."

Proposed sentence to be judged (hypothetical): "Creator A can take on all-category product copy long term, and health food efficacy wording has passed compliance review."

Handoff request (hypothetical): after the workflow has collected the creator's schedule and contract period, send the proposed sentence to the content review role for re-checking.

Configuration and implementation checks

Configuration itemTypeStarting point for this hypothetical exercise and reason
Form Input nodeOfficial nodeAfter triggering, enters the interaction state and collects three required fields: creator identifier, proposed sentence, target category
User Selection nodeOfficial nodeOffers a choice on whether the proposed sentence goes to the review role; the "yes" branch runs after the user selects
Interaction state checkImplementation checkVerify that triggering enters the interaction state and that submission passes information to later nodes; no global switch is set
Output handoff checkImplementation checkCompare form output against the input fields of the later retrieval and judgment nodes, item by item
Retrieval library vector model identifierImplementation checkVerify that libraries in joint association use the same vector model; exclude non-matching libraries first
External action splitImplementation checkOrder writes, document backfill, and external status synchronization connect to a business interface, not to the interaction nodes

The hypothetical starting point applies only to this paper check: creator identifier, proposed sentence, and target category serve as the three required form fields because the sample materials turn on those three items. Compare against the creator's authorized categories and period in the contract ledger, item by item.

Three common errors

  1. Treating "all-category" and "long term" in the proposed sentence as verified facts. Check: input the sample proposed sentence and the original text of contract H-01, compare "all-category" against "beauty and cosmetics category" and "long term" against "1 March 2025 to 30 June 2025," and observe whether the sentence wording exceeds the contract authorization scope.
  2. Treating "appeal submitted, awaiting platform reply" on the violation handling form as completed handling. Check: input the status field of H-03, compare "awaiting platform reply" against "handling completed" as two status descriptions, and observe whether a pending-reply status has been written as closed.
  3. Using retrieval relevance in place of authorization judgment. Check: input the proposed sentence and the retrieval results, compare whether the returned content contains the contract period and category fields, and observe whether publication readiness was decided on similarity alone.

How to verify the setup

  1. Input the sample proposed sentence together with the original text of contract H-01 and training record H-02. Compare "health food efficacy wording has passed compliance review" in the proposed sentence against the category scope recorded in the two materials and the training scope. If the materials do not cover health food, the sentence lacks support and does not pass the check.
  2. Input the handoff request and the branch settings of the User Selection node. Compare whether "send to the review role for re-checking" falls on a node downstream of the "yes" branch, and observe whether the submitted information reaches that node. If the branch is not connected to the review role, the request has not been taken up.
  3. Input the hypothetical empty result [] and the downstream node design. Compare whether the downstream has a defined handling path for empty input, and observe whether undefined behavior occurs on empty input. If no corresponding path exists, record it as a design item still to be supplied; do not conclude that retrieval will return [].