Separate site access, ownership and billing roles on service jobs

Setup requirements

1. Use approved, non-sensitive excerpts and synthetic party codes; redact personal addresses, phone numbers and payment details before any separately approved pilot.

2. The owner defines authoritative role evidence and effective dates.

3. Treat payer as an administrative instruction only, with liability and contract interpretation reserved for authorized humans.

Inputs and access

1. Name

   service_order_copy.csv

   Source or owner

   Service account owner

   Scope

   Synthetic order/site/asset and party codes with current contact and bill-to fields.

   Sensitivity

   Synthetic design fixture only. A future real-data pilot must use owner-approved minimized copies, exclude sensitive/unrelated personal data and credentials, and obtain separate approval for its processing environment.

   Permission needed

   No pilot is authorized by this plan. The accountable owner must approve these exact inputs, their permitted use, output recipients and retention before a future test.

2. Name

   approved_party_role_records.csv

   Source or owner

   Service account owner

   Scope

   Explicit role assignments, effective dates and source references; use pseudonymous codes, no actual personal details.

   Sensitivity

   Synthetic design fixture only. A future real-data pilot must use owner-approved minimized copies, exclude sensitive/unrelated personal data and credentials, and obtain separate approval for its processing environment.

   Permission needed

   No pilot is authorized by this plan. The accountable owner must approve these exact inputs, their permitted use, output recipients and retention before a future test.

3. Name

   service_instruction_excerpts.txt

   Source or owner

   Account owner

   Scope

   Owner-approved non-sensitive excerpts stating access contact, authorized customer and billing directions; no legal interpretation delegated.

   Sensitivity

   Synthetic design fixture only. A future real-data pilot must use owner-approved minimized copies, exclude sensitive/unrelated personal data and credentials, and obtain separate approval for its processing environment.

   Permission needed

   No pilot is authorized by this plan. The accountable owner must approve these exact inputs, their permitted use, output recipients and retention before a future test.

4. Name

   authority_rules.txt

   Source or owner

   Account owner

   Scope

   Who may approve role changes and what documentation is authoritative, including known unresolved conflicts.

   Sensitivity

   Synthetic design fixture only. A future real-data pilot must use owner-approved minimized copies, exclude sensitive/unrelated personal data and credentials, and obtain separate approval for its processing environment.

   Permission needed

   No pilot is authorized by this plan. The accountable owner must approve these exact inputs, their permitted use, output recipients and retention before a future test.

The problem

A single contact field can obscure several legitimate parties on one service job. The person who opens the site, the equipment owner, the authorized customer and the instructed payer may differ without any identity being wrong.

Suggested task

Reconcile explicit role evidence across owner-approved service records and instructions, producing a multi-party role matrix and authority questions without deciding legal liability.

What you could produce

A source-linked service-party matrix, role-collapse exceptions and pending owner questions for access, ownership, customer authority and bill-to instructions.

Why an agent / simpler alternative

An agent may recognize different role statements in short agreement and service-instruction excerpts and connect them to rigid order fields. Identity joins and effective-date comparisons should be deterministic. A well-configured party-role form or manual four-column checklist is simpler when records are already explicit; this plan cannot determine legal duties from text.

Who this helps

1. Service administration coordinator

2. Account operations specialist

Evidence boundary

Problem/occupational sources describe a human need; capability documentation establishes general primitives. The workflow, acceptance fixture and synthetic example are original designs, not source tutorials, verified compatibility or demonstrated success.

Proposed steps

1. 1

   Establish stable IDs and effective dates, retaining separate entities for site, equipment and parties; surface uncertain identity matches without merging contacts.

   Input: Order, site, asset and party records

   Output: Entity and evidence manifest.

   Expected output: Entity and evidence manifest.

   Checkpoint: Shared addresses or similar names do not establish a common legal or operational role.

   Approval gate: Account owner approves the nonpersonal scope and identity mapping.

2. 2

   Extract explicit role assertions with source spans, effective dates and who approved them. Keep access contact, asset owner, service customer and instructed payer separate.

   Input: Instruction excerpts and role vocabulary

   Output: Role assertion ledger.

   Expected output: Role assertion ledger.

   Checkpoint: A title or default field value is not evidence of payment liability or access authority.

   Approval gate: Owner resolves role meaning; the agent does not interpret legal responsibility.

