Registry stack documentation: machine-readable Markdown. Index of all pages: https://docs.registrystack.org/llms.txt Full corpus: https://docs.registrystack.org/llms-full.txt # Disclosure modes and computed answers > Why Registry Notary can answer a question about a subject by returning a computed result (value, predicate, or redacted) instead of handing back the source record. 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](../known-limitations/) for the full inventory. ## Related - [Security overview](../../security/): the full posture this fits into - [Data minimization and purpose limitation](../data-minimization-and-purpose-limitation/): the privacy view - [Known limitations and non-guarantees](../known-limitations/): where the edges are - [Records stay home](../records-stay-home/): what stays inside the institution and what crosses out - How a claim and its disclosure policy are defined: [RS-DM-CLAIM](../../spec/rs-dm-claim/); disclosure modes, credentials, and federation: [RS-PR-NOTARY](../../spec/rs-pr-notary/)