Disclosure modes and computed answers

View as Markdown

You are weighing whether Registry Stack actually keeps a sensitive registry record private while still answering questions about the subjects in it. The short answer is that a caller asks a question and receives a computed answer, not the record. This page explains how that works, what each kind of answer does and does not reveal, and where the privacy claim has edges. You will see one product term used throughout: an evidence claim, which is one atomic, precisely defined evidence statement or extracted value, such as “is this person registered?” or “what is this person’s registration date?”. A claim is deliberately narrow and reusable. A claim that returned a whole record would over-collect, and a claim that embedded one consumer’s eligibility or action rules could not be reused as neutral evidence.

How Registry Notary controls what leaves the service

Registry Notary is the component that evaluates an evidence claim and enforces what the caller receives back. It controls the answer through three disclosure modes: value, predicate, and redacted. There are exactly three. value is not always all-or-nothing, though: when a claim returns an object, value mode can have specific fields redacted (configured through redaction_fields), and the result carries the object minus those fields plus a list of what was withheld.

Per-claim disclosure control is enforced at runtime by the service. It is not left to a caller’s good behavior.

The evaluation pipeline: computed answers, not record handoffs

The reason an answer can stand in for a record is that the caller never supplies the value being asked about. To evaluate a claim, the caller sends a claim id plus the typed request inputs the claim policy admits. Those inputs can include target or requester identifiers, declared variables, or scoped relationship attributes. The REST call is authenticated the way the rest of the service is: an API key or bearer token in static-credential mode, or an OIDC token, whichever your deployment is configured for. For a registry-backed claim, Registry Notary requests the compiler-pinned consultation from Registry Relay. For a source-free or self-attested claim, Notary uses only the configured request inputs. The caller does not supply the evaluated value, and cannot inject one.

The evaluation runs as a pipeline: Relay returns a closed typed consultation result when the claim is registry-backed, a rule evaluates the configured evidence statement, a disclosure mode shapes what leaves the service, and a response format carries the result. Because Notary computes the answer from the closed Relay result or permitted self-attestation, it can return that computed answer rather than handing back a source record.

The rule that does the computing is one of three kinds. An exists rule checks whether the pinned consultation produced one admissible match. An extract rule reads a declared typed output. A cel rule derives an evidence value from typed outputs, request variables, or earlier claim results through a hardened expression. Each kind produces an answer about the subject without that answer being a copy of the source row.

Evidence is not a consumer decision

Registry Relay source-access and adaptation policy controls how an authoritative source is read and normalized. Registry Notary evidence policy controls which evidence statement is evaluated, who can request it, and how much can be disclosed. The evidence consumer determines how the evidence is used, while the decision owner remains accountable for requirements, decisions, and actions.

A Common Expression Language (CEL) rule can derive an evidence predicate, such as whether the source records an active programme enrollment or a measles dose. It is not a general-purpose consumer eligibility or decision engine. A public-health programme, for example, can act as both evidence consumer and decision owner when it combines those evidence claims with its own thresholds, priorities, and case state to decide whether outreach or follow-up is required.

Registry Notary can also attest a decision that an authoritative source already owns. The claim identifier and its review documentation must say that it is a source-owned decision. Notary does not recompute that decision or present the source’s decision policy as Notary policy.

The three disclosure modes

The disclosure mode fixes how much of the computed answer the caller receives:

Mode	What the caller receives
`value`	the evaluated value, less any object fields the policy redacts
`predicate`	only the true/false satisfaction of a boolean result
`redacted`	no value and no satisfaction outcome

value returns the computed result, minus configured object-field redactions, so this mode is the least private of the three and is appropriate only where the use case calls for the actual value.

Every evaluation result records which disclosure mode was applied, so a downstream system can tell how much was revealed.

This is the central privacy property. Because Notary computes the answer from compiler-pinned Relay outputs or permitted self-attestation, a predicate result can satisfy a question while disclosing only a boolean. A question of whether someone has a registered record is modelled as an exists rule disclosed as predicate: the caller learns true when a matching record is found, while a subject with no matching record returns evidence.not_available (collapsed to a single public reason by default) rather than false; absence is surfaced as no-evidence, not as a negative result. Either way the source row never leaves the service. A source fact such as whether a recorded vaccination dose is present can be modelled as a boolean evidence predicate without returning the underlying health record.

