Check site coverage before handing off a shared contract

Setup requirements

1. The contract owner supplies the authoritative signed scope and identifies which later messages count as approved schedule revisions. The agent does not decide contract interpretation or acceptance.

2. Use stable site tokens and explicit contract-version IDs. A contact shared across locations does not make the sites interchangeable.

3. Before any pilot, confirm an actual unresolved need and approve minimized copies, processing environment, retention and recipients. This design does not authorize execution.

Inputs and access

1. Name

   contract_site_schedule.txt

   Source or owner

   Commercial contract owner

   Scope

   Synthetic executed-version identifier, site tokens, agreed units, planned dates and explicit future-hold conditions.

   Sensitivity

   Synthetic fixture only. Real commercial, personal, location or financial records need approved minimization and handling. No credentials are required.

   Permission needed

   Specific owner approval before any real-data pilot; no live access, uploads or external transmission authorized.

2. Name

   location_deals.csv

   Source or owner

   Sales operations owner

   Scope

   Separate deal IDs, contract references, site IDs, quantities, operational owners and allocation states.

   Sensitivity

   Synthetic fixture only. Real commercial, personal, location or financial records need approved minimization and handling. No credentials are required.

   Permission needed

   Specific owner approval before any real-data pilot; no live access, uploads or external transmission authorized.

3. Name

   approved_schedule_changes.txt

   Source or owner

   Implementation owner

   Scope

   Authorized site-level scheduling changes with effective time and source reference.

   Sensitivity

   Synthetic fixture only. Real commercial, personal, location or financial records need approved minimization and handling. No credentials are required.

   Permission needed

   Specific owner approval before any real-data pilot; no live access, uploads or external transmission authorized.

4. Name

   allocation_snapshot.csv

   Source or owner

   Operations planner

   Scope

   Planned deployment IDs, site IDs, quantities and start dates at the same snapshot time.

   Sensitivity

   Synthetic fixture only. Real commercial, personal, location or financial records need approved minimization and handling. No credentials are required.

   Permission needed

   Specific owner approval before any real-data pilot; no live access, uploads or external transmission authorized.

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

One signed agreement can cover several location deals whose start dates and allocation states must remain separate.

Suggested task

Reconcile the signed site schedule and authorized rollout revisions with location-level deal and allocation copies, preserving each site’s coverage and hold status.

What you could produce

A contract-to-site coverage matrix showing missing, duplicated, extra and date-conflicting handoff rows, plus an owner-reviewed rollout summary.

Why an agent / simpler alternative

Mixed narrative and structured evidence can benefit from assisted extraction and explanation. Identity joins, interval calculations and totals require deterministic checks. A supported native report, query or spreadsheet is preferable when it answers the owner’s question reliably.

When this work comes up

Role

Sales-to-implementation coordinator

Trigger

A multi-location contract is signed or its deployment schedule changes.

Human approval

Owner approves scope, rules and evidence interpretation. Any operational action requires separate appropriate authorization.

Finished output

A contract-to-site coverage matrix showing missing, duplicated, extra and date-conflicting handoff rows, plus an owner-reviewed rollout summary.

Proposed evaluation scope — no pilot authorized

Scope

One synthetic contract, up to eight sites, 20 deal/allocation records and five explicit schedule revisions.

Limit origin

Editorial evaluation bound, not a verified platform limit.

Overflow action

Stop and ask for approved partitioning; no silent truncation.

Pilot authorized

No

Evidence boundary

Firsthand reports establish stated friction or concerns only. O*NET provides duty context. Official documents establish limited native features or general primitives. This workflow, safeguards, fixtures and outputs are original proposals, not source-documented executions.

Proposed steps

1. 1

   Freeze the signed scope, change cut-off and three operational snapshots; identify absent schedules before interpreting coverage.

   Output: contract_handoff_manifest.json

   Expected output: contract_handoff_manifest.json

   Checkpoint: A deal marked won is not substituted for a supplied signed scope.

   Approval gate: Owner approves exact scope, copies and rule definitions before any pilot.

2. 2

   Extract one site obligation per explicit contract schedule line and layer only owner-approved date revisions over that baseline.

   Output: effective_site_obligations.csv

   Expected output: effective_site_obligations.csv

   Checkpoint: Keep the original date, revised date and authority reference; do not overwrite the chain.

   Approval gate: Owner resolves ambiguous source language and evidence authority.

3. 3

   Match sites to deal and allocation IDs using the approved identity map; retain multiple deals at the same site as separate candidates.

   Output: site_record_links.csv

   Expected output: site_record_links.csv

   Checkpoint: Shared contacts, similar addresses and matching amounts do not silently merge sites.

   Approval gate: Owner approves identity mappings and unresolved joins.

4. 4

   Compare expected sites and quantities with operational coverage, separating future-held sites from currently allocatable ones.

   Output: site_coverage_matrix.csv

   Expected output: site_coverage_matrix.csv

   Checkpoint: Future hold does not mean missing contract coverage, and signed status does not mean deployment is ready.

   Approval gate: Owner validates the rule and calculations; no live decision is implied.

