Verify an eligibility or entitlement fact without sharing the full record

Use this pattern when a programme needs to confirm a yes/no eligibility fact against another ministry’s registry, without receiving the underlying case file, income tier, or family composition.

Starting situation

A social-protection authority operates a household enrollment registry for a national cash-transfer programme. A school-feeding programme run by a separate ministry needs to confirm, before enrolling a child for free meals, that the child’s household is registered in the cash-transfer programme. The school-feeding programme needs a yes/no answer against a household identifier. It does not need the household case file, income tier, family composition, or transfer history.

What you set up

Configure a Registry Notary claim for the enrolled-household fact. The claim definition names the source binding (the enrollment registry table), the rule (an active enrollment exists for the household identifier), the disclosure mode (predicate: true/false), and the issuer identifier.

Registry Manifest can publish service, requirement, and evidence metadata that describes what facts a consumer may request. A consumer reads the evidence offering document to understand the subject identifier format, the claim scope, and the issuer before making runtime calls.

Registry Lab demonstrates a wallet-facing issuance flow that fits this pattern, but a wallet is not required. The evaluation endpoint works without a wallet-based credential flow when the relying service calls Notary directly.

What a caller does

The school-feeding workflow sends an authorized request to the Notary evaluation endpoint, passing the household identifier as the subject and naming the enrolled-household claim.

For a credential flow, the head of household receives an SD-JWT VC. They present only the enrolled-household disclosure to the school-feeding programme, keeping income tier, family composition, and transfer history in the unselected credential attributes.

What the caller gets back

A signed evaluation containing: the subject identifier, the predicate result (enrolled: true or false), the evaluation timestamp, and the issuer identifier.

The household case file, income tier, family composition, transfer history, and internal registry notes do not appear in the response.

Cross-programme eligibility decisions remain a policy responsibility of the issuing and relying ministries; the signed evaluation gives them an auditable answer to work from.

The same Notary predicate pattern fits a status-coded registry; see Verify a status fact about a registered entity without sharing the full record for a business-registry worked example.