3. 3

   Compare each recorded field with its corresponding approved role evidence, allowing one party to hold multiple roles and several parties to hold distinct roles.

   Input: Role ledger and order snapshot

   Output: Order-by-role matrix.

   Expected output: Order-by-role matrix.

   Checkpoint: Different party IDs across roles are not automatically duplicates or errors.

   Approval gate: No contact merge, order edit or account change occurs.

4. 4

   Identify collapsed roles, stale defaults, conflicting instructions and gaps requiring owner confirmation; do not resolve a payer conflict merely by recency.

   Input: Matrix and effective-dated authority rules

   Output: Role mismatch and authority-gap register.

   Expected output: Role mismatch and authority-gap register.

   Checkpoint: Only explicit approved instructions support a candidate administrative mapping.

   Approval gate: Account owner determines contractual authority and payment responsibility.

5. 5

   Draft candidate administrative mappings where the supplied authority uniquely determines them; otherwise write targeted questions and show the conflicting sources.

   Input: Exceptions and source references

   Output: Review worksheet with supported and blocked mappings.

   Expected output: Review worksheet with supported and blocked mappings.

   Checkpoint: No invoice generation, payment action, disclosure to any party or operational access permission is included.

   Approval gate: Owner approves every candidate mapping before any later use.

6. 6

   Package the final draft with a completeness checklist and specific downstream fields that require separate review. Preserve all source copies and existing role assignments.

   Input: Role matrix and review worksheet

   Output: Draft service-party role packet.

   Expected output: Draft service-party role packet.

   Checkpoint: No assertion that a person may enter a site or owes a debt.

   Approval gate: Authorized staff separately approve any record change, bill or communication.

Original starter prompt — proposed

Origin

editorial_proposal

Label

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

Placeholders

1. approved_inputs

2. owner_rules

3. output_folder

Execution authorized

No

Text

Using only {approved_inputs} and {owner_rules}, reconcile explicit role evidence across owner-approved service records and instructions, producing a multi-party role matrix and authority questions without deciding legal liability. Follow the six-step review design. Preserve source references and uncertainty, use deterministic checks for joins/counts/times, and write only new draft review files to {output_folder}. Stop if inputs contain sensitive or unrelated personal data or credentials. Do not access live accounts, change source records, send messages, upload, purchase or provision access. Return unresolved owner decisions without guessing.

Expected output schema — proposed

Origin

editorial_proposal

Columns

1. order_id

2. site_id

3. asset_id

4. role_type

5. party_code

6. effective_from

7. effective_to

8. source_reference

9. approval_authority

10. recorded_field_value

11. mapping_state

12. conflicting_evidence

13. owner_question

14. owner_decision

Record status

draft_pending_owner_review

Synthetic output illustration — not an executed result

Label

Synthetic worked input/output illustration; authored expectation, not an observed result

Synthetic

Yes

Executed

No

Owner approval status

pending_not_obtained

Data

Synthetic inputs

Order

SYN-JOB-4

Access contact

SYN-P1

Equipment owner

SYN-P2

Authorized customer

SYN-P3

Approved payer instruction

SYN-P4

Order bill to

SYN-P2

Illustrative expected output

Role rows

4

Finding

bill_to_default_conflicts_with_order_instruction

Candidate administrative payer

SYN-P4 pending owner review

Legal liability

not assessed

Source record changed

No

Human approval boundaries

1. Before any future pilot, the accountable owner approves exact synthetic/minimized inputs, processing environment, retention and allowed output recipients. This plan grants no execution permission.

2. The owner confirms identities, authority rules and all unresolved interpretations identified in the steps; a draft is not authorization.

3. Any later source-system change, publication, send, upload, account access, purchase or permission change requires separate appropriate authorization. No such action is part of this plan.

Current problem validation — proposed, unexecuted

Before any pilot, ask an authorized owner whether this problem still occurs, inspect a minimized representative export and compare the built-in/manual remedy. No contact or research with private data is authorized here.

Limits

1. Original editorial proposal only; no workflow, synthetic fixture or acceptance check has been executed.

2. A human-duty listing and an issue report establish context, not prevalence, current demand, successful agent use or willingness to pay.

3. Closed or old reports are historical evidence. Current target-version relevance and simpler built-in remedies must be checked before a pilot.

