Review and e-sign your venue agreement
Open the tokenised signing link, read the hashed document, sign it, and wait for the counter-signature.
Owned by Host / Promoter · 11 steps · about 20 minutes
Why this exists
The contract is a gate, not a formality, and the mechanism is worth understanding before you press anything.
When an admin locks the contract, the platform renders it canonically — a deterministic HTML rendering with no timestamps and no randomness — and takes the SHA-256 hash of that rendering. From that moment the sections and the variables are frozen by database triggers. The signing link you are emailed carries a token, and the token is your credential: no account, no password, no login. What you sign is recorded against that hash. If the document were altered underneath you, the recomputed hash would not match and signing would be refused with a hash mismatch. That is the guarantee the hash exists to give you, not the venue.
Signing is not the end. Your signature moves the contract to host_signed and it waits for the venue's counter-signature, which only an admin can give. The counter-signature seals the document into immutable stored HTML with a sealed hash, advances the application to contract_deposit, and attempts to flip the linked event from draft to announced.
Attempts, because the event has its own gate and it is checked separately. The seal always succeeds; the flip does not, and a refused flip does not undo anything. An event still missing a required time, or whose booked act has not yet confirmed, stays a draft — the agreement is final and the night is not yet public. Today the only sign of that is on the staff channel, so if your event has not appeared on the public listing shortly after you get the executed email, ask the venue; the usual answer is a confirmation somebody has not sent yet. (This paragraph describes what happens now. Making the refusal visible to you, rather than to a staff channel, is plan/631.)
Built behaviour, differing from the BRD: the seal moves the event draft to announced. There is no contract_pending or approved event status in this platform. Announced means publicly visible — it does not mean on sale. Going on sale is a separate, deliberate admin action afterwards.
Before you start
- An approved application of yours with a drafted contract.
- The signing link from the 'ready to sign' email (or a freshly resent one).
- An admin to lock the document beforehand and to counter-sign afterwards.
Practise with
| Persona | Password | Note | |
|---|---|---|---|
| host_promoter | host@club.test | host123 | owns the seeded 'Neon Circuit Gala' application and its draft contract |
| admin | admin@club.test | admin123 | the only persona that can lock and counter-sign |
| venue_manager | manager@club.test | manager123 | can read the contract and its redlines, and nothing else |
Steps 1–2 — Admin
their manual →Locks and hashes the document, then counter-signs on behalf of the venue.
-
1Open the drafted contract, check the auto-injected riders against the promoter's flags, and fill every variable: headcount, ticket price and event date.Expected result A section-by-section editor. Variables render inline in blue, and every edit you make is recorded as an append-only redline.Watch out for A blank variable blocks the lock. That is the intended failure — an unpriced agreement must never reach a signature.
-
2Lock the contract.Expected result The document is canonically rendered and SHA-256 hashed, a signing token is minted, and the signing link is emailed to the host.Watch out for 422 comes back with a reasons list, for example an empty event_date variable. Locking freezes the wording: if it is wrong, unlock (only possible while unsigned) or void and supersede — do not try to edit around it.
Steps 3–4 — Venue Manager
their manual →Reads the agreement and its redline history, but may never lock or sign it.
-
3As the venue manager, open the contracts list and find the locked agreement.Expected result The contract with its status, plus any approved applications that still have no paperwork.Watch out for You can read this list, but the lock, void, resend and counter-sign controls are not yours — the page renders read-only for you.
-
4Read the redline history to see exactly what the venue changed from the master template before locking.Expected result An append-only list of edits with word-level diffs.Watch out for Redlines cannot be edited or deleted by anyone — the tables carry both UPDATE and DELETE triggers.
Steps 5–7 — Host / Promoter
their manual →-
5Open the signing link from your email and read the whole agreement — your rider clauses and your numbers are in it.Expected result The full document exactly as it was locked, with a signature pad below it.Watch out for An expired link renders 'Link expired' with a 410; a revised agreement renders 'Agreement revised' with a 410 because the old contract was voided and a fresh draft supersedes it. In both cases ask the venue to resend rather than hunting for another route in. /contracts/sign/{token} redirects here, so both forms of the link work.
-
6Sign: either draw your signature on the pad or switch to the Type tab and type your full legal name, then tick the consent box and press Sign Agreement.Expected result Your signature is stored against the locked hash together with your IP address and browser user agent, and the contract moves to host_signed.Watch out for The button stays disabled until you have both consented and produced a signature. Refusals you may see: 422 consent_required, 409 already_signed, 409 not_locked, and 409 hash_mismatch — the last one means the document drifted from what was hashed and is a stop-everything signal, not a retry.
-
7Check where the agreement stands without pestering anyone.Expected result The contract status plus two booleans: signed, and sealed.Watch out for signed true and sealed false is the normal in-between state — you have signed and the venue has not counter-signed yet. Reloading the signing page in that state shows a plain 'awaiting venue counter-signature' message, which is not an error.
Steps 8 — Admin
their manual →Locks and hashes the document, then counter-signs on behalf of the venue.
-
8Counter-sign on behalf of the venue.Expected result Status executed with a sealed hash, and the response reports event_flipped and application_advanced. In the same transaction the event goes draft to announced and the application moves to contract_deposit.Watch out for 409 host_must_sign_first if you jump the queue, 409 already_executed on a replay. Executed rows are immutable at the database level — a trigger refuses any UPDATE, even from the admin data suite.
Steps 9–11 — Host / Promoter
their manual →-
9Reopen your original signing link.Expected result The same URL now serves the sealed, executed document — your permanent copy.Watch out for The stored sealed HTML never changes again. A preview of an unexecuted contract is watermarked; the sealed document is not, because there is nothing provisional left about it.
-
10Once you have your host login, fetch the sealed copy from inside the app instead of from the email link.Expected result The same sealed HTML document.Watch out for This needs a session and the platform must recognise you: it lets you through if you hold the host grant for the event, or if the application's host or applicant is you, or simply if your account email matches the application's email. It is 404 not_executed until the counter-signature lands.
-
11Look at your event on the public catalogue.Expected result It is visible — the seal announced it.Watch out for Announced is not on sale. Nobody can buy yet, and no amount of refreshing changes that; putting inventory on sale is a separate admin decision.