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 eligibility

The pieces that make up eligibility:

Eligibility policy is the rule definition. It carries:

• A name and a description.
• A condition referencing party assignments, form responses, governed facts, and external signals, combined with all/any/not logic.
• Evidence requirements for the conditions.
• A status (draft, active, retired).

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

• The policy.
• The party.
• The purpose and the transition or target being attempted (if applicable).
• The decision (allowed, blocked, waived).
• The blockers, and the evidence and trace snapshots that were evaluated (for audit fidelity).
• The actor and timestamp.

Waiver records an approved exception when a policy blocks or no applicable policy exists. It moves through requested, approved, and revoked, with a reason and a risk-acceptance note.

Readiness caches the latest decision and blockers for a party, purpose, and target, so a surface can show the current posture and whether it needs refreshing.

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 Policies list shows every defined policy with its name, status, and the lifecycle transitions that reference it.

Inside a policy, you see:

• The condition.
• Recent evaluations and their decisions.
• Activity history.

Evaluations are visible per-party from the party’s record and per-policy from the policy’s detail page.

Every change is captured in the workspace Audit Log.

Policy status and evaluation fidelity

A policy moves through draft, active, and retired. You draft a policy, activate it when it should start gating transitions, and retire it when it should stop. Each evaluation records the decision (allowed, blocked, or waived), the blockers, and a snapshot of the evidence and trace that were evaluated.

This matters for audit: when a party transitioned, what did the policy decide, and on what inputs? The evaluation record carries that fidelity, independent of later changes to the policy.

Common workflows

Defining a new policy

1. Eligibility → New policy. Name, description.
2. Draft the condition.
3. Test against existing parties (preview, doesn’t change state).
4. Activate.
5. Reference from lifecycle transitions.

Revising a policy

1. From the policy, edit the condition.
2. Test against existing parties.
3. Save; the next lifecycle transition is evaluated against the updated policy.

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.