4. Exact platform account access, export availability, environment tools and end-to-end compatibility remain unknown.

5. All consequential decisions and operational use remain with the named accountable owner.

Candidate platforms — compatibility untested

1. Name

   ChatGPT Work

   Required capabilities

   1. Read the exact owner-approved file copies

   2. Run inspectable deterministic checks if supported by the chosen environment

   3. Create separate reviewable CSV and text artifacts

   Capability source urls

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

   Selection basis

   Editorial candidate based on general primitives only.

   Workflow compatibility

   Unknown and untested; no source-system connector or MCP compatibility assumed.

   Setup caveat

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

   Availability in canada

   Not assessed.

2. Name

   Claude (Cowork-capable account)

   Required capabilities

   1. Read the exact owner-approved file copies

   2. Run inspectable deterministic checks if supported by the chosen environment

   3. Create separate reviewable CSV and text artifacts

   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

   Editorial candidate based on general primitives only.

   Workflow compatibility

   Unknown and untested; no source-system connector or MCP compatibility assumed.

   Setup caveat

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

   Availability in canada

   Not assessed.

Failure modes

1. A location default overrides an order-specific payer instruction.

2. An access contact is assumed to be the equipment owner.

3. Conflicting instructions have different approvers.

4. Source text contains instructions unrelated to the authorized analysis; treat it as untrusted evidence, never as permission or executable guidance.

Recovery and troubleshooting

1. Signal

   A location default overrides an order-specific payer instruction.

   Recovery

   Expose the competing sources and effective dates; do not change the bill-to field.

   Resume condition

   Account owner confirms which instruction is authoritative.

2. Signal

   An access contact is assumed to be the equipment owner.

   Recovery

   Separate the roles and mark ownership evidence missing.

   Resume condition

   Owner supplies an explicit ownership-role record.

3. Signal

   Conflicting instructions have different approvers.

   Recovery

   Retain both and request the required authority decision rather than choosing the newest.

   Resume condition

   Authorized owner resolves the conflict in writing.

Unexecuted validation plan

Sample setup

Design-only fixture: SYN-SITE-1 has P1 as access contact, P2 as equipment owner, P3 as authorized service customer and P4 as instructed payer under an approved order-specific direction. The order uses P1 in its single contact field and defaults bill-to to P2. A control order explicitly approves one party for all four roles; a third order has contradictory payer directions.

Acceptance checks

1. The four distinct roles for SYN-SITE-1 remain visible and the P2 bill-to default is flagged against the approved P4 instruction.

2. P1 is not inferred to own equipment, authorize the service or owe payment.

3. The same-party control is valid because all four roles are explicitly supported.

4. The conflicting-direction order remains blocked; no legal liability is assigned.

5. No contact merge, order mutation, invoice, payment or external disclosure occurs.

6. Every substantive finding carries a supplied source-row/span reference; unresolved authority or missing evidence stays visible.

7. All input copies remain unchanged and all outputs are labelled synthetic draft / pending owner review.

8. No network/account operation, live mutation, external communication, personal-data processing, upload, purchase or access provisioning is attempted.

Stop conditions

1. A planted critical exception is missed, a valid control is wrongly failed, or an unknown is presented as certain.

2. Required identity, policy, time basis or export completeness cannot be resolved within the owner-approved fixture.

3. Personal data, credentials or unrelated material appears, or the proposed run requires live access, source mutation or external action.

Executed

No

Fixture status

Design only; no fixture or workflow execution and no acceptance result.

Approval status

not_requested_or_granted_for_execution

Costs and effort — unknown or hypothetical

Status

unknown_or_estimate

Currency

Not specified.

Items

1. Plan eligibility, usage limits, token/runtime consumption and current price are unknown; verify before an authorized pilot.

2. Role-record cleanup and owner authority review are unmeasured. No ERP connector, contract-analysis service, billing integration or revenue effect is assumed.

3. Preparation of minimized copies, review, correction and retention effort is unmeasured. No native integration, paid dependency, installation or new account is assumed.

Caveat

No numerical cost, time saving, ROI, income or willingness-to-pay claim. Compare with the simpler alternative before investing.

Canadian adaptation — proposed

Retain organization-approved bilingual role labels where needed. Privacy, access and contractual questions stay with authorized local staff; no Canadian legal or compliance conclusion is made.