Venue ownership workflow

Status: Active Last reviewed: 2026-09-06

This workflow governs ownership certification separately from the community contribution pipeline. One reliable source can support a court's information. Ownership certification requires an independent check of the operator's authority. Neither pending claims nor ordinary accepted corrections award 인증됨.

Application and tenure

An active account submits an ownership application for an existing venue with one supporting observation and a note or public reference. The application records its venue baseline and remains pending. Platform staff other than the applicant can accept it with a business-record or published-business-contact check, reject it, or request more information with an explanation. Applicants can withdraw an open application or replace it with a linked revision.

An accepted application creates one venue-scoped tenure and an exact matching venue_admins.claim_id projection. Multiple independently accepted owners can coexist. Neither a user's source count nor their submission history grants staff authority. Five new applications per hour and twenty open applications bound intake; replacing an open application reuses its open slot. Ending a tenure is not blocked by the intake quota.

Operation	Authorization and result
Submit or replace	Active applicant; records evidence and baseline without changing venue facts.
Review	Independent active platform staff; acceptance records the check and creates a tenure.
Transfer consent	The named outgoing tenure holder confirms the exact current proposal revision.
Accept transfer	Independent staff; atomically ends only the named outgoing tenure and starts the new one.
Relinquish	Current owner; ends their exact tenure and removes its projection.
Revoke	Active platform staff; records a reason and ends the exact tenure.
Account departure	Ends that account's tenures and open applications; restoring the account cannot revive them.

Transfer consent alone never transfers ownership. Changed or ended outgoing tenure, replaced evidence, or stale revisions require a fresh valid decision. Other co-owners retain their tenures. Losing the last owner removes certification while preserving the venue, its courts, source observations, closure state and history.

Requests and authorization

Each mutation carries a caller-generated request UUID and its original arguments. An unchanged retry does not repeat the mutation and returns its current authorized receipt; later decisions can therefore appear in that receipt. Lost full-read entitlement denies a full-result replay. Reusing the UUID with different arguments fails. Request checks precede stale-revision and intake-quota checks. Explicit retries must retain the original UUID and payload. Redacted request tombstones prevent UUID reuse without retaining the actor or digest.

Private reads and writes require a current active profile and Auth account. Ordered account, tenure, grant and venue locks bind authority to the actual transaction. A role acquired after capture cannot promote a pending operation into an instant write. Account deletion that conflicts with the established lock order returns a retryable lock error; it does not deadlock or bypass a waiting authorization check.

Existing correction and contribution RPC signatures remain supported. Accepted owners can review facts for their own venue; new venue identities require platform staff. An owner cannot reopen a row closed as merged or not-a-venue through the legacy correction path. No actor may reopen an old row that has a successor; the successor retains its distinct identity. Ordinary reviewed temporary/permanent reopening remains available under the existing lifecycle contract.

Private evidence and public certification

Applicants and authorized platform staff receive full claim receipts. An outgoing owner receives a restricted transfer-consent view, without applicant proof or history. Raw claims, events, request digests and grant rows are unavailable through client table reads. Account anonymization removes personal evidence and historical actor linkage while preserving audit state and the explicit distinction between removed proof and unavailable legacy proof.

get_venue_owner_certifications(uuid[]) accepts one to one hundred distinct venue IDs and returns only each requested ID, its current boolean and one server check time. It is deliberately callable by anon, authenticated and service_role; PUBLIC and raw private reads remain denied. The SQL ACL gate exempts only the exact signature and named anonymous grant, including regressions for PUBLIC and accidental overloads.

The app request foundation binds private reads and writes to the current account and scope generation. Each attempt reads the current session through the auth port, then checks the same identity, expiry and cancellation after waiting for a network slot. Account changes cancel scoped work and clear ownership query and mutation entries. Requests started by an abandoned render cannot replace the committed account lifetime. An explicit session retry can recover from a delayed initial auth event without reactivating old requests.

Ownership queries and certification checks are excluded from persistent query storage. Hydration also verifies the stored query key itself, preventing an unrelated key with the same storage hash from restoring private data. Error feedback uses constant, operation-specific messages; stale scopes cannot emit callbacks with private proof. Mutation receipts must match the original request's venue, UUID and tenure bindings.

The shared application, receipt/history and review screens are mounted at /venue-owner-claims, /venue-owner-claims/new and /venue-owner-claims/[id] on both platforms. Venue detail and contribution history link to this workflow. Form retries retain the original request UUID and payload; changing the application starts a new attempt. Actions and evidence links require the current receipt and account lifetime. Losing full-read permission hides the receipt and its actions until a successful refresh. Transfer applicants can use an exact outgoing-tenure application link; native share-sheet integration is not included.

Certification badges use a transient proof for the exact canonical venue ID. Every badge consumer checks its lifetime; stored directory, search or wizard booleans cannot restore it. Proof expires within sixty seconds of the server check and disappears on failed checks, inactive scope or an affected ownership action. Settlement requires a new check, including when an earlier account's action finishes after an account change. An ordinary reliable venue remains visible without a certification badge.

Directory, search and club/session pickers check visible venues in bounded batches: thirty initial rows, then up to one hundred visible/selected IDs, with one in-flight request and at least one second between new dispatches per observer. Club selections remain uncapped; scrolling advances which courts are checked. Reopening a search overlay or returning to a focused screen recomputes the active viewport.

Ownership signals carry validated claim, venue and event UUIDs. They navigate to a fresh authorized receipt; a notification carries no proof or review authority. Malformed or duplicate route parameters are rejected before private reads.

Account export

export-user-data uses the caller's token and the existing own-profile RPC. It adds venueOwnerClaims with every exhausted own-claim page and every history continuation, retaining raw microsecond cursors and original wire values. It rejects restricted or foreign receipts, unexpected private fields, duplicates and nonadvancing pages. The final authorization read is required before returning any assembled data.

The handler allows 45 seconds overall, at most 10 seconds per call, 64 traversal calls plus a reserved final check, and 84 total dispatches. Responses are bounded before SDK JSON decoding: 2 MiB per successful upstream response, 8 MiB aggregate and final output. Failure aborts outstanding work and returns a constant error without partial data. The legacy authored-post export uses content:body and post_type:type aliases while retaining the own-author filter and existing output keys.

Exhausted pagination is not a shared database snapshot. Concurrent edits can appear at different read times, and the final authorization read is not atomic with JSON serialization. The other fifteen legacy collections remain unpaged; larger-account asynchronous export and complete legacy collection auditing remain separate work.

Verification and rollout

Apply migrations 00621–00628 before deploying the revised export or app consumer. No service-role fallback may manufacture a successful export when owner RPCs are absent. No migration creates a new user claim from community evidence. Historical grant import is one-time and records incomplete originals for investigation without granting authority.

Run yarn check for canonical app contracts, export regressions, strict Edge typechecking and repository gates. With an isolated fully migrated local database, yarn db:test also covers ownership, legacy contributions, stable courts and SQL privileges. The audit records actual execution, independent findings and remaining app/provider/hosted boundaries.