I would first establish what the 82 percent measures. Is it 82 percent of changed files, direct grants, inherited grants, user-document pairs, or search queries that returned a document? A principal can have access through a group even if a direct permission record is absent. Conversely, a newly permitted file may simply not be indexed yet. Compare the same source snapshot, principal, and document version at each boundary before calling it an ACL sync bug.

Take a sample of missing pairs and trace them end to end. Was the source change observed? Did pagination finish? Was the permission record fetched? Were group and folder inheritance resolved? Did the index accept the update? Did it become visible to search? Was the request routed to the right partition, and did the query filter use the intended principal's groups? A connector can report that its poll succeeded while a downstream ACL materializer is retrying or a bulk index write partially failed. In a search engine such as OpenSearch, an acknowledged write may still need a refresh before it is searchable. I would inspect those stage counts and a few exact document lookups before tuning the retriever.

Missing grants cause false negatives. That is bad for usefulness, but the security concern is whether the same broken path also drops revocations. I would run the matching negative test: revoke access to a document already indexed, then search and try to open it as that principal. The final disclosure path needs a current enough authorization decision independent of the potentially stale search ACL. Do not take “we have seen no leak” as evidence that this path is safe. It may only mean nobody asked for the newly revoked file yet.

One trap is comparing source permission objects to index entries as if they were the same model. Folder inheritance, groups, links, and explicit denies may be represented differently. Define a canonical authorization question, “may principal P read document D at source state S?”, and compare the source or authoritative policy decision with the system's result for sampled pairs. Keep the distinction between a candidate filtered out by an index hint and a candidate denied by the final check. A rise in final denials often points to a stale index, but an absence of denials can also mean the wrong candidates never reached that check.

If the source change feed cannot be trusted, reconciliation becomes a normal part of the pipeline. Take a source inventory or snapshot by stable document ID, partition it, and compare versions and permission-derived summaries with our desired-state registry and index manifest. Page through the whole scope and checkpoint only completed partitions. Apply changes found during the scan without letting an old scan overwrite a newer observed state. A source that cannot give a consistent snapshot needs repeated passes or a per-item current read before activation. The exact convergence bound has to be measured, not assumed.

Would a daily full scan be enough? Maybe for repairing missed grants, if the product explicitly allows a day of missing search. It is not enough for a 30-second revocation promise. Revocation needs a different, current authorization path with a known failure policy, as in the fast-revocation question. If the source authorization service is unavailable and no sufficiently fresh decision exists, sensitive content cannot be exposed based on yesterday's grant. A stale grant can be convenient for search ranking but cannot become the final permit.

I would also inspect the remaining 18 percent by source type and permission shape. Are failures concentrated in shared folders, very large groups, newly created principals, one pagination boundary, or one tenant? A global percentage can conceal a deterministic bug. Once the fix is in place, compare both positive and negative pairs against an independent source snapshot, measure source-change-to-searchable-grant time, and separately measure source-revocation-to-blocked-disclosure time. Those are two different promises and they fail in different ways.