Skip to content

Derived Eligibility or Status Answer

Compute-and-answer method — instantiates Role-Scoped Disclosure Minimization

Answers the consumer's actual question with a computed predicate or status — 'meets the income threshold: yes' — returned live in place of the underlying record, so the source releases a conclusion instead of the data behind it.

Derived Eligibility or Status Answer replaces "give me the data so I can decide" with "ask me the decision and I'll answer it." The source holds the raw record, exposes a narrow query interface, and — on each request — computes the specific conclusion the consumer actually needs and returns only that: eligible / not eligible, over threshold / under, in good standing / not. The one idea that makes it this mechanism and not its siblings: the surplus never leaves because the consumer only ever receives the verdict, computed live against data the source keeps to itself. Unlike a portable credential, there is no reusable artifact and the source stays authoritative and in the loop on every query; the whole disclosure is a single decision-relevant bit.

Example

A landlord needs to know one thing about an applicant: can they afford the rent? The naive path pulls the applicant's full credit report and bank statements — income, debts, account history, past addresses — a mountain of surplus for what is really a yes/no. The derived-answer path instead sends a verification service a scoped question: does this applicant's verified income meet the 3× threshold for a $2,000/month unit? The service computes the answer against the financial data it already holds and returns "meets threshold: yes." The landlord learns the one fact that governs the lease and never sees the income figure, the debts, or the account numbers — so there is nothing for them to store, leak, or quietly discriminate on.

The subtlety is that the answers themselves can leak. If the landlord can ask a battery of overlapping questions — "meets 3×?", "meets 3.2×?", "meets 3.5×?" — the pattern of yes/no replies triangulates the income into a narrow band. So the mechanism has to review and rate-limit its own answer surface, not just each answer. And when landlords report that a bare boolean is too coarse — "we need to know if it's close, so we can ask for a co-signer" — that feedback tunes which predicate the service is willing to expose, without opening the raw data.

How it works

The source retains the raw data and publishes only a query interface that returns computed predicates or statuses. The consumer poses the decision-question; the source evaluates it against data it never releases and hands back the conclusion. What distinguishes this from a credential is that nothing portable is minted — the answer is computed fresh, per request, and the source remains the live authority rather than delegating to a signed artifact the holder carries. Because the disclosure surface is the set of answers rather than any single one, the mechanism's real work is governing that surface: choosing the least-informative sufficient answer and limiting how the answers can be combined.

Tuning parameters

  • Answer resolution — boolean vs. banded vs. full score. Coarser answers leak less but serve fewer decisions; the whole game is the least-informative answer that still decides the case.
  • Query surface and rate limits — which questions a consumer may ask, and how often. Tighter limits blunt reconstruction-by-composition, at the cost of flexibility.
  • Freshness — computed live vs. cached. A cached "eligible" is cheaper but can go stale between the computation and the decision.
  • Threshold ownership — whether the consumer supplies the threshold or the source answers only from a fixed catalog of questions. A fixed catalog resists fishing for a precise value.
  • Explanation depth — a bare answer vs. an answer with its reason. Reasons help the consumer act but re-leak the inputs the answer was meant to hide.

When it helps, and when it misleads

Its strength is the tightest possible disclosure: the surplus literally never leaves the source, the consumer receives exactly the decision-relevant bit, and there is nothing downstream to retain or breach. For a yes/no decision over sensitive inputs, releasing the conclusion instead of the data is hard to beat.

It misleads when the answer quietly carries its inputs. A series of answers can reconstruct the hidden value by composition, and an over-precise or over-explained single answer can leak it outright — so a "safe" boolean is only safe if the query surface is controlled. A derived answer also hides its own assumptions — which threshold, which data vintage — so a wrong "no" is hard for the subject to see or contest. The classic misuse is exposing an unrestricted query interface that lets a consumer triangulate the underlying number with a batch of overlapping questions, or deriving the verdict from data the source should not be using at all. The discipline is to return the least-informative sufficient answer, review the answer surface for side-channels, and rate- and combination-limit the queries so the conclusions can't be reassembled into the record[1].

How it implements the components

  • inference_and_side_channel_review — controlling what the answer, or a series of answers, lets a consumer infer about the hidden inputs is intrinsic to this mechanism; it reviews and limits its own answer surface, not just each reply.
  • consumer_feedback_loop — the exposed predicate is tuned by consumer feedback on whether the answer's form and granularity actually serve the task, closing the loop between what is disclosed and what the task genuinely needs.

It does not maintain a signed, reusable catalog of attestations or mint a portable credential — that form is Claim Certificate or Verifiable Credential; it does not classify the source's raw sensitivity (Data Loss Prevention Policy) or decide entitlement (Attribute-Based Access Policy). It answers, live, from data it keeps.

Notes

The pairing with Claim Certificate or Verifiable Credential is worth holding in mind: both disclose only a derived fact, but one answers live and keeps the source in the loop, the other mints a portable token the holder reuses offline. Choose the live answer when freshness and query control matter more than portability, and the credential when the verifier must check the fact without reaching the source at all.

References

[1] When a system answers many overlapping questions about the same private data, the pattern of answers can reconstruct the underlying value — the composition/reconstruction problem long studied in statistical disclosure control. Limiting and reviewing the query surface is the standard guard. ↩