-
-
Offline synthetic fixture: 900 kg reported capacity against a 1,100 kg pallet. No telephone call occurred.
-
Actual official-hotline result: completed call, incomplete receiving questionnaire. This was a fictional test, not a warehouse.
Inspiration
“We accept deliveries” does not tell a dispatcher whether a receiving site has the equipment, access and people for a particular heavy pallet. DockBrief focuses on that missing-information problem: make the receiving conversation inspectable, with the reported fact and the question still needing an answer.
What it does
The operator enters a pallet’s gross weight, external width and height, unloading mode and one authorized receiving contact. A no-network preview shows the task. An explicitly confirmed live run uses CALL-E to ask receiving questions and return structured answers.
DockBrief produces a printable brief. A reported forklift capacity below the pallet weight is a reported blocker. Missing, approximate, qualified, conflicting or unsupported statements remain unconfirmed. Each accepted fact cites a recipient-side transcript turn. A finished call does not automatically clear the checklist.
The report supports human review. It never approves dispatch, certifies safe unloading, schedules a delivery or commits either party. Equipment configuration, load center, clearance margins and actual site conditions require independent verification by qualified personnel.
How it was built
The local TypeScript CLI uses the published CALL-E SDK 0.7.0, recipient result schemas and checks over the returned recipient transcript. It saves the original request and idempotency key before creation, then saves the returned call ID. Resume retrieves that call with GET only. An uncertain creation response stays available for explicit same-key reconciliation rather than automatic redial.
The same SDK runs reproducible no-call examples through an in-process fixture transport. HTML and Markdown reports distinguish synthetic examples from provider results.
What was learned
Call lifecycle, provider task completion and usable domain evidence are separate questions. Our actual test reached CALL-E's official integration hotline on September 11, 2026. CALL-E returned completed and taskCompleted: true, while the custom questionnaireOutcome was incomplete: the hotline had no forklift or doorway measurements and ended the questionnaire. DockBrief kept all five required checks unknown. A completed telephone connection became evidence of missing information, not an invented successful receiving assessment.
An answer can also contain the desired words while qualifying or contradicting them. DockBrief deliberately accepts a narrow set of explicit English and Spanish statements; unfamiliar wording stays unresolved. Numerical comparisons describe reported facts, not a complete unloading plan. The SDK's user role denotes the receiving side, not proof that a human answered; reports use “recipient” accordingly.
Verification and current limitations
Build and 20 offline tests pass, covering SDK serialization, duplicate prevention, same-key replay, GET-only resume, mismatched recipients, units, clipped/contradictory evidence, phone masking and HTML escaping. A separate bounded code review and browser inspection of the report were completed.
One real integration call completed to the organizer's official US test hotline: call ID call_GkF-eB8CYO4AxyLUEGqFXg, telephone attempt September 11, 2026, 21:32:44–21:34:14 UTC (16:32:44–16:34:14 Bogotá). The requested questionnaire remained incomplete and the report displayed “Needs confirmation,” with zero supported facts among its five required checks. The hotline said, “I don't have that information.” This was a fictional shipment questionnaire to a test hotline, not a customer, warehouse or equipment operator. Official test-destination announcement.
Sanitized timestamps, actual short transcript excerpts and scope are documented in docs/live-test.md. Private run state and credentials are not published. The three local scenarios are synthetic and explicitly labeled; they do not imply a successful customer questionnaire. No users, measured savings, production reliability or general-purpose language accuracy are claimed. The demo distinguishes the actual incomplete hotline result from offline comparison scenarios.
Built with AI coding assistance, automated tests and independent review.
Log in or sign up for Devpost to join the conversation.