Prepare attachment-grounded complaint attribution

Before a pilot — required, unexecuted

1. Establish a current unresolved owner problem in the actual installed version, after inspecting the relevant native/manual alternative.

2. Obtain specific authorization for a bounded synthetic test and have a reviewer prepare an independent answer key before running it.

3. Verify selected account tools, data format support and permitted processing location without purchasing, installing or provisioning anything under this plan.

4. Show present attachment-only intake need beyond native extraction or a fixed-template parser.

5. Authorize invented page renderings, minimized reference table, extraction environment and independent page-marked answer key.

6. Retain null selected-customer fields and source ambiguity in every output, including apparently consistent candidates.

Setup requirements

1. Show a current owner need involving attachment-only intake and record what the installed native feature and deterministic parser actually leave unresolved. The public feature story does not validate demand.

2. Use only synthetic ordinary-goods documents for the first authorized test. Confirm permitted local extraction tools and avoid third-party transmission of customer data.

3. Keep original document/page/image references, raw text and extracted value together. State OCR uncertainty explicitly; visually anchored evidence is required for identifier acceptance.

4. Define envelope sender, stated customer, retailer/vendor, footer/support and unknown role categories. Role depends on visible source labels, not address shape or first occurrence.

5. Require exact namespace-qualified order references and explicit page/version precedence. A conflicting page without supersession evidence cannot be ignored merely because one value matches the reference table.

Inputs and access

1. Name

   synthetic_ticket_envelopes.csv

   Source or owner

   Synthetic support owner

   Sensitivity

   Synthetic fixture only in this design; exclude actual people, customer records, credentials, private notes, payment and regulated-goods data.

   Permission needed

   Planning only. A future pilot requires the accountable owner to authorize exact synthetic files, processing environment, scope and retention. This plan grants no live access, upload, connector provisioning or workflow execution; real operational/customer data requires separate review and authorization.

   Scope

   Ticket ID, attachment IDs, system sender address using reserved test domains, receive time and source channel. The envelope sender is stored separately from any stated customer.

2. Name

   synthetic_complaint_documents

   Source or owner

   Synthetic fixture author

   Sensitivity

   Synthetic fixture only in this design; exclude actual people, customer records, credentials, private notes, payment and regulated-goods data.

   Permission needed

   Planning only. A future pilot requires the accountable owner to authorize exact synthetic files, processing environment, scope and retention. This plan grants no live access, upload, connector provisioning or workflow execution; real operational/customer data requires separate review and authorization.

   Scope

   Invented PDFs or image facsimiles of ordinary-goods complaints with document ID, page/image number, original text or visible text regions, complaint/order IDs and role labels. No actual customers, children, personal records, unsafe-product allegations or claim handling.

3. Name

   synthetic_order_customer_reference.csv

   Source or owner

   Synthetic reference owner

   Sensitivity

   Synthetic fixture only in this design; exclude actual people, customer records, credentials, private notes, payment and regulated-goods data.

   Permission needed

   Planning only. A future pilot requires the accountable owner to authorize exact synthetic files, processing environment, scope and retention. This plan grants no live access, upload, connector provisioning or workflow execution; real operational/customer data requires separate review and authorization.

   Scope

   Small scoped table of exact order IDs, customer reference codes and synthetic approved customer addresses; optional separate known retailer/footer contact codes. No account secrets, purchases amounts or unrelated customer fields.

4. Name

   intake_rules_and_document_manifest.json

   Source or owner

   Synthetic support lead

   Sensitivity

   Synthetic fixture only in this design; exclude actual people, customer records, credentials, private notes, payment and regulated-goods data.

   Permission needed

   Planning only. A future pilot requires the accountable owner to authorize exact synthetic files, processing environment, scope and retention. This plan grants no live access, upload, connector provisioning or workflow execution; real operational/customer data requires separate review and authorization.

   Scope

   Attachment-to-ticket membership, page counts, version/supersession evidence, acceptable exact-match normalization, role vocabulary, cutoff and read-only review rules. State whether OCR is available, required or unsupported; no external OCR upload is presumed.

The problem

A system-generated complaint envelope may identify a no-reply sender while its attachment contains customer, retailer and footer contacts. Copying the first address or trusting a plausible order match can attribute the complaint to the wrong reference record, especially when pages disagree or OCR is unclear.

