Review component-only returns against the kit originally sold

Setup requirements

1. The original sold composition is authoritative; the current product BOM may differ.

2. Separate customer request, physical receipt, commercial approval and financial credit.

3. A quantity match alone does not establish return eligibility or monetary value.

4. Agree this bounded synthetic scope and confirm a real unresolved need before any implementation pilot. The written design does not authorize executing it.

Inputs and access

1. Name

   original_sale.json

   Source or owner

   Sales owner

   Scope

   Synthetic invoice line, kit quantity, sold kit/BOM version and any approved component credit schedule.

   Sensitivity

   Synthetic fixture only. A real-data pilot requires a separate minimized scope and approved handling.

   Permission needed

   Owner approval of exact data, processing environment, retention and recipients before a pilot. No pilot is authorized by this plan.

2. Name

   delivery_components.json

   Source or owner

   Warehouse owner

   Scope

   Synthetic delivered component IDs, quantities, serials if relevant and links to the kit sale.

   Sensitivity

   Synthetic fixture only. A real-data pilot requires a separate minimized scope and approved handling.

   Permission needed

   Owner approval of exact data, processing environment, retention and recipients before a pilot. No pilot is authorized by this plan.

3. Name

   return_intake.txt

   Source or owner

   Returns owner

   Scope

   Synthetic requested and physically received components with original-order references and inspection status.

   Sensitivity

   Synthetic fixture only. A real-data pilot requires a separate minimized scope and approved handling.

   Permission needed

   Owner approval of exact data, processing environment, retention and recipients before a pilot. No pilot is authorized by this plan.

4. Name

   prior_returns.json

   Source or owner

   Returns owner

   Scope

   Synthetic prior component returns, credited amounts and allocation IDs.

   Sensitivity

   Synthetic fixture only. A real-data pilot requires a separate minimized scope and approved handling.

   Permission needed

   Owner approval of exact data, processing environment, retention and recipients before a pilot. No pilot is authorized by this plan.

5. Name

   return_rules.json

   Source or owner

   Commercial owner

   Scope

   Approved quantity limits, rounding and credit basis; explicitly unknown values remain unknown.

   Sensitivity

   Synthetic fixture only. A real-data pilot requires a separate minimized scope and approved handling.

   Permission needed

   Owner approval of exact data, processing environment, retention and recipients before a pilot. No pilot is authorized by this plan.

Human approval boundaries

1. Before a pilot, the accountable owner approves exact synthetic/minimized copies, processing environment, retention and allowed recipients.

2. Owner validates identity mappings, authority, status definitions and all unresolved evidence.

3. Any source mutation, account access, upload, external communication, commercial commitment, payment or changed permission requires separate appropriate authorization.

The problem

A component return may not map cleanly to a single-line kit invoice. The reviewer needs the original kit composition and previous returns before deciding what quantity and credit basis to approve.

Suggested task

Map received components to the original delivered kit version, check prior return coverage and prepare an owner-review credit basis.

What you could produce

A component-return quantity bridge plus unresolved credit-basis questions, with no refund or credit note issued.

Why an agent / simpler alternative

An agent can reconstruct references across mixed return notes and historical kit documents. Component expansion and quantity limits are deterministic. Native RMA functionality is preferable if it already retains sold-BOM and component credit relationships.

When this work comes up

Role

Returns administrator

Trigger

A customer requests return of selected components from an invoiced kit.

Human approval

Owner reviews scope, rules, identities and findings; operating decisions remain separately authorized.

Finished output

A component-return quantity bridge plus unresolved credit-basis questions, with no refund or credit note issued.

Proposed evaluation scope — no pilot authorized

Scope

At most 10 synthetic return cases linked to exact original sale lines and sold kit versions.

Limit origin

Original editorial evaluation bound, not a verified tool limit.

Overflow action

Stop and request owner-approved partitioning; no silent truncation.

Pilot authorized

No

Evidence boundary

Source facts describe human friction; O*NET describes duties; shared official documentation supports file primitives. The six-step workflow, safeguards, numerical fixture and outputs are original proposed designs.