5. 5

   Flag missing, extra, duplicated and conflicting site records; calculate counts and quantities by contract version and rollout cohort.

   Output: site_handoff_exceptions.json

   Expected output: site_handoff_exceptions.json

   Checkpoint: Do not net an extra site against a missing site or use equal totals to conceal wrong identities.

   Approval gate: Owner reviews exceptions and accepts unresolved status where evidence is insufficient.

6. 6

   Package the site matrix and reviewer questions into an internal draft handoff summary with explicit unapproved decisions.

   Output: contract_site_handoff_review.json

   Expected output: contract_site_handoff_review.json

   Checkpoint: No customer email, allocation commitment, shipment, quote or CRM status is created.

   Approval gate: Owner accepts the separate draft artifact; all live actions require separate authorization.

Original starter prompt — proposed

Origin

editorial_proposal

Execution authorized

No

Text

Using only {approved_synthetic_inputs} and {owner_rules}, Reconcile the signed site schedule and authorized rollout revisions with location-level deal and allocation copies, preserving each site’s coverage and hold status. Follow the six-step design. Preserve exact identities, evidence spans, explicit policy boundaries and uncertainty. Use inspectable deterministic comparisons. Write only separate draft review artifacts described by the output schema. Stop for missing authority, ambiguous evidence or out-of-scope data. Do not change source records, contact anyone, access live accounts, upload files, post transactions or execute any recovery action.

Expected output schema — proposed

Primary key

1. contract_id

2. contract_version

3. site_id

Columns

1. contract_id

2. contract_version

3. site_id

4. signed_units

5. effective_start

6. hold_basis

7. deal_ids

8. allocation_ids

9. coverage_status

10. date_conflict

11. approval_reference

12. reviewer_decision

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 values remain null, not zero. Keep raw identities and evidence. 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

Contract

C1-v1

Sites

1. Id

   S1

   Units

   2

   Start

   2026-10-20

   Hold

   No

2. Id

   S2

   Units

   1

   Start

   2027-01-15

   Hold

   Yes

Deals

1. Id

   D1

   Site

   S1

2. Id

   D2

   Site

   S1

3. Id

   D3

   Site

   S3

Allocations

1. Id

   A1

   Site

   S1

   Units

   2

   Start

   2026-10-22

Approved date changes

Not specified.

Expected

Expected site count

2

Expected unit count

3

S1

1. duplicate_deal_coverage

2. unapproved_date_difference

S2

1. future_hold

2. missing_location_deal

S3

1. extra_uncontracted_site

Ready without review count

0

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. Read supplied text and files, compare evidence and calculate transparent checks in an owner-approved environment.

   Capability source urls

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

   Workflow compatibility

   Untested. Requires an owner-approved file-processing environment; no CRM, ERP, payment or transport connector is assumed.

Failure modes

1. Different site names may denote the same location but no approved mapping exists.

2. A sales note changes a deployment date without an identifiable approval.

3. A contract contains optional or conditional sites.

Recovery and troubleshooting

1. Signal

   Different site names may denote the same location but no approved mapping exists.

   Recovery

   Keep both identities unresolved and request a site crosswalk from the owner.

   Resume condition

   The accountable owner supplies authoritative evidence or an explicit rule; otherwise retain the affected row as unresolved.

2. Signal

   A sales note changes a deployment date without an identifiable approval.

   Recovery

   Retain the signed date and show the requested change separately as unapproved.

   Resume condition

   The accountable owner supplies authoritative evidence or an explicit rule; otherwise retain the affected row as unresolved.

3. Signal

   A contract contains optional or conditional sites.

   Recovery

   Require the owner to mark inclusion conditions; do not count an option as committed coverage.

   Resume condition

   The accountable owner supplies authoritative evidence or an explicit rule; otherwise retain the affected row as unresolved.

Unexecuted validation plan

Sample setup

Contract

C1-v1

Sites

1. Id

   S1

   Units

   2

   Start

   2026-10-20

   Hold

   No

2. Id

   S2

   Units

   1

   Start

   2027-01-15

   Hold

   Yes

Deals

1. Id

   D1

   Site

   S1

2. Id

   D2

   Site

   S1

3. Id

   D3

   Site

   S3

Allocations

1. Id

   A1

   Site

   S1

   Units

   2

   Start

   2026-10-22

Approved date changes

Not specified.

Acceptance checks

1. S1 and S2 are not collapsed because they share contract C1.

2. D1 and D2 remain two records and a duplicate-coverage question.

3. S3 cannot offset missing S2 in the count.

4. No revised start date is called approved without change evidence.

5. Every conclusion traces to a source row or explicitly labelled owner rule; identical frozen inputs preserve identities and deterministic totals.

6. All source copies remain unchanged; no business workflow or synthetic acceptance evaluation has been run.

Stop conditions

1. Required identity, source coverage, calculation policy or owner authority is missing.

2. Unexpected real sensitive data is supplied without approved handling.

3. Requested work would require live access, upload, external communication, accounting posting, payment, permission change or irreversible action.

Executed

No

Fixture status

Designed specification and separately authored answer key only. No model run, numerical acceptance execution or customer pilot performed.

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.

5. The case requires owner preparation of 4 input groups and review of 6 intermediate/final artifacts. Costs and effort remain unmeasured; these are design counts, not runtime estimates.

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.