Clarify behavior with more explanation and an example e.g.:

In this mode "calls hitting the cache continue to be authorized or denied based on their cached status". For further clarification the cache hit is determined by the key which consists of the credentials and all matched methods and metrics. See example below (not only Methods are considered and not Metrics):

Applications A and B.
API endpoints api.mydomain.com/[resource]
Resource is one of X, Y or Z

Scenario 1
Full granularity mapping based on HTTP methods GET and POST i.e. potential matched methods
x-get
x-post
y-get
y-post

Before API Manager outage the following call is made:
A calls GET to api.mydomain.com/x
After API Manager outage the following is the result of API authorizations:
A calls GET to api.mydomain.com/x : Allowed
A calls POST to api.mydomain.com/x : Denied
A calls GET to api.mydomain.com/y : Denied
B : all calls denied
C : all calls denied

Scenario 2
Mid-level granularity based on the API path and not down to granularity of HTTP methods i.e. potential matched methods
x
y

Before API Manager outage the following call is made:
A calls GET to api.mydomain.com/x
After API Manager outage the following is the result of API authorizations:
A calls GET to api.mydomain.com/x : Allowed
A calls POST to api.mydomain.com/x : Allowed
A calls GET to api.mydomain.com/y : Denied
B : all calls denied
C : all calls denied

Reported by: mcheshir

https://access.redhat.com/documentation/en-us/red_hat_3scale_api_management/2.9/html/administering_the_api_gateway/apicast_policies#annotations:a80922b5-16c2-4c96-ac23-402e88b80fe8