Eligibility

An eligibility rule is a declarative condition that must hold for a party to make a specific lifecycle transition. A vendor can only move from due-diligence to qualified if their financial standing check passed. A buyer can only move to active if KYC is clear. These are eligibility rules.

Rules are reusable. The same financial-standing rule can gate vendor qualification and also gate a higher-trust tier transition later in the relationship. Eligibility is the layer of “what must be true,” separate from “what state we’re in” (that’s the lifecycle).

When you would reach for this

You define eligibility rules when:

• A lifecycle transition should not happen without specific data being true.
• A regulator requires you to demonstrate that certain checks were performed before a party reached a particular status.
• An internal policy needs to be enforced consistently across many parties.
• A rule needs to be evolved (a new condition added, an old condition relaxed) with audit trail of when the change took effect.

You don’t reach for this for one-off decisions; those happen in the lifecycle transition itself with reviewer judgment. Eligibility is for rules that should always be evaluated.

What lives in an eligibility rule

Two record types:

Eligibility rule is the rule definition. It carries:

• A name and a stable key.
• A condition expression referencing party assignments, form responses, governed facts, and external signals.
• A failure message explaining why a party didn’t pass.
• An owner.
• A status (draft, published, retired).
• A version (rules evolve over time; published versions stay frozen).

Evaluation record is the record of one evaluation of one rule against one party at one moment. It carries:

• The rule and rule version.
• The party.
• The transition being attempted (if applicable).
• The result (pass, fail, unknown).
• The inputs that were evaluated (snapshot for audit fidelity).
• The actor and timestamp.

Condition expressions

Conditions are declarative. They reference data the workspace already holds:

• Party assignments: party.assignment.kyc-status == "verified".
• Form responses: party.form.vendor-financial-disclosure.tier >= "B".
• Governed facts: party.fact.daysInProspect > 30.
• External signals: party.signal.sanctions-screen.result == "clear".

Multiple conditions can be combined: condition-A AND condition-B. Rules can also use parametric thresholds set per rule version.

The expression language is bounded — no arbitrary code, no outbound calls, no unrestricted scripting. The bounds are what make eligibility safe to entrust with party-gating decisions.

A worked example: the procurement marketplace’s eligibility rules

Felipe’s marketplace setup defines several reusable eligibility rules.

Rule 1: financial-standing-check. Used by vendor-lifecycle for the due-diligence → qualified transition.

party.assignment.financial-standing.result == "pass"
AND party.assignment.financial-standing.daysAge < 365

The financial standing is an assignment on the vendor party (populated by an integration with a third-party financial-checking provider). The rule says: the result must be “pass,” and the check must be less than a year old.

Rule 2: category-compliance. Used by vendor-lifecycle for the same transition.

party.assignment.product-category.requireRegulated == false
OR party.assignment.product-category.regulatorApprovals.allSatisfied == true

Either the categories are unregulated, or all required regulator approvals are in place.

Rule 3: kyc-clear. Used by buyer-lifecycle for the prospect → kyc-checked transition.

party.assignment.kyc-status.result == "verified"
AND party.assignment.sanctions-screen.result == "clear"

KYC verified plus sanctions-clear.

Rule 4: enhanced-due-diligence-required. Used by the new buyer-lifecycle v2 to route higher-risk buyers to the enhanced state.

party.assignment.kyc-status.riskTier == "high"
OR party.fact.totalRequestedCreditLine > threshold

When the rule passes, the transition routes to enhanced-due-diligence instead of active.

A vendor attempting to move from due-diligence to qualified is evaluated against financial-standing-check AND category-compliance. If either fails, the transition is blocked with the failure message displayed to whoever attempted it.

What you’ll see in the product

Eligibility lives under Governance → Party → Eligibility in the workspace.

The Rules list shows every defined rule with its key, current published version, status, the lifecycle transitions that reference it.

Inside a rule, you see:

• The condition expression.
• Recent evaluations (with pass/fail counts).
• Versions and their status.
• Activity history.

Evaluation records are visible per-party from the party’s record and per-rule from the rule’s detail page.

Every change is captured in the workspace Audit Log.

Versioning

Rules are versioned. A change to a rule’s condition creates a new version. Lifecycle transitions reference a specific rule version (typically “current”); historical evaluations preserve the rule version that was evaluated.

This matters for audit: when a party transitioned, what rule version gated them? The evaluation record carries that fidelity.

Common workflows

Defining a new rule

1. Eligibility → New rule. Name, key, owner.
2. Draft the condition expression.
3. Test against existing parties (preview, doesn’t change state).
4. Publish.
5. Reference from lifecycle transitions.

Revising a rule

1. From the rule, create a new version draft.
2. Adjust the condition.
3. Test against existing parties.
4. Publish; the next lifecycle transition references the new version.

Investigating a blocked transition

1. From the party, look at the most recent evaluation records.
2. The failed rule and its failure message tell the story.
3. Address the underlying data (correct an assignment, request a re-screen, etc.).
4. Re-attempt the transition.

Related

• Overview - the full party governance story.
• Lifecycles - rules gate lifecycle transitions.
• Forms - form responses feed rule inputs.
• Party Types - assignment kinds feed rule inputs.