Brand-owned edges
Customer ordering channel, POS, and restaurant users. Channel clients obtain Braid-owned item identifiers, screen a basket, and submit fulfillment intent. Real channel integration remains customer-specific work.
Technical follow-up · September 2026
The connections.
The boundaries.
The work still ahead.
Braid coordinates restaurant-owned delivery across ordering, POS, restaurant work, and provider interfaces. This brief separates a functional demonstration from a production operating service.
System shape
Stable product contracts.
Vendor-specific adapters.
Braid core
Eligibility explanation, state transitions, scoped permissions, menu/package approvals, launch dependencies, packing/custody work, care records, and audit. Persistent paths use tenant-scoped PostgreSQL and durable jobs.
Provider edge
Provider-specific requests and reports remain behind adapters. Theoretical provider simulation and Wing offline mapping exercise local contracts. Live Wing transport and provider-native verification are not implemented.
Four kinds of truth remain distinct: POS order/payment, restaurant preparation/approval, Braid coordination, and provider acceptance/outcome. A cancellation request does not erase a later provider report; the persistent lifecycle preserves that report and flags reconciliation.
- The ordering channel asks whether the basket fits the available product policy and approved inputs. Eligibility is not a flight authorization or capacity guarantee.
- After payment in the authoritative system, the channel records fulfillment intent. Braid does not become the payment system.
- The restaurant accepts prep, records packing checks, and approves packed status. Provider request and custody are separate actions.
- Provider reports drive fulfillment state and exceptions. Customer care records what was communicated and how recovery was handled; the record itself does not execute a refund or replacement.
Release-specific capability map
What can be demonstrated—and what that proves.
| Capability | Public demo | Local implementation / remaining boundary |
|---|---|---|
| Menu and package governance | Assortment selection, package review, and eligibility changes. | Shared domain rules and persistent approval paths. No automated source-backed SOP compilation or general upstream-change invalidation guarantee. |
| Customer ordering | Fictional checkout and tracking; sample prices and estimates. | Braid-owned catalog IDs, screening, and fulfillment-intent API. Real checkout, pricing, payment, and customer-channel integration require scoped work. |
| Store execution | Prep, packing evidence, packed approval, handoff, and role perspectives. | Permissioned persistent actions and next-task queue. Actual staff usability and POS/KDS coexistence require customer rehearsal. |
| Provider lifecycle | Offline requests, scripted acceptance/decline/outcome and cancellation rehearsal. | Persistent contract handles delayed/out-of-order reports, cancellation races, and pickup expiry. Controlled local updates are not a live provider-native integration. |
| Customer recovery | Generated case, claim, disposition, communication, evidence reference, and note. | Recorded outcomes preserve attribution. Braid does not execute refunds, replacement orders, or alternate deliveries in this release. |
| Launch readiness | Dependency gates, named owners, and external evidence references. | Activation/resumption checks required gates and current assortment/package state—not a score alone. External completion records are attestations, not independent verification. |
| Square / POS abstraction | Square-shaped fixtures, not a seller connection. | Square adapter, OAuth/sync/webhook paths; normalized snapshot boundary tested with two POS-shaped inputs. That second fixture is not a shipped Toast adapter. |
| Wing | Wing offline contract rehearsal; zero network calls. | No live transport. Current partner documentation, access, mapping review, native update verification, joint testing, and approval still required. No partnership claim. |
| AI assistance | Deterministic inferred suggestions requiring review. | AI adapter path exists. Estimated values need real evidence; neither suggested nor clicked-approved values establish physical measurement. |
| Identity and tenancy | Role switching only; browser state is editable synthetic data. | Local OIDC/PKCE, product grants, revocable sessions, CSRF controls, tenant RLS, and scoped identities. Demo role enforcement is not customer authentication. |
| Jobs, security, operations | Illustrative administration screens and sample metrics. | Durable jobs/retries, credential encryption, audit, runtime checks, and deployment contracts. Managed key custody, hosted telemetry/paging, and exact release-promotion implementation remain production blockers. |
Hosting & data
The public demo is not a customer environment.
Vercel demonstration
Static assets plus a stateless function evaluate browser-carried synthetic state. State is saved in browser storage and submitted for each action. No shared tenant database, production sign-in, paid AI, Square seller connection, or Wing access is enabled.
Do not enter customer or confidential data. Reset discards synthetic work in the current browser; it is not a production privacy workflow.
Separate operating runtime
The local implementation separates web, worker, and migration authority. Tenant-scoped data, identity, credentials, and jobs are different paths from the hosted demo.
Production startup is deliberately blocked until remaining implementation and approval gates are satisfied. Environment variables cannot turn the demo into production.
Local tests establish behavior under the tested conditions. They are not independent security assurance, capacity certification, live provider validation, or customer acceptance. Sample brand metrics are not load-test results or customer performance.
The path to a real pilot
Scope the missing work before estimating the launch.
Implementation work
- Actual customer ordering/POS connection and data mapping.
- Approved provider transport, event verification, and operating semantics.
- Managed key custody, telemetry/paging, release promotion, and selected hosting.
- Measured packaging provenance, change handling, and any customer-specific workflow requirements.
External inputs and acceptance
- Named store, market, provider, sponsor, and operating owners.
- Access, agreements, privacy/security requirements, and support responsibilities.
- Staff procedures, package measurements, and local operating approval.
- Joint success/failure/cancellation testing, recovery rehearsal, and explicit go/no-go criteria.
A useful technical session ends with a system/data map, responsibility boundaries, concrete gaps, and an acceptance plan. It should not end with “just supply credentials” or an unsupported launch date.
Bring the brand's digital/POS owner, operations/menu owner, security representative as needed, and the provider's integration contact. Start with one store and representative orders. Expand only when the next decision needs more breadth.
Return to the product story →