ADR-0050 independent local authorization proof and remaining runtime gates
The accepted contract bundle merged through coordination PR #1 at b3a3afb8932298e76b7da728988226e0f054b587. Platform has now executed independent authorization and read-only checks against real Revenue and Delivery handlers in isolated synthetic databases. These checks establish the tested local route behavior. Successful financial mutations, full composed closure and production activation remain separate gates.
Independently observed results
Platform evidence is committed on the isolated codex/adr0050-auth candidate at 5416d68b724b97af0e73865919a3115ed2dba956. Its test issuers use ephemeral local keys and the existing closure capability policies. They do not establish production workload exchange or deployed authentication.
| Producer source | Executed evidence | Persistent-state observation |
|---|---|---|
Revenue 5f10755c031897b6598a051f915c6864ee0901e1 |
38 passing executions: 30 initial meaningful cases, four nested abort/proof rechecks, four corrected-issuer checks including two repeated positive baselines | All 52 inventoried tables unchanged across the denial and GET snapshots |
Delivery be8be31552787fa26ac5589319271b22632ecaa7, followed by b5ea639d148f34013c0192d075d05364372d5271 for the explicit issuer switch |
49 passing exact-code/read cases, followed by eight corrected-issuer executions including three repeated positive baselines | All 57 inventoried tables unchanged across the denial and GET snapshots |
Evidence files in that Platform candidate are docs/adr0050-revenue-auth-checkpoint.json, docs/adr0050-revenue-nested-route-proof.json, docs/adr0050-revenue-tenant-proof.json, docs/adr0050-delivery-auth-rerun.json and docs/adr0050-delivery-tenant-proof.json. The first checkpoint retains its earlier limitations; the subsequent reports resolve the named nested-route and corrected-tenant cases. Counts are executions, including explicitly identified repeated baselines, not unique contract requirements.
The independent verifier found Delivery returned lower-case auth codes despite correct denial statuses. The owner corrected only the additive 1.1 mapping and strengthened its own status-only harness. Platform reran the exact canonical-code cases successfully. Revenue's initially missing nested routes were a local Windows watcher problem; polling restored the routes and the actual handlers were rechecked. An earlier wrong-tenant control had an invalid audit identifier, so it was excluded and replaced with a valid signed control on a separately coordinated issuer.
The databases were revenue_adr0050_auth_d3ac01e38c188e88 and adr0050_delivery_47c75dec242949108457a73d699f5c4c. The owner-approved fixtures use restricted runtime roles and synthetic identities. Snapshot equality proves observed table state at the sampled boundaries; it does not establish unobserved provider effects or concurrency safety. No successful financial command was sent by this auth verifier.
Implementation review and integration work
Coordinator source review identified and routed two additional defects to their owners: Sales' initial journal revision guard accepted omitted/null revisions, and Delivery's standalone adapter called Prisma driver release callbacks without explicitly issuing SQL COMMIT/ROLLBACK. Owners corrected those paths. Delivery's separate restricted-role proof demonstrated fresh-connection commit/rollback visibility and pool cleanup; Sales' database proof exercised revision omission/null/rewind/fraction and journal deletion rejection. These local results do not certify complete writer coverage in production.
The pinned Platform dispatcher reads dispatcher_event and writes cursor, dedup and dead-letter bookkeeping. Event INSERT remains a producer SDK transaction. Revenue and Delivery confirmed bookkeeping is outside their protected financial/outbox set. No new dispatcher epoch adapter is justified by the inspected paths; an actual restricted-role bookkeeping execution remains outstanding.
Owners are running a separate common invoice-correlated fixture through the real Sales, Revenue and Delivery implementation. Revenue has generated cancellation receipts through its actual service and SDK using a strictly in-process provider double, with no Square network call. That fixture is distinct from the stable auth databases. Its receipts are preparation evidence, not a completed composed closure or provider-sandbox proof.
Sales is also implementing an internal durable soft-hold request/response journal on a separate candidate. Recovery must reuse the saved request and key, and unresolved admission must keep closure pending. A reservation with no canonical order/lead provenance remains a separate fail-closed case; no synthetic production linkage or new cross-domain ownership rule has been approved to bypass it.
Gates retained
Remaining evidence includes historical graph validation/quarantine, complete writer and privilege coverage, mixed-version admission and transitive successor cases, every required crash/recovery boundary, actual bind/financial races, and the composed transition to exactly one final Lost event after every linked obligation clears. Existing v1 envelopes and narrow safe replacement remain compatible; ADR-0050 starts no deprecation clock.
ADR-0049 owns shared production target, migration and deployment sequencing. Its pre-lineage candidates remain separate from these new lineage candidates. New lineage activation requires its own epoch, graph, worker/provider drain and rollback evidence. The user's scoped authorization allows necessary production changes and mutations, but does not substitute for failed technical prerequisites.
The coordinator refreshed the live ledger and Platform inbox for this checkpoint. No implementation or production commitment is marked completed by this FYI memo. Each domain retains ownership of its source changes, commitments and final release evidence.