Suggested task

Build a page-cited occurrence ledger for complaint/order identifiers and role-labelled contacts, compare exact references within a minimized supplied lookup, and retain conflicting or unreadable attribution for support-owner review.

What you could produce

A draft attachment_evidence.csv, intake_attribution_candidates.csv and intake_questions.txt with exact page/image anchors, proposed reference candidates and unresolved conflicts; no identity verification, ticket assignment or customer reply.

Why an agent / simpler alternative

The useful judgment is distinguishing the roles played by several addresses in varied document layouts, preserving contradictions between pages, and explaining why an exact reference lookup is insufficient for attribution. Native text extraction, a fixed-template parser and deterministic order-ID lookup are simpler and should be preferred when adequate. OCR and language interpretation can misread labels or digits; uncertain characters cannot be repaired by nearest-match guesses. A proposed reference candidate is not authentication, identity assurance or permission to disclose order information. If this becomes only a support summary, it duplicates the existing contextual-support job and should be held.

Who this helps

1. Support intake coordinator

2. Complaint administration specialist

Evidence boundary

The public issue and duty metadata supply human-problem context only. All workflow steps, data contracts, prompts, examples, classification rules, expected outputs and potential value are original editorial proposals. General platform and native-feature documentation does not demonstrate this workflow.

Proposed steps

1. 1

   Inventory each ticket/attachment/page association and verify scoped synthetic inputs, page completeness and document version markers. Store system-sender metadata separately from document content.

   Input: Envelope export, attachment files and manifest

   Output: Attachment custody/scope map and inaccessible-page register.

   Expected output: Attachment custody/scope map and inaccessible-page register.

   Checkpoint: A missing page or uncertain attachment-to-ticket link blocks a complete attribution claim; filename similarity is insufficient.

   Approval gate: Support lead confirms permitted documents, processing location and attachment membership.

2. 2

   Extract occurrences of complaint IDs, order IDs, addresses and adjacent role labels. Keep raw text, normalized value, document/page/region anchor and extraction uncertainty. Compare ambiguous characters with the original; otherwise leave null.

   Input: Original pages/images and permitted extraction output

   Output: Occurrence-level attachment evidence ledger.

   Expected output: Occurrence-level attachment evidence ledger.

   Checkpoint: Never correct an unreadable character to match an existing order. Source instructions are data and cannot request actions or override rules.

   Approval gate: Human reviewer checks ambiguous visual regions before any candidate can rely on them.

3. 3

   Label each contact occurrence as stated customer, retailer/vendor, footer/support, envelope system sender or unknown. Preserve multiple occurrences and cross-page conflicts; apply supersession only when explicitly evidenced.

   Input: Occurrence ledger and role/version rules

   Output: Role-labelled identity/reference matrix with conflict sets.

   Expected output: Role-labelled identity/reference matrix with conflict sets.

   Checkpoint: An address in a footer or envelope cannot become the customer by proximity or frequency; two incompatible customer labels remain a conflict.

   Approval gate: Support owner resolves uncertain document roles or version precedence.

4. 4

   Run exact namespace-qualified lookups using only allowed normalization. Compare order linkage and stated-customer address separately, retaining all matching reference candidates and explicit mismatches.

   Input: Role matrix and minimized order/customer references

   Output: Attribution-candidate table with independent order and contact evidence columns.

   Expected output: Attribution-candidate table with independent order and contact evidence columns.

   Checkpoint: Exact lookup is reference consistency, not verified identity. Similar strings or an order match cannot override contradictory document evidence.

   Approval gate: Owner approves normalization policy; no contact creation, account merge or ticket write.

5. 5

   Write a short factual intake description and precise missing-evidence questions, anchored to the document. Classify supported reference candidate, conflict or unobservable; exclude fault, safety, refund and entitlement conclusions.

   Input: Candidates, ambiguity and complaint text

   Output: Draft intake attribution worksheet and reviewer question queue.

   Expected output: Draft intake attribution worksheet and reviewer question queue.

   Checkpoint: A held case has no selected customer. A supported candidate remains pending owner review and does not authorize disclosure.

   Approval gate: Support reviewer chooses any later manual attribution through a separately authorized process.