Proposed steps

1. 1

   Confirm the original sale and sold composition version, scope and owner-provided return rules.

   Output: Kit-sale evidence manifest.

   Expected output: Kit-sale evidence manifest.

   Checkpoint: Retain source IDs/spans and explicit unknown states. No source writes or external action.

   Approval gate: Owner approves exact inputs and rule scope before any pilot.

2. 2

   Extract returned component observations and join only explicit delivery or serial references.

   Output: Return-to-delivery candidates.

   Expected output: Return-to-delivery candidates.

   Checkpoint: Retain source IDs/spans and explicit unknown states. No source writes or external action.

   Approval gate: Owner resolves ambiguous meaning, identity or authority before affected rows advance.

3. 3

   Expand the original sold kit into its delivered components and subtract previously approved quantity allocations.

   Output: Remaining component quantity basis.

   Expected output: Remaining component quantity basis.

   Checkpoint: Retain source IDs/spans and explicit unknown states. No source writes or external action.

   Approval gate: Owner resolves ambiguous meaning, identity or authority before affected rows advance.

4. 4

   Compare the current return against that basis, flag duplicates, excess units and components absent from the sold version.

   Output: Quantity exception table.

   Expected output: Quantity exception table.

   Checkpoint: Retain source IDs/spans and explicit unknown states. No source writes or external action.

   Approval gate: Owner resolves ambiguous meaning, identity or authority before affected rows advance.

5. 5

   Apply a supplied component credit schedule only where explicit; otherwise prepare a question without allocating the kit price.

   Output: Credit-basis review draft.

   Expected output: Credit-basis review draft.

   Checkpoint: Retain source IDs/spans and explicit unknown states. No source writes or external action.

   Approval gate: Owner reviews draft findings; no operational action authorized.

6. 6

   Package the traceable quantities, unresolved commercial decisions and acceptance specification for the returns owner.

   Output: Non-postable return packet.

   Expected output: Non-postable return packet.

   Checkpoint: Retain source IDs/spans and explicit unknown states. No source writes or external action.

   Approval gate: Owner accepts the review artifact; any live change or communication needs separate approval.

Original starter prompt — proposed

Origin

editorial_proposal

Execution authorized

No

Text

Using only {approved_synthetic_inputs} and {owner_rules}, Map received components to the original delivered kit version, check prior return coverage and prepare an owner-review credit basis. Follow the six-step design. Preserve exact identities, source citations and uncertainty; make calculations inspectable. Write only separate review drafts to {approved_output_folder}. Do not guess missing facts, alter sources, access accounts, send, upload, buy, post, settle, make personnel decisions or claim the fixture passed.

Expected output schema — proposed

Primary key

1. return_case_id

2. original_invoice_line_id

3. delivery_component_id

4. return_allocation_id

Columns

1. sold_kit_version

2. component_id

3. delivered_units

4. prior_returned_units

5. requested_units

6. received_units

7. quantity_excess

8. credit_rule_id

9. review_amount

10. currency

11. approval_state

12. source_spans

13. prior_return_allocation_ids

14. prior_credit_ids

15. current_return_appearance_ids

Record status

draft_review_only

Common provenance columns

1. input_snapshot_id

2. rule_version

3. source_document_id

4. source_row_or_span

5. reviewer_decision

Unknown value policy

Unknown numeric values remain null, never zero. Preserve raw rows and typed relation/allocation IDs; unresolved rows do not silently enter approved totals.

Synthetic output illustration — not an executed result

Label

Synthetic authored example, not observed output

Synthetic

Yes

Executed

No

Input

V1 brackets

4

Prior return

1

Current request

4

V2 brackets

6

Credit schedule

Not specified.

Expected

Remaining quantity

3

Excess requested

1

Review amount

Not specified.

Credit authorized

No

Limits

1. Original proposed and untested design; no source documents this complete agent workflow.

2. A reported problem is not proof of prevalence, willingness to pay, harm magnitude or current demand.

3. Historical product reports require current-installation checks; a current capability document only establishes general primitives.

