Donation Specification Call

Donation Specification Call

This is the reusable phone workflow behind The Missing Call, a category-neutral donation matching and fulfilment engine.

Use it when donated goods cannot be matched safely because a required real-world attribute is unknown. Examples include the age range on school supplies, labelled clothing sizes, furniture dimensions, whether goods are packed, available quantities, or whether a required document exists.

The skill asks one authorised contact only the questions currently blocking the match. It returns evidence-linked reported claims for human review. It does not inspect an item, certify its safety, approve an allocation, promise collection, transfer ownership, or prove that a document is genuine.

The governing rule is:

A completed call is not a completed match, and a spoken answer is not an inspection.

When To Use

Use this skill when all of the following are true:

• a donation offer, recipient request, warehouse record, or transport offer has an unknown hard attribute;
• that unknown value prevents deterministic compatibility or bundle assembly;
• the contact has consented to calls for this specific donation-specification purpose;
• the recipient organisation has authorised the question set;
• a human operator can preview the exact call before dispatch.

This workflow is category-neutral. It can ask about any attribute defined in the host application's category schema, including quantities, dimensions, sizes, age ranges, packing state, collection windows, accessory presence, or documentary evidence.

When Not To Use

Do not use it when:

• the phone number is merely present in a CSV, email signature, comment, directory, or public website;
• the contact or recipient organisation has not authorised the call;
• the operator has not reviewed the exact questions;
• the intended result requires physical inspection, legal judgement, safety certification, proof of ownership, medical advice, or regulatory approval;
• a previous attempt has an unknown outcome and has not been reconciled;
• the requested action is to book transport, transfer ownership, purchase goods, or promise an allocation;
• the situation involves an injury, fire, gas leak, electrical danger, or another emergency.

Required Input

The host must provide:

• batch_reference: opaque donation-offer or request reference;
• contact_reference: authorised contact identifier;
• contact_masked: masked display number;
• contact_role: donor, recipient, warehouse, transport, or coordinator role;
• organisation_name: organisation represented on the call;
• authorised_purpose: exactly donation_specification;
• authorisation_version and expiry;
• recipient_organisation_authorised: boolean;
• consent_to_call: boolean;
• subjects: opaque item or batch references with allowed attributes;
• questions: only the unresolved hard attributes, including why each answer matters;
• a closed recipient_result_schema.

Never place personal names, street addresses, pupil details, beneficiary details, or unmasked phone numbers in the task when opaque references are sufficient.

Core Workflow

1. Find the blocking gaps. Run deterministic matching first. Select only unknown hard attributes that prevent a match.
2. Bind the questions. Every question must map to one known subject_reference and one attribute allowed by that subject's category schema.
3. Verify authorisation. Confirm active contact consent, recipient-organisation approval, purpose, question-set hash, and expiry.
4. Reserve idempotency. Derive a stable key from batch_reference + contact_reference + authorisation_version + question_set_hash and persist call intent before dispatch.
5. Preview. Show the masked destination, AI disclosure, purpose, exact questions, result schema, likely side effect, and the fact that no call has yet been placed.
6. Require confirmation. Stop unless the operator explicitly approves this exact preview.
7. Place one call. Send the reviewed task and closed result schema to CALL-E. Store the provider call ID immediately.
8. Reconcile. Poll or process the webhook for that existing call. A timeout means outcome_unknown; reuse the provider ID or idempotency key and never redial blindly.
9. Validate. Reject unknown subjects, unasked attributes, invalid types or units, impossible quantities, and values without a supporting quotation.
10. Store claims. Accepted answers become donor_reported or recipient_reported claims. Conflicting claims remain visible; history is never overwritten.
11. Re-run matching. The host application decides whether the newly reported values remove the gap. Human approval still controls allocation and handoff.

gap -> authorised questions -> preview -> confirm -> one call -> reconcile
    -> validate evidence -> reported claims -> re-run match -> human decision