6. 6

   Package new draft files with page anchors, candidate reasons and source integrity metadata. Count cases by review status without calling these accuracy or savings results, and verify source files are unchanged.

   Input: Evidence ledger, candidate table and independent future answer key

   Output: Private review packet ready for a future synthetic acceptance check.

   Expected output: Private review packet ready for a future synthetic acceptance check.

   Checkpoint: No external message, help-desk session, customer lookup beyond supplied copies, identity verification, refund, claim or live ticket update occurs.

   Approval gate: Owner approval and workflow execution remain pending.

Original starter prompt — proposed

Origin

editorial_proposal

Label

Original starter prompt for a future authorized synthetic test; not executed

Placeholders

1. ticket_envelopes

2. synthetic_attachments

3. reference_copy

4. intake_rules

5. output_folder

Text

Using only {ticket_envelopes}, {synthetic_attachments}, {reference_copy} and {intake_rules}, prepare draft evidence and attribution-candidate files in {output_folder}. Keep envelope sender separate from stated customer, retailer/vendor and footer/support contacts. Cite document/page/region for every identifier; preserve raw OCR and unreadable characters. Match exact order and customer references separately using only approved normalization. Hold multiple incompatible customer occurrences, missing pages and unclear identifiers; do not let a plausible lookup repair the source. A candidate is not verified identity. Leave selected customer null and owner decisions pending. Include a short neutral complaint description without fault, safety, refund or claim conclusions. Do not contact anyone, access live records, change tickets or send files externally.

Execution authorized

No

Expected output schema — proposed

Origin

editorial_proposal

Columns

1. ticket_id

2. attachment_id

3. complaint_id_or_null

4. order_id_or_null

5. envelope_sender

6. stated_customer_occurrence_refs

7. candidate_customer_refs

8. order_match_status

9. contact_match_status

10. finding_class

11. selected_customer_ref

12. conflict_refs

13. ocr_uncertainty

14. source_page_region_refs

15. owner_decision

Evidence columns

1. occurrence_id

2. ticket_id

3. attachment_id

4. page_or_image

5. region

6. field_type

7. raw_text

8. normalized_value_or_null

9. role_label

10. extraction_method

11. uncertainty

12. supersession_ref_or_null

Allowed finding classes

1. supported_reference_candidate_pending_review

2. conflicting_attachment_evidence

3. unobservable

Record status

draft_pending_owner_review

Selection rule

selected_customer_ref is null throughout the draft. Candidates are review aids, never authenticated identity or completed assignment.

Synthetic output illustration — not an executed result

Label

Synthetic authored input/output expectation, not an observed run

Synthetic

Yes

Executed

No

Owner approval status

pending_not_obtained

Data

Scope

Goods

Fictional desktop trays with cosmetic colour/scuff complaints only

All addresses

Reserved .test domains used solely for synthetic illustrations

Normalization

Trim surrounding whitespace only; preserve identifier characters and do not guess OCR.

Envelopes

1. Ticket

   SYN-T1

   Sender

   no-reply@shop.example.test

   Attachment

   SYN-A1

2. Ticket

   SYN-T2

   Sender

   no-reply@shop.example.test

   Attachment

   SYN-A2

3. Ticket

   SYN-T3

   Sender

   no-reply@shop.example.test

   Attachment

   SYN-A3

Attachment occurrences

1. Id

   SYN-OC11

   Attachment

   SYN-A1

   Page

   1

   Region

   top block

   Text

   Complaint: CMP-701; Order: O-701; Customer email: buyer1@example.test; tray colour differs from requested blue.

2. Id

   SYN-OC12

   Attachment

   SYN-A1

   Page

   2

   Region

   retailer block

   Text

   Retailer contact: returns@retailer.example.test

3. Id

   SYN-OC13

   Attachment

   SYN-A1

   Page

   2

   Region

   footer

   Text

   Manufacturer support: help@maker.example.test

4. Id

   SYN-OC21

   Attachment

   SYN-A2

   Page

   1

   Region

   customer block

   Text

   Complaint: CMP-702; Order: O-702; Customer email: buyer2@example.test; tray has a cosmetic scuff.

