Deliberately narrower than data-cap's equivalent, which
splits the unprovable case further (an unresolved consumer vs. an
indeterminate field). That split exists because a data-cap capability
exposes many fields at once, so it has a real "we resolved the consumer,
but can't tell which field it touched" state to name. env-cap's
consumption model is one value per key: a contract member access either
names the key statically ("used") or it doesn't ("indeterminate"), and
there is no intermediate case where the consumer is known but the thing
consumed is ambiguous. Adding a fourth state here would be vocabulary
borrowed from a model env-cap doesn't have -- see ADR 0010's
"provable, not heuristic" rule. Developer-declared dynamicAccess
citations stay a wholly separate fact and are never folded into this
status (ADR 0037).
What env-cap's static scan could prove about one variable's consumption: it was member-accessed somewhere (
"used"), it was never accessed at all within the scanned surfaces ("unconsumed"), or a computed (dynamic) property access on the owning contract makes the answer unprovable ("indeterminate").