A redacted result goes further: it carries neither the source value nor the satisfaction outcome. Both are withheld. The standard result body reports no satisfied value, and the CCCEV JSON-LD renderer omits cccev:isConformantTo.

predicate still discloses a true-or-false fact; redacted does not.

Preserve negative, unknown, and unavailable evidence

Claim authors must keep these source meanings distinct:

true means the reviewed source contract positively establishes the evidence statement.
false means the reviewed source contract positively establishes its negative.
null means a subject matched but the declared source value is unknown, absent, or not recorded.
no_match means the exact selector did not resolve a subject.
ambiguous means the selector resolved more than one admissible subject.
A source failure means the source could not provide a reliable result.

A claim rule must not silently coerce null, no_match, ambiguous, or source failure to false. Missing evidence is not a negative fact. An explicitly named existence predicate is the narrow exception: a reviewed rule can map matched == false to false only when the claim means that one admissible match exists. This exception does not make other claims negative, and ambiguity or source failure never becomes false. A public disclosure policy can collapse matching failures to evidence.not_available, but the reviewed source outcome and audit provenance remain distinct from an explicit negative source value.

How disclosure policy is configured per claim

The caller does not freely pick from all three modes. Each claim configures a disclosure policy: a default mode, an allowed set drawn from the three modes, and a downgrade policy. A caller may request a mode: Notary honors it when it is in that claim’s allowed set. Under the default deny downgrade, a disallowed request is refused (claim.disclosure_not_allowed); a default or redacted downgrade substitutes that fallback mode when the fallback is itself allowed. When the caller requests no mode, Notary applies the claim’s default. So the policy bounds which modes are allowed, and the caller chooses among the allowed modes. A privacy-sensitive claim can be configured to default to the least-revealing mode that still answers the question.

What a redacted result still reveals (and to whom)

“Reveals nothing to the caller” is not the same as “leaves no trace.” A redacted evaluation can still be pointed back at: it carries an evaluation_id, and the audit record carries a verification_id and a claim_hash. That lets you reference the evaluation that happened; it is not a cryptographic signature on the answer. Redaction shapes what the caller sees; it does not erase the fact that an evaluation happened.

That trace is by design. Every evaluation (redacted or not) is audited, and a deployment can run audit fail-closed, so that a request whose audit record cannot be written does not succeed. So redaction does not mean an unlogged request; it means an unrevealed answer.

There is a related protection on the matching surface. By default, a matching failure collapses to a single public reason, evidence.not_available, so the lookup cannot be used as an existence oracle; a “not found” answer does not tell the caller whether a record exists. This complements redacted disclosure by not leaking record existence. A deployment can turn this off, but only in a controlled environment; it is not always on.

Disclosure control is one safeguard among several

Disclosure modes are one runtime safeguard within a broader posture that also includes authentication, scoped routes, no source mutation, and audit. They are not the whole privacy guarantee. A few protections are not the software’s to make at all: secret and key custody, audit retention, tenant isolation, transport, and rate limiting are your deployment’s job, not built-in guarantees.

Limits

A few boundaries matter when you evaluate this design:

Minimization is conditional, not absolute: A minimized answer can be narrower than the full source record only where the configured use case supports that pattern. Notary does not always return less than the record; value mode returns the full value, and a claim reveals only what its policy was configured to reveal.
The caller cannot inject a value, but matching strictness is configured: The “computed answer avoids sharing the record” guarantee rests on Notary computing the answer from the configured evidence mode and closed typed inputs. Matching is only as strict as the reviewed Relay consultation contract.
Disclosure modes are not credential selective disclosure: A holder’s later choice of which credential fields to present is a separate mechanism from Notary’s three evaluation modes. Do not read value/predicate/redacted as the same thing as a wallet holder selectively disclosing credential fields.
Credential selective disclosure is claim-output scoped by default: without an explicit projection, each claim becomes one disclosure carrying the whole value, so an object-valued output is revealed as a unit.

These modes also sit inside boundaries that are not specific to disclosure design: how the Relay consultation is authorized and pinned, how self-attestation inputs are scoped, and what “aligned with a standard” does and does not mean. Weigh those alongside the disclosure modes; see the known limitations hub for the full inventory.

Security overview: the full posture this fits into
Data minimization and purpose limitation: the privacy view
Known limitations and non-guarantees: where the edges are
Records stay home: what stays inside the institution and what crosses out
How a claim and its disclosure policy are defined: RS-DM-CLAIM; disclosure modes, credentials, and federation: RS-PR-NOTARY