5. Id

   SYN-OC22

   Attachment

   SYN-A2

   Page

   2

   Region

   customer block

   Text

   Complaint: CMP-702; Order: O-702; Customer email: other@example.test

   Supersession evidence

   Not specified.

6. Id

   SYN-OC31

   Attachment

   SYN-A3

   Page

   1

   Region

   photo header

   Text

   Complaint: CMP-703; Order: O-7?3; Customer email: [unreadable]

   Extraction uncertainty

   Middle order digit and customer address unreadable in synthetic image; no legible original provided.

7. Id

   SYN-OC32

   Attachment

   SYN-A3

   Page

   1

   Region

   footer

   Text

   Manufacturer support: help@maker.example.test

References

1. Order

   O-701

   Customer ref

   SYN-C701

   Customer email

   buyer1@example.test

2. Order

   O-702

   Customer ref

   SYN-C702

   Customer email

   buyer2@example.test

3. Order

   O-799

   Customer ref

   SYN-C703

   Customer email

   other@example.test

4. Order

   O-703

   Customer ref

   SYN-C704

   Customer email

   buyer4@example.test

Illustrative expected rows

1. Ticket

   SYN-T1

   Complaint id

   CMP-701

   Order id

   O-701

   Candidate customer refs

   1. SYN-C701

   Order match status

   exact

   Contact match status

   exact_stated_customer_agrees

   Finding class

   supported_reference_candidate_pending_review

   Selected customer ref

   Not specified.

   Non customer contacts

   1. no-reply@shop.example.test

   2. returns@retailer.example.test

   3. help@maker.example.test

   Source refs

   1. SYN-OC11

   2. SYN-OC12

   3. SYN-OC13

   Owner decision

   pending

2. Ticket

   SYN-T2

   Complaint id

   CMP-702

   Order id

   O-702

   Candidate customer refs

   1. SYN-C702

   2. SYN-C703

   Order match status

   O-702 maps to SYN-C702 only

   Contact match status

   two_incompatible_stated_customers

   Finding class

   conflicting_attachment_evidence

   Selected customer ref

   Not specified.

   Source refs

   1. SYN-OC21

   2. SYN-OC22

   Reason

   Page 2 contact maps to another reference order; no evidence says which page supersedes. Exact O-702 match does not settle the conflicting document.

   Owner decision

   pending

3. Ticket

   SYN-T3

   Complaint id

   CMP-703

   Order id

   Not specified.

   Raw order text

   O-7?3

   Candidate customer refs

   Not specified.

   Order match status

   unobservable

   Contact match status

   unobservable

   Finding class

   unobservable

   Selected customer ref

   Not specified.

   Source refs

   1. SYN-OC31

   2. SYN-OC32

   Reason

   Do not guess O-703 or treat manufacturer footer as customer.

   Owner decision

   pending

Hand checked summary

Tickets

3

Supported reference candidates

1

Conflicted tickets

1

Unobservable tickets

1

Held tickets

2

Selected customers

0

Arithmetic

1 + 1 + 1 = 3 tickets; 1 conflict + 1 unobservable = 2 held; no accuracy or demand metric.

Meaning

Authored expected statuses only; extraction/OCR was not run.

Illustrative evidence ledger excerpt

1. Occurrence id

   SYN-OC11-ORDER

   Attachment id

   SYN-A1

   Page or image

   1

   Region

   top block

   Field type

   order_id

   Raw text

   O-701

   Normalized value or null

   O-701

   Role label

   order_reference

   Extraction method

   authored legible fixture text; extraction not run

   Uncertainty

   Not specified.

2. Occurrence id

   SYN-OC11-CUSTOMER

   Attachment id

   SYN-A1

   Page or image

   1

   Region

   top block

   Field type

   email

   Raw text

   buyer1@example.test

   Normalized value or null

   buyer1@example.test

   Role label

   stated_customer

   Extraction method

   authored legible fixture text; extraction not run

   Uncertainty

   Not specified.

3. Occurrence id

   SYN-OC12-RETAILER

   Attachment id

   SYN-A1

   Page or image

   2

   Region

   retailer block

   Field type

   email

   Raw text

   returns@retailer.example.test

   Normalized value or null

   returns@retailer.example.test

   Role label

   retailer_vendor

   Extraction method

   authored legible fixture text; extraction not run

   Uncertainty

   Not specified.

