Requirements
Conditions an entry or person must satisfy before a gate, what is checked today, and how inheritance works
A Requirement is a condition you attach to a gate: complete your profile, verify an email on your domain, hold an active affiliation, or sign in through your organization. Ulsav checks it on the server, not in the browser. This page covers the kinds that work today, where they attach, and what a buyer sees when one is unmet.
Attaches to
Organization down to Pass
Inherits downward, never negates
Gates
Four
Selection, payment, issuance, check-in
Enforcement
Hard or soft
Soft never blocks
Kinds
Six stored
Four are evaluated today
Decided by
One server evaluator
Re-checked
At the door
A lapsed affiliation blocks entry
The six kinds
| Kind | Satisfied when | Evaluated today? |
|---|---|---|
| Identity completeness | The Account has a verified email and a verified phone | Yes |
| Verified email | The Account holds a verified email, optionally on listed domains | Yes |
| Verified phone | The Account holds a verified phone | Yes |
| Affiliation | An unexpired eligibility claim matches a provider, domain, or claim | Yes |
| Form | The named form is submitted | No |
| Consent | The named document version is accepted | No |
The last two can be saved as definitions, but the evaluator returns "unknown" for them. A hard Form or Consent Requirement therefore blocks every gate it is attached to, because unknown is treated as a blocker.
Do not use Form or Consent Requirements yet
Collect form answers through the Event's form fields. A Form or Consent Requirement does not check the answer; it blocks. Use only the four evaluated kinds until the others report a real state.
Who the condition applies to
| Subject | Whose condition it is |
|---|---|
| Buyer | The purchasing Account |
| Participant | One Participant's linked Account |
| Every participant | Every current place in the entry |
| Registration | A property of the entry itself |
Two limits are worth knowing before you configure one.
- At checkout, Ulsav evaluates the buyer's Account for buyer, participant, and every-participant subjects. Unnamed places have no Account to check.
- The Registration subject has no Account to read, so it returns unknown. A hard Registration Requirement blocks checkout.
Because the buyer is often not the attendee, an audience gate should be authored as every participant and will still be checked against whoever is attached at the gate. The safest design is to require sign-in before checkout and confirm the person at the door.
The four gates
| Gate | What the buyer sees | Typical use |
|---|---|---|
| At selection | The Pass is locked and cannot be added | Audience-only Passes |
| Before payment | The entry exists, but checkout is refused | Sign-in or profile completeness |
| Before issuance | Paid, but no credential yet | Post-payment checks |
| Before check-in | The ticket is valid, the door refuses | Affiliation valid on the day |
The organizer screens label the third gate "Before issuance"; its stored value is BEFORE_ACTIVATION.
A check-in gate does not cancel the purchase. The person still holds a valid Pass; they just cannot enter until the condition is true. That is why an expired affiliation is a door problem, not a refund.
Hard and soft
A hard Requirement blocks its gate. The buyer gets the Requirement's guidance text, which is the sentence you write in "What's needed". Always write it as an action: "Sign in with your college account."
A soft Requirement never blocks. It records that the condition is unmet and can be shown as a nudge.
Ulsav adds its own soft identity-completeness nudge to every chain. You cannot make the platform's nudge hard. If you want completeness to block, create your own hard Requirement.
Where they attach, and how they combine
A Requirement belongs to one scope:
- Organization
- Event group series
- Event group
- Event series
- Event
- Pass
For a given Event and Pass, Ulsav walks the whole chain and collects every active Requirement whose scope appears in it. Inheritance is additive only. There is no "except this Pass" rule, so you restrict access by adding a Requirement, never by subtracting one.
Editing has one sharp edge: the scope and kind cannot be changed in place. Saving an edit archives the old definition and creates a new one. The old version stays in the record of what was decided under it.
What the buyer experiences
The evaluator returns one of three states for each applicable Requirement:
| State | Meaning | Hard gate result |
|---|---|---|
| Satisfied | The condition is met, with the artifact named | Passes |
| Unsatisfied | The condition is not met | Blocked |
| Unknown | Ulsav could not decide | Blocked |
For an affiliation, "unknown" is common when the Account has no link to your organization, so no claim can be read. The buyer sees your guidance, not a technical error.
Guidance is the only explanation
Write the guidance as the instruction, because that is the text returned to the buyer. A blank guidance falls back to the internal kind name, which is not useful at a door.
Snapshots and freshness
When a Registration checks out, Ulsav snapshots the Requirement versions it was evaluated under and the artifacts that satisfied them. Later edits to a Requirement cannot retroactively invalidate a completed purchase.
Check-in is different. The door re-evaluates the current state at the scan. If an affiliation expired, or the Account was unlinked, admission is refused even though the purchase is valid.
Common setups
Students only, by domain. Add a verified-email Requirement with allowed domains at selection or before payment. The buyer must hold a verified email on one of those domains.
Members only, by provider. Add an affiliation Requirement with an identity provider. The buyer signs in through that provider, and the eligibility claim satisfies the gate.
Profile complete before paying. Add an identity-completeness Requirement before payment. The buyer needs both a verified email and a verified phone.
Check eligibility at the door. Add an affiliation Requirement before check-in. The Pass stays issued; the scan refuses when the claim has lapsed.
Failure paths
- A buyer with no Account cannot satisfy a participant or every-participant gate. Ask them to sign in first, or the gate returns unknown.
- An unclaimed Participant has no Account to check at the door, so a hard check-in Requirement refuses them until they claim the place.
- An expired eligibility is skipped during evaluation, so it counts as unsatisfied.
- A Requirement archived mid-flight disappears from new checks but stays in old snapshots.
- A hard Form or Consent Requirement blocks every gate and cannot be satisfied by filling the form.
Related
- Registrations — the entry a gate protects
- Approvals — the review gate
- Check-in — where freshness is enforced at the door
- Members — who may configure a Requirement