4. Native reports or a deterministic script may be simpler. Exports, identity mappings, context size, privacy controls and actual tool compatibility remain untested.

5. Numerical fixtures are synthetic and have not been executed. Owner review is necessary; no time saving, cost saving or revenue outcome is asserted.

Candidate platforms — compatibility untested

1. Name

   ChatGPT Work

   Required capabilities

   1. Assess this plan’s input, operation and output requirements before selecting an account.

   Capability source urls

   1. https://learn.chatgpt.com/docs/get-started-with-work

   Selection basis

   Editorial candidate only. Shared source facts are general primitives; this plan remains unexecuted.

   Workflow compatibility

   BotCurrent has not tested this workflow.

2. Name

   Claude

   Required capabilities

   1. Assess this plan’s input, operation and output requirements before selecting an account.

   Capability source urls

   1. https://support.claude.com/en/articles/16761823-claude-cowork-and-chat-are-one-claude

   Selection basis

   Editorial candidate only. Shared source facts are general primitives; this plan remains unexecuted.

   Workflow compatibility

   BotCurrent has not tested this workflow.

Failure modes

1. The latest BOM replaces the composition actually delivered.

2. One component is returned twice under separate case IDs.

3. The full kit price is divided equally among unlike components.

Recovery and troubleshooting

1. Signal

   The latest BOM replaces the composition actually delivered.

   Recovery

   Recover the sold version or hold the kit expansion until the owner supplies it.

   Resume condition

   The accountable owner supplies the missing authoritative evidence or approved interpretation; otherwise keep the affected result unresolved.

2. Signal

   One component is returned twice under separate case IDs.

   Recovery

   Aggregate prior and proposed component allocations by original delivery/serial and retain duplicate appearances.

   Resume condition

   The accountable owner supplies the missing authoritative evidence or approved interpretation; otherwise keep the affected result unresolved.

3. Signal

   The full kit price is divided equally among unlike components.

   Recovery

   Leave credit amount unknown unless an explicit owner-approved basis exists.

   Resume condition

   The accountable owner supplies the missing authoritative evidence or approved interpretation; otherwise keep the affected result unresolved.

Unexecuted validation plan

Sample setup

One synthetic lighting kit K1 sold two housings and four brackets under BOMv1. One bracket was already returned. Current intake requests all four brackets, but only three remain. BOMv2 now has six brackets. No component credit schedule is supplied. Add an unlinked housing serial.

Acceptance checks

1. The remaining bracket basis is 3, and current request 4 has excess 1; BOMv2 does not change it.

2. The missing credit schedule leaves review_amount null rather than one-sixth of the kit price.

3. The unlinked serial remains unresolved.

4. Prior returns remain traceable by allocation ID and cannot be subtracted twice.

5. No return eligibility, refund, credit note, tax or inventory decision is issued.

6. Every conclusion traces to approved source rows or an explicitly labelled owner rule; rerunning the same frozen input must not change identities or totals.

7. All source copies remain unchanged. Any duplicate, missing key, stale snapshot or conflicting authority is held visibly.

Stop conditions

1. Input scope, required identity or calculation policy is missing.

2. Unexpected real sensitive/personal data is supplied before handling approval.

3. The requested output would require live account access, external upload/send, accounting posting, purchase, access change or irreversible action.

Executed

No

Fixture status

Designed only; no acceptance fixture or workflow executed.

Costs and effort — unknown or hypothetical

Status

unknown_or_estimate

Currency

Not specified.

Items

1. Plan access, model usage, tool runtime and storage costs unknown.

2. Export preparation, evidence cleanup, review and correction effort unmeasured.

3. No native integration, paid service, new account or software installation assumed.

4. Case-specific effort is unknown: source extraction, identity repair, owner-rule preparation, fixture design and review may dominate model cost.

Caveat

No measured time saving, current demand, ROI or price claim. Compare the simpler remedy first.

Canadian adaptation — proposed

Verify local privacy and organizational record-handling requirements before any real-data pilot; preserve original currency, business calendars and time zones. No Canadian deployment or compliance claim.