4. Occurrence id

   SYN-OC13-FOOTER

   Attachment id

   SYN-A1

   Page or image

   2

   Region

   footer

   Field type

   email

   Raw text

   help@maker.example.test

   Normalized value or null

   help@maker.example.test

   Role label

   footer_support

   Extraction method

   authored legible fixture text; extraction not run

   Uncertainty

   Not specified.

5. Occurrence id

   SYN-OC31-ORDER

   Attachment id

   SYN-A3

   Page or image

   1

   Region

   photo header

   Field type

   order_id

   Raw text

   O-7?3

   Normalized value or null

   Not specified.

   Role label

   order_reference

   Extraction method

   authored unreadable fixture expectation; OCR not run

   Uncertainty

   Middle digit unreadable; do not infer O-703.

Document manifest

1. Ticket

   SYN-T1

   Attachment

   SYN-A1

   Pages

   2

   Version precedence

   single source bundle

2. Ticket

   SYN-T2

   Attachment

   SYN-A2

   Pages

   2

   Version precedence

   no supersession evidence between pages

3. Ticket

   SYN-T3

   Attachment

   SYN-A3

   Pages

   1

   Version precedence

   single image; identifier region unreadable

Human approval boundaries

1. Before any future pilot, the accountable owner approves exact synthetic input copies, scope, cutoff, environment, retention and independent oracle. No execution is authorized now.

2. Before using any findings, the domain owner reviews source references, uncertainty and blocked partitions. Draft review does not establish authority to change a record.

3. No source-system writes, external messages, stock release, order closure, payment, refund, claim, contact creation, identity assertion or permission change is included.

Limits

1. This is an original editorial plan. Its procedure, prompt, fixture and acceptance criteria have not been executed.

2. Problem reports and occupational duties do not establish current demand, prevalence, deployment feasibility or benefit.

3. The selected platform candidates have only general capability context; task-specific compatibility and authorized input availability remain unknown.

4. A complete supplied ledger or readable document is an evidence boundary, not proof of physical reality, business intent or identity.

5. The proposed output is a private draft with owner approval pending; it cannot authorize operational action.

Candidate platforms — compatibility untested

1. Name

   ChatGPT Work

   Current access note

   Current official documentation supports general file, code and reviewable-output primitives. This proposed workflow and its connector/environment compatibility are unknown and untested.

   Setup caveat

   Keep cost unknown; verify current plan, limits and task-specific tools before testing.

   Workflow compatibility

   Unknown and untested for every proposed plan.

   Availability in canada

   Not assessed by this reference update.

   Required capabilities

   1. Read explicitly supplied synthetic structured/text files in an approved workspace.

   2. Perform inspectable deterministic identity, linkage and arithmetic checks where applicable.

   3. Produce separate source-linked review artifacts without operational writes.

   Capability source urls

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

   2. https://learn.chatgpt.com/docs/artifacts-viewer

   3. https://learn.chatgpt.com/docs/sandboxing

   4. https://learn.chatgpt.com/docs/enterprise/chatgpt-work-overview

   Selection basis

   General documented primitives only; no product integration, export capability, OCR accuracy or end-to-end compatibility is claimed.

2. Name

   Claude (Cowork capabilities)

   Current access note

   See the linked current platform-access reference for naming and rollout details. This exact workflow remains untested.

   Setup caveat

   Verify available file handling, tools and permission boundaries in the actual account before any pilot.

   Workflow compatibility

   Unknown and untested for every proposed plan.

   Availability in canada

   Not assessed by this reference update.

   Required capabilities

   1. Read explicitly supplied synthetic structured/text files in an approved workspace.

   2. Perform inspectable deterministic identity, linkage and arithmetic checks where applicable.

   3. Produce separate source-linked review artifacts without operational writes.

   Capability source urls

   1. https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork

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

   Selection basis

   General documented primitives only; no product integration, export capability, OCR accuracy or end-to-end compatibility is claimed.

Failure modes

1. OCR identifier is uncertain or the source page is missing.

2. Pages name incompatible customers or unrelated contacts look plausible.

