Disclosure modes and computed answers

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: a claim, which is a single pre-modelled question (one decision or one extracted value), such as “is this person registered?” or “what is this person’s registration date?”. A claim is deliberately narrow: a claim that tried to return a whole record would over-collect and be hard to authorize, which is exactly the outcome this design avoids.

How Registry Notary controls what leaves the service

Registry Notary is the component that evaluates a claim and decides 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 subject-resolution inputs the claim policy admits: a subject identifier, and, when matching policy requires them, target or requester attributes, further identifiers, or 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. Registry Notary then performs the evaluation against its own configured sources. The caller does not supply the evaluated value, and cannot inject one.

The evaluation runs as a pipeline: a source connector resolves facts about the subject, a rule computes the configured condition, a disclosure mode shapes what leaves the service, and a response format carries the result. Because Notary computes the answer itself, it can return that computed answer rather than handing back the source record it read.

The rule that does the computing is one of three kinds. An exists rule checks for the presence of exactly one matching source record. An extract rule reads a value from a source field. A cel rule derives a value from source fields 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.

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.

Why predicate and redacted avoid sharing the underlying record

This is the central privacy property. Because Notary computes the answer from its own sources, 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 question about an eligibility threshold without exposing the figure behind it is modelled as a cel rule whose eligibility boolean is disclosed as predicate; the underlying value stays inside the service.

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.

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 a subject id and claim id. Identity matching is only as strict as its configured policy.
• 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 much source-binding governance is actually configured, what a source-adapter sidecar token does and does not authorize, 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.

Related

• 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