Real applications through a taken Durable Object

DRQ can dispatch an application request through a taken object to a fixed private Worker binding. The deployed example is ASIC: its application code and service bindings are on main. Its separate delivery record records publication and production acceptance; the presence of this route does not mean its datasets are published.

Authenticated AU entry
  → taken ResidentObject: check activation and stored assignment
  → fixed application Worker: check its own execution
  → application's verified R2 or D1 binding

The reusable interface is createResidentJobs, exported from @comms-id/data-residency/cloudflare/workers. Its applications map fixes each consumer and handler at deployment. dispatch(applicationId, name, request, credential) authenticates, checks the locally confirmed grant and cancellation, then invokes that handler once. Only fixed host methods choose the application ID; it is never caller-selected request data. The local grant is checked again before returning the reply. Request bodies and replies are neither retained nor put in the synthetic job queue.

Existing separate-Worker route (ASIC)

1. Take one existing DO for the application's team, stack, binding and required city. Retain the returned item name and request identity. Consumption has no replenishment step.
2. Add a fixed private service binding and host method to the existing resident host and pool stack, following ASIC's route. Configure applications.<id>.consumer to match that taken assignment exactly and applications.<id>.fetch to call the fixed binding. This is a reviewed deployment change; preserve existing consumer bindings. Check each application’s delivery record for deployed acceptance. Creating another namespace or merely importing the adapter does not connect an application to existing pool stock.
3. In the application entry, authenticate and check Australian ingress and execution before reading protected input. Select the taken object with the existing namespace's idFromName(item.name). Invoke the configured host method with the existing pool credential; callers never supply a callback, destination binding or grant.
4. In the private application Worker, use requireResident() before input processing and storage access. Use the service configuration rules for the actual R2/D1 bindings and disable protected logging. A service binding does not inherit the DO's execution city.
5. Deploy through the existing gate. Refresh that object's local assignment once through its authenticated refresh(name, credential) method before first use. The existing host alarm refreshes routing separately from requests.

For example, from the comms-id/drq checkout, take an existing Sydney object:

RESIDENCY_CONSUMER_TOKEN="$(/Users/MN/bin/comms-id-secret RESIDENCY_CONSUMER_TOKEN)" pnpm quarantine take --kind do --city SYD --request-id example-worker-query-001 --team example-team --stack example-worker --binding QUERY

Use a unique request ID for a new intent and the same ID after interruption. Credentials follow the consumer guide. Application deployment retains its normal deployment access. No Cloudflare provisioning credential is needed to take stock.

The complete working wiring is in ASIC's Worker entry and private handler, assignment and deployment. Preserve those production assignments when adding another application.

Recovery and limits

Application writes need an application-owned idempotency key and outcome lookup before retrying an unknown result. DRQ supplies admission, not exactly-once application effects, durable application payloads or transaction recovery for another Worker. Revocation stops later dispatch; it cannot recall an already forwarded request.

The existing /work client still accepts only fixed synthetic jobs. This request-dispatch interface is separate from native Queues, Workflows and a general durable job system. Dispatch recovery tests exercise DRQ's integration without treating them as proof of Cloudflare's placement guarantees.

ABN and DFAT: application execution inside the object

ABN follows ADR-0038: its fixed handler executes inside the assigned object rather than forwarding to a private Worker. The host composition supplies the object-bound R2 client and request lifetime. DRQ activation and background assignment refresh provide admission; ABN makes no per-lookup location probe. Its entry supplies only private server release configuration, never a caller-selected handler or destination. DFAT follows the same boundary under ADR-0039, including source refresh, parsing, publication and screening with its own verified R2 binding. Neither application adds per-request location probes. ASIC still follows the separate-Worker procedure above. New consumers should use fixed in-object handlers when their processing must remain on assigned compute.

Address: application and producer admission

Address follows ADR-0040. Its fixed handler uses the assigned object and native R2 bucket; consumer requests perform no ledger read or location probe. The entry preserves the owner-approved best-effort ingress boundary, hostname and IAS capability contract. The object checks dataset bytes against the completion digest.

The same host exposes the fixed, authenticated address producer, with start-before-download and completion-before-promotion controls. Read the release procedure. When deploying the shared host, supply RESIDENT_BUILD_COMMIT as the full clean source revision; it identifies the authority in new receipts. Preserve all existing bindings and the physical ResidentObject class and namespace.