June 4, 2026. I am tightening three parts of VALESKA that determine whether a reviewer can inspect a retrieval decision: access-event recording, permission refresh, and image-query conditions. A policy statement alone cannot explain why a particular record was returned. The implementation must carry the relevant values through the access and retrieval paths, and its tests must exercise those paths. Today’s changes improve that inspectability. They do not yet measure how the platform behaves under sustained changes in a live enterprise directory.
Auditability starts with the path actually taken
The governance work tightens the audit-hash path and the supporting authorization and lineage code. An audit hash gives a later reviewer a way to compare what was recorded about an access event with the inputs that governed it. That only has value if the surrounding code passes the intended typed values into the calculation and if the access path has tests that exercise the relevant cases. This revision also updates access control list (ACL) refresh handling and the permission mappers for Alfresco, Gmail, OpenText, and SharePoint. The common purpose is to retain source permission information while turning it into grants VALESKA can evaluate.
That is an implemented integration surface, not evidence that every connector has been operated continuously or that every source policy has been reconciled. The repository tests cover mapping, refresh, application programming interface (API) behavior, route authentication, and lineage-related cases. They show that the changed contracts can be exercised in the codebase. They do not measure freshness under a changing enterprise directory, nor do they establish a completed access audit for a live organization. Those remain operational questions, and they need live-directory evidence before the work can be described as a production governance result.
Image retrieval needs conditions as well
The image-retrieval revision separates structural clues from the similarity query. Episode, scene, and beat tokens are stripped from the text used for matching, while production-cut scope is handled through explicit query conditions. The change also addresses path verification and result ordering, with corresponding updates around images, cuts, thumbnails, reconciliation, and search. This matters when a query mixes a description with a location inside a production: the system should apply the requested scope without treating every structural label as descriptive language. The changes make the selection mechanics more inspectable; representative queries are still needed to establish whether the returned images are useful.
Putting these changes in one dated milestone does not make access governance and image search the same problem. They share a discipline. A system should be able to show what rule it applied, what representation it used, and what test establishes the current behavior. For access, that means a source ACL, a mapped grant, lineage, and an audit record. For image retrieval, it means an accepted query shape, thumbnail and reconciliation handling, and explicit conditions before a result enters a production-cut path.
The working question
The next test is operational: when permissions change in a connected source, can a refresh produce a reviewable before-and-after record without granting more access than the source allows? In parallel, image-query cases need representative evaluation data so the production-cut conditions can be tested against real retrieval failures as well as unit fixtures. Until those tests exist, this work should be described as implemented and covered by repository tests, not as a measured production outcome. The value today is that reviewers have specific paths to inspect instead of a promise that governance exists somewhere outside the evidence.
Historical basis: 2026-06-04 repository milestones, commits 741fa08 and 0a9121c.