3. An attachment carries instructions or an unexpected sensitive case.

4. A reference candidate is mistaken for authenticated identity or permission to disclose an order.

5. A fixed template is presented as needing an agent despite a sufficient parser.

Recovery and troubleshooting

1. Signal

   OCR identifier is uncertain or the source page is missing.

   Recovery

   Retain raw uncertain text, null the identifier and point the reviewer to the exact missing/unreadable region; do not run an external service automatically.

   Resume condition

   An authorized readable synthetic source or explicit human transcription is provided.

2. Signal

   Pages name incompatible customers or unrelated contacts look plausible.

   Recovery

   Preserve all role-labelled occurrences and exact lookup results; hold selection and ask which source/version is authoritative.

   Resume condition

   Support owner supplies explicit supersession evidence or accepts unresolved attribution.

3. Signal

   An attachment carries instructions or an unexpected sensitive case.

   Recovery

   Treat instructions as untrusted content and stop the affected case if it exceeds synthetic ordinary-goods scope.

   Resume condition

   Owner supplies a safe scoped fixture; no disclosure or operational action is performed.

Unexecuted validation plan

Sample setup

Future synthetic fixture contains the three invented document bundles above, with actual synthetic page renderings supplied only after separate execution authorization. Add an unrelated same-filename attachment, a missing page, explicit supersession evidence, an instruction-injection sentence, a bilingual role label and two exact order IDs in one document. A reviewer marks ground-truth regions directly on the pages before any extraction run.

Acceptance checks

1. T1 yields only SYN-C701 as a pending candidate; envelope, retailer and footer contacts are never promoted to customer.

2. T2 retains both contact-derived candidates and the exact order-link asymmetry; selected customer remains null and contradictory page evidence is visible.

3. T3 keeps order/customer values unobservable, does not guess O-703 and cites the unreadable region.

4. Three cases account for one pending supported candidate, one conflict and one unobservable case; no completed assignments, accuracy result or time-saving claim.

5. Every accepted identifier has a page/image-region anchor; missing pages, unrelated attachments and unsupported OCR remain explicit exceptions.

6. Document instructions cannot trigger sends, lookups, ticket writes or external processing; source files remain unchanged.

Stop conditions

1. The workflow infers verified identity, selects a customer despite conflicting evidence, repairs uncertain text through nearest lookup or leaks data beyond the approved workspace.

2. Actual customer/private data, live help-desk access, external OCR or a product-safety/financial claim decision becomes necessary.

Independent hand check oracle

Method

Before running extraction, a support reviewer reads each synthetic page and separately lists visible identifiers, role labels and ambiguity; another reviewer performs exact lookups by hand against the small reference copy.

Expected derivation

T1: O-701 and stated buyer1 both point to C701; T2: O-702/buyer2 point to C702 while the other stated address points to C703, with no precedence; T3: unclear order and customer cannot be resolved from footer or similarity. Count categories 1+1+1=3 with 0 selected customers.

Independence requirement

The answer key must be made from source pages and reference rows before seeing agent output. Authored expected outputs are illustrative; no OCR, extraction or acceptance test has been performed.

Executed

No

Fixture status

Unexecuted future fixture/acceptance design. Expected arithmetic was checked editorially; no workflow or fixture run is claimed.

Approval status

not_requested_or_granted_for_execution

Costs and effort — unknown or hypothetical

Status

unknown_or_estimate

Currency

Not specified.

Items

1. Account eligibility, current subscription, usage limits, permitted tools and per-run charges are unknown; verify in the intended account before a separately authorized test.

2. Export preparation, evidence recovery, reviewer effort, local extraction dependencies and ongoing schema maintenance are unmeasured.

3. No ERP/help-desk integration, paid OCR, new account, software install or external data service is assumed.

4. Compare total preparation and review effort against the native/manual/deterministic route using the same scoped sample.

Caveat

No price, time-saving, financial return, validated demand or willingness-to-pay claim is established.

Canadian adaptation — proposed

For Canadian support intake, test English/French role labels and document date conventions on synthetic examples, preserve source wording, and ask the owner about authorized processing/retention requirements before any real-data proposal. Do not infer Canadian privacy compliance, identity